Android开发从GC root分析内存泄漏

我们常说的垃圾回收机制中会提到GC Roots这个词,也就是Java虚拟机中所有引用的根对象。我们都知道,垃圾回收器不会回收GC Roots以及那些被它们间接引用的对象。但是,对于GC Roots的定义却不是很清楚。它们都包括哪些对象呢?

经过查阅,了解JVM中GC Roots的大致分类,然后用自己的语言解释一下:

  • Class 由System Class Loader/Boot Class Loader加载的类对象,这些对象不会被回收。需要注意的是其它的Class Loader实例加载的类对象不一定是GC root,除非这个类对象恰好是其它形式的GC root;
  • Thread 线程,激活状态的线程;
  • Stack Local 栈中的对象。每个线程都会分配一个栈,栈中的局部变量或者参数都是GC root,因为它们的引用随时可能被用到;
  • JNI Local JNI中的局部变量和参数引用的对象;可能在JNI中定义的,也可能在虚拟机中定义
  • JNI Global JNI中的全局变量引用的对象;同上
  • Monitor Used 用于保证同步的对象,例如wait(),notify()中使用的对象、锁等。
  • Held by JVM JVM持有的对象。JVM为了特殊用途保留的对象,它与JVM的具体实现有关。比如有System Class Loader, 一些Exceptions对象,和一些其它的Class Loader。对于这些类,JVM也没有过多的信息。

这里的参考资料有:

Yourkit

What are the roots?
了解过GC Roots之后,可以帮助我们定位内存泄漏。因为被GC roots直接或者间接引用的对象都不会被回收,所以我们要确保我们用的局部对象远离这些危险的类。下面根据GC root的分类分析一下几种内存泄漏的原因。

1. Class


应用运行过程中非动态加载的类都是通过dalvik.system.PathClassLoader的实例加载到虚拟机中的。这些类对象是GC root的一种,它们带来的静态变量永远不会被垃圾回收。因此,静态变量持有的“过期”对象将会造成内存泄漏。下面举几个例子。

单例:

public class AccountMananger {
    private Context mContext;
    private static AccountMananger instance = null;
    
    public static AccountMananger getInstance(Context context) {
        if (instance == null) {
            synchronized (AccountManager.class) {
                if (instance == null) {
                    instance = new AccountMananger(context);
                }
            }
        }
        return instance;
    }

    private AccountMananger(Context context) {
        mContext = context;
    }
}

上面这段代码就很危险,因为单例对象持有一个 Context。它可能是一个 Activity 也可能是一个 ServiceActivity 对象包括大量的布局和资源文件, 一旦它被该单例持有,它所持有的资源在应用结束前都不会被释放。修改的方法很简单:

    private AccountMananger(Context context) {
        if (context != null) {
            mContext = context.getApplicationContext();
        }
    }

传进来的ContextApplicationContext就可以了。ApplicationContext对象在应用整个生命周期中有且只有一个对象。持有它的引用不会占用更多资源。

注册/反注册

public class AccountMananger extends Observable{
//单例的内容
}

public class MainActivity extends AppCompatActivity implements Observer {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        AccountMananger.getInstance(this).addObserver(this);
    }
    
    @Override
    protected void onDestroy() {
        super.onDestroy();
    }
    
    ...
    
    @Override
    public void update(Observable observable, Object data) {
        //todo Your logic
    }
    
    
}

上面的代码也会导致内存泄漏,因为注册了监听模式却没有反注册。注册过的监听者都会间接的被单例对象持有,他们都不会被GC回收。修改方法:

    @Override
    protected void onDestroy() {
        super.onDestroy();
        AccountMananger.getInstance(this).deleteObserver(this);
    }

所有的注册型的用法都要有反注册。编码的时候养成好习惯,像Activity,Fragment等类在生命周期对等的回调方法中,最好成对的添加代码。例如在onCreate()方法注册监听之后,马上在onDestroy()方法中反注册。

非静态内部类/匿名类 + 静态变量

public class MainActivity extends AppCompatActivity {
    private static MyHandler handler = new MyHandler();

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
    }

    public class MyHandler extends Handler {
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);

        }
    }
}

非静态内部类会持有外部类的引用(所以它才可以直接访问外部类的成员变量)。上面代码中的静态handler变量间接持有了MainActivity对象。这样就造成了内存泄漏。
解决的方法就是将内部类中对外部类的调用改成public方法,然后将Handler改成静态内部类或者外部一个类。或者将将它放到弱引用中。

2. Thread


Runnable/AsyncTask

激活状态的线程是不会被GC回收的,所以它持有的对象也不会被回收。看下面的代码:

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        AsyncTasks asyncWork = new AsyncTasks(this);
        ExecutorService defaultExecutor = Executors.newCachedThreadPool();
        defaultExecutor.execute(asyncWork);
    }

    public static class AsyncTasks implements Runnable {
        private Context context;

        public AsyncTasks(Context context) {
            this.context = context;
        }

        @Override
        public void run() {
            while (true) ;
            //正常情况下,线程执行时间不会无限,但可能有5分钟,10分钟
        }
    }
}

线程中持有一个Activity对象,在这个线程活跃的时间内这个Activity对象都不会被释放。因此,其它线程中尽量不要持有Activity,Service等大对象。如果需要用到Context,尽量使用ApplicationContext

隐藏的线程

比如说在一个Activity中实现一个电子钟:

public class MainActivity extends AppCompatActivity {
    private TextView tvClock = null;
    Timer clock = null;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        tvClock=findViewById(R.id.tv_clock);
        TimerTask clockTask = new TimerTask() {
            @Override
            public void run() {
                tvClock.setText(updateClockText());
            }
        };
        clock = new Timer();
        clock.schedule(clockTask, 0, 1000);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
    }
}

Timer的部分源码如下:

public class Timer {

    private static final class TimerImpl extends Thread {
    ....
        /**
         * This method will be launched on separate thread for each Timer
         * object.
         */
        @Override
        public void run() {
            while (true) {
                TimerTask task;
                ...
            }
        }
    }

每一个Timer类都运行在一个独立的线程中。例子中我们的Timer对象的线程被设置为1000ms触发一次操作,永不结束。需要注意的是当前的引用关系Timer->TimerTask->Activity。所以当我们的Activity结束之后,还会被GC root间接持有。这个Activity每次被打开都会多一个对象在进程中,并且永远不会被回收。
解决办法就是在ActivityonDestroy方法中将Timer取消掉。

3. JNI Local & JNI Global


这类对象一般发生在参与Jni交互的类中。

比如说很多close()相关的类,InputStream,OutputStream,Cursor,SqliteDatabase等。这些对象不止被Java代码中的引用持有,也会被虚拟机中的底层代码持有。在将持有它们的引用设置为null之前,要先将他们close()掉。
还有一个特殊的类是Bitmap。在Android系统3.0之前,它的内存一部分在虚拟机中,一部分在虚拟机外。因此它的一部分内存不参与垃圾回收,需要我们主动调用recycler()才能回收。

动态链接库中的内存是用C/C++语言申请的,这些内存不受虚拟机的管辖。所以,so库中的数组,类等都有可能发生内存泄漏,使用的时候务必小心。

总结:


  1. 使用静态变量的时候要小心,尤其要注意Activity/Service等大对象的传值。在单例模式中能用ApplicationContext的都用ApplicationContext,或者把聚合关系改成依赖关系,不在单例对象中持有Context引用;
  2. 养成良好的代码习惯。注册/反注册要成对出现,ActivityService对象中避免使用非静态内部类/匿名内部类,除非十分清楚引用关系;
  3. 使用多线程的时候留意线程存活时间。尽量将聚合关系改成依赖关系,减少线程对象持有大对象的时间;
  4. 在使用xxxStream,SqlLiteDatabase,Cursor类的时候要注意释放资源。使用Timer,TimerTask的时候要记得取消任务。Bitmap在使用结束后要记得recycler()

参考文章:
Android 内存泄漏总结
Android内存泄漏分析及调试

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 197,966评论 5 462
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,170评论 2 375
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 144,909评论 0 327
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,959评论 1 268
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,851评论 5 358
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,583评论 1 275
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,956评论 3 388
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,590评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,878评论 1 293
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,892评论 2 314
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,719评论 1 328
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,501评论 3 316
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,957评论 3 300
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,124评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,440评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,003评论 2 343
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,211评论 2 339

推荐阅读更多精彩内容