最近在研究内存泄漏的过程中偶然发现一个问题：我们通过Builder这种构建者的方式(这个Builder是个静态内部类)去构建一个参数对象是否会引发内存泄漏的风险（即静态内部类的生命周期是怎样的）？核心代码如下：
public class ImageLoader {
private Context context;
public ImageLoader(Builder builder) {
this.context = builder.context;
}
public Context getContext() {
return context;
}
public static class Builder {
private Context context;
public Builder with(Context context) {
this.context = context;
return this;
}
public ImageLoader build() {
return new ImageLoader(this);
}
}
}
- 类似android中Dialog的创建，也是内部维护了一个静态内部类Builder，通过实例化Buidler对象去设置各种参数，最后通过build方法去实例化ImageLoader。不知道大家会不会跟我一样，会这么想：
1.静态内部类应该是一开始就创建了并且会一直存在内存中
2.所有的外部类实例共享这个静态内部类
3.静态会不会造成我的上下文（假设传递过来的是activity对象）泄漏
带着这些疑问，我做了如下的改动：
public class ImageLoader {
private Context context;
static {
Log.e("cyw", "ImageLoader静态代码块");
}
public ImageLoader(){
Log.e("cyw", "ImageLoader构造方法");
}
public ImageLoader(Builder builder) {
this.context = builder.context;
}
public Context getContext() {
return context;
}
public static class Builder {
private Context context;
static {
Log.e("cyw", "Builder静态代码块");
}
public Builder(){
Log.e("cyw", "Builder构造方法");
}
public Builder with(Context context) {
this.context = context;
return this;
}
public ImageLoader build() {
return new ImageLoader(this);
}
}
}
- 可以看到，我在外部类和内部类中分别加上了无参构造方法和静态代码块，并输出相关日志，最后，我在主函数中实例化了外部类观察日志输出：
日志.png
- 通过日志，我们可以看到，静态内部类并没有实例化也没有执行它的静态代码块，至此我们可以得出第一个结论：静态内部类并不是一开始就创建的！它与静态成员不一样，并不能直接通过外部类名.内部类名的方式就可以直接访问并得到它的对象，通俗一点来说就是：静态内部类跟正常的一个外部类一样，它需要创建才能有！
- 既然得出了上面的结论，那么第二个问题也是一样的道理，就是说：静态内部类并不会依赖于任何一个外部类实例，它可以在适当的时候被系统回收！所以这里自然也解答了第三个问题，并不会造成内存泄漏！
- 所以，静态内部类对象的生命跟普通的对象一样，生命开始于开发者创建它，结束于系统回收它！
-
最重要的一点：前面说不会造成内存泄漏的前提是传过来的对象（如context）没有被静态引用，也就是说Builder的context用静态修饰而又处理不当可能会造成内存泄漏！切记！
