最近在研究内存泄漏的过程中偶然发现一个问题:我们通过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);
}
}
}
- 可以看到,我在外部类和内部类中分别加上了无参构造方法和静态代码块,并输出相关日志,最后,我在主函数中实例化了外部类观察日志输出:
- 通过日志,我们可以看到,静态内部类并没有实例化也没有执行它的静态代码块,至此我们可以得出第一个结论:静态内部类并不是一开始就创建的!它与静态成员不一样,并不能直接通过外部类名.内部类名的方式就可以直接访问并得到它的对象,通俗一点来说就是:静态内部类跟正常的一个外部类一样,它需要创建才能有!
- 既然得出了上面的结论,那么第二个问题也是一样的道理,就是说:静态内部类并不会依赖于任何一个外部类实例,它可以在适当的时候被系统回收!所以这里自然也解答了第三个问题,并不会造成内存泄漏!
- 所以,静态内部类对象的生命跟普通的对象一样,生命开始于开发者创建它,结束于系统回收它!
-
最重要的一点:前面说不会造成内存泄漏的前提是传过来的对象(如context)没有被静态引用,也就是说Builder的context用静态修饰而又处理不当可能会造成内存泄漏!切记!
网友评论