Handler Thread 内部类引起内存泄露分析

非静态内部类引起内存泄漏的原因

内部类的实现其实是通过编译器的语法糖(Syntactic sugar)实现的,通过生成相应的子类即以OutClassName$InteriorClassName命名的Class文件。并添加构造函数,在构造函数中【传入】外部类,这也是为什么内部类能使用外部类的方法与字段的原因。所以,当外部类与内部类生命周期不一致的时候很有可能发生内存泄漏。

Handler引起内存泄漏案例分析

例如,当使用内部类(包括匿名类)来创建Handler的时候,Handler对象会隐式地持有一个外部类对象(通常是一个Activity)的引用。而Handler通常会伴随着一个耗时的后台线程一起出现,这个后台线程在任务执行完毕之后,通过消息机制通知Handler,然后Handler把图片更新到界面。

然而,如果用户在网络请求过程中关闭了Activity,正常情况下,Activity不再被使用,它就有可能在GC检查时被回收掉,但由于这时线程尚未执行完,而该线程持有Handler的引用,这个Handler又持有Activity的引用,就导致该Activity无法被回收,直到网络请求结束。

另外,如果你执行了Handler的postDelayed()方法,该方法会将你的Handler装入一个Message,并把这条Message推到MessageQueue中,那么在你设定的delay到达之前,会有一条MessageQueue -> Message -> Handler -> Activity的链,导致你的Activity被持有引用而无法被回收。

Handler完整方案示例

首先:将内部类声明为静态内部类(通用方法)

在Java 中,非静态的内部类和匿名内部类都会隐式地持有其外部类的引用,静态的内部类不会持有外部类的引用。如果你想使用外部类的话,可以通过软引用或弱引用的方式保存外部类的引用。

静态类不持有外部类的对象,所以你的Activity可以随意被回收。由于Handler不再持有外部类对象的引用,导致程序不允许你在Handler中操作Activity中的对象了。所以你需要在Handler中增加一个对Activity的弱引用(WeakReference)。

对于Handler,还可以通过程序逻辑来进行保护

1、在关闭Activity的时候停掉你的后台线程。线程停掉了,就相当于切断了Handler和外部连接的线,Activity自然会在合适的时候被回收。

2、如果你的Handler是被delay的Message持有了引用,那么使用相应的Handler的removeCallbacks()方法,把消息对象从消息队列移除就行了。

public class MainActivity extends Activity {
    private Handler mHandler = new MyHandler(this);
    public TextView textView;
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        textView = new TextView(this);
        textView.setText("包青天");
        setContentView(textView);
        mHandler.sendMessageDelayed(Message.obtain(), 2000);
    }
    private static class MyHandler extends Handler {
        private WeakReference<MainActivity> mWeakReference;
        public MyHandler(MainActivity activity) {
            mWeakReference = new WeakReference<MainActivity>(activity);
        }
        @Override
        public void handleMessage(Message msg) {
            MainActivity activity = mWeakReference.get();
            if (activity != null) activity.textView.setText("静态内部类的Handler");
        }
    }
    @Override
    protected void onDestroy() {
        super.onDestroy();
        if (mHandler != null) mHandler.removeCallbacksAndMessages(null);
    }
}

Thread引起内存泄漏案例分析

例如在一个Activity启动一个Thread执行一个任务,因为Thread是内部类持有了Activity的引用,当Activity销毁的时候如果Thread的任务没有执行完成,造成Activity的引用不能被释放从而引起内存泄漏。

这种情况下可以通过声明一个静态内部类来解决问题,从反编译中可以看出,声明为static的内部类不会持有外部类的引用。此时,如果你想在静态内部类中使用外部类的话,可以通过软引用的方式保存外部类的引用。

在Activity里声明了一个匿名内部类,如果Activity在销毁之前,线程的任务还未完成, 那么将导致Activity的内存资源无法回收,造成内存泄漏。

/**
 * 测试非静态内部类导致内存泄漏的问题
 */
public class MemoryLeaksActivity extends Activity {
    TextView textView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        textView = new TextView(this);
        setContentView(textView);
        String startTime = new SimpleDateFormat("yyyy.MM.dd HH:mm:ss SSS", Locale.getDefault()).format(new Date());
        textView.setText("开始休息 " + startTime);

        new Thread(() -> {
            SystemClock.sleep(1000 * 5);
            String endTime = new SimpleDateFormat("yyyy.MM.dd HH:mm:ss SSS", Locale.getDefault()).format(new Date());
            Log.i("bqt", "【结束休息】" + endTime);//即使Activity【onDestroy被回调了】,这条日志仍会打出来
            //runOnUiThread(() -> textView.append("\n结束休息 " + endTime));
        }).start();
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        Log.i("bqt", "【onDestroy被回调了】");
    }
}

Thread解决方案示例

解决办法就是使用静态内部类,如下:

/**
 * 测试使用静态内部类避免导致内存泄漏
 */
public class MemoryLeaksActivity extends Activity {
    TextView textView;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        textView = new TextView(this);
        setContentView(textView);
        String startTime = new SimpleDateFormat("yyyy.MM.dd HH:mm:ss SSS", Locale.getDefault()).format(new Date());
        textView.setText("开始休息 " + startTime);

        new MyThread(this).start();
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        Log.i("bqt", "【onDestroy被回调了】");
    }

    private static class MyThread extends Thread {
        SoftReference<Activity> context;

        MyThread(Activity activity) {
            context = new SoftReference<>(activity);
        }

        @Override
        public void run() {
            SystemClock.sleep(1000 * 15);
            String endTime = new SimpleDateFormat("yyyy.MM.dd HH:mm:ss SSS", Locale.getDefault()).format(new Date());
            Log.i("bqt", "【结束休息】" + endTime);//即使Activity【onDestroy被回调了】,这条日志仍会打出来
            if (context.get() != null) {
                context.get().runOnUiThread(() -> Toast.makeText(context.get(), "结束休息", Toast.LENGTH_SHORT).show());
            }
        }
    }
}

2017-8-24

来自为知笔记(Wiz)

时间: 2024-10-22 16:26:47

Handler Thread 内部类引起内存泄露分析的相关文章

内存泄露分析之MAT工具简单使用

使用了Heap视图的方式来分析内存泄露之后,我们尝试用MAT插件来分析下. MAT,提供了太强大的功能,以至于在测试的过程中也是懵懂的,没有彻底的研究. 1. 安装Android Sdk,Java SDK,Eclipse之类的软件之后, 2. 安装Eclipse MAT插件 3. 调出DDMS的Heap视图 4. 手机连接电脑之后,选择要测试的进程,并点击Heap 5. 在手机上操作需要测试的功能 6. 选择Dump HPROF file功能. 7. 如果Eclipse中直接安装了MAT插件之后

学会用Clang来进行内存泄露分析

最近项目出现了内存泄露的问题,对于PC x86平台来说,一点点的内存泄露往往不会出错,很难进行debug调试.这个时候我们可以用到苹果给我们带来的神器--Clang编译器来进行内存泄露分析检测,开关打开之后,生成出来的二进制文件对内存泄露的敏感程度非常高,只要有内存泄露基本就会立马停止并进行报错. 由于项目是用CMake进行组织,因此使用CMake的方法来进行开关的打开,首先要让CC和CXX都变成Clang和Clang++(注意:在Clang下有时候会对inline函数报错,需要将inline去

Handler导致内存泄露分析

Handler mHandler = new Handler() {    @Override    public void handleMessage(Message msg) {            // do something.    }}```当我们这样创建`Handler`的时候`Android Lint`会提示我们这样一个`warning: In Android, Handler classes should be static or leaks might occur.`. 一

android内存优化-Activity, Thread引起的内存泄露0

Android编程中一个共同的困难就是协调Activity的生命周期和长时间运行的任务(task),并且要避免可能的内存泄露.思考下面Activity的代码,在它启动的时候开启一个线程并循环执行任务. 1 /** 2 * 一个展示线程如何在配置变化中存活下来的例子(配置变化会导致创 3 * 建线程的Activity被销毁).代码中的Activity泄露了,因为线程被实 4 * 例为一个匿名类实例,它隐式地持有外部Activity实例,因此阻止Activity 5 * 被回收. 6 */ 7 pu

【转】.. Android应用内存泄露分析、改善经验总结

原文网址:http://wetest.qq.com/lab/view/107.html?from=ads_test2_qqtips&sessionUserType=BFT.PARAMS.194206.TASKID&ADUIN=554147273&ADSESSION=1467939955&ADTAG=CLIENT.QQ.5479_.0&ADPUBNO=26582 前言   通过这几天对好几个应用的内存泄露检测和改善,效果明显: 完全退出应用时,手动触发GC,从原来占有

ThreadLocal深入理解与内存泄露分析

ThreadLocal 当使用ThreadLocal维护变量时,ThreadLocal为每个使用该变量的线程提供独立的变量副本,所以每一个线程都可以独立地改变自己的副本,而不会影响其它线程所对应的副本.从线程的角度看,目标变量就象是线程的本地变量,这也是类名中"Local"所要表达的意思.可以理解为如下三点: 1.每个线程都有自己的局部变量 每个线程都有一个独立于其他线程的上下文来保存这个变量,一个线程的本地变量对其他线程是不可见的. 2.独立于变量的初始化副本 ThreadLocal

Android内存泄露分析和处理

什么是内存泄露 Java使用有向图机制,通过GC自动检查内存中的对象,如果GC发现一个或一组对象为不可到达状态,则将该对象从内存中回收.也就是说,一个对象不被任何引用所指向,则该对象会在被GC发现的时候被回收. 内存泄露的原因 1.资源对象没关闭造成的内存泄漏 资源性对象比如 (Cursor,File文件等)往往都用了一些缓冲,我们在不使用的时候,应该及时关闭它们,以便它们的缓冲及时回收内存.它们的缓冲不仅存在于 java虚拟机内,还存在于java虚拟机外.如果我们仅仅是把它的引用设置为null

Android内存泄露分析简要思路

工作中遇到挺多需要分析内存泄露问题的情况,现在大致简要写下思路,等之后时间相对比较充裕再进行补充. 1.明白内存泄露的判断依据? 个人总结为:持续增加,只增不减! 理解一下这8个字,配合几个命令和工具来确定一下你的应用是否存在内存泄露问题,这是很关键的,如果一开始就判断错误了,那么没有继续往下进行的理由. 命令如下: adb shell dumpsys meminfo 应用包名 [当然,比较粗略地话,可以用adb shell procrank] 这时候你可以看到一个内存使用情况表 而我们首先关注

JAVA内存泄露分析及解决

一,问题产生     项目采用Tomcat6.0为服务器,数据库为mysql5.1,数据库持久层为hibernate3.0,以springMVC3.0为框架,项目开发完成后,上线前夕进行稳定性拷机,测试数据为插入4条/S,更新4条/S,访问300次/S,前期运行速度顺畅,三天后就开始运行缓慢,访问量达到1500W次后以抛出Java heap space结束. 二.问题分析     1.前期分析为连接池内存溢出,期间优化了连接池参数,调整了tomcat线程参数,替换数据库连接池,问题依旧