你使用Rxjava时,内存泄漏了吗?

作者: brzhang | 来源:发表于2016-07-13 21:22 被阅读7036次

今天有位同学问了我一个问题,话说,问我

“有遇到网络请求一半,退出Activity造成的Theard泄露吗?已在销毁时调用了un了

我去查看了下rx的源码的unsubscribe方法,定位到一个实现类,NewThreadWorker的unsubscribe方法中,源码如下:

@Override
    public void unsubscribe() {
        isUnsubscribed = true;
        executor.shutdownNow();
        deregisterExecutor(executor);
    }

    @Override
    public boolean isUnsubscribed() {
        return isUnsubscribed;
    }

这个shutdownNow()在java的注释中写的很清楚

There are no guarantees beyond best-effort attempts to stop* processing actively executing tasks.

public interface ExecutorService extends Executor {

    /**
     * Initiates an orderly shutdown in which previously submitted
     * tasks are executed, but no new tasks will be accepted.
     * Invocation has no additional effect if already shut down.
     *
     * <p>This method does not wait for previously submitted tasks to
     * complete execution.  Use {@link #awaitTermination awaitTermination}
     * to do that.
     */
    void shutdown();

    /**
     * Attempts to stop all actively executing tasks, halts the
     * processing of waiting tasks, and returns a list of the tasks
     * that were awaiting execution.
     *
     * <p>This method does not wait for actively executing tasks to
     * terminate.  Use {@link #awaitTermination awaitTermination} to
     * do that.
     *
     * <p>There are no guarantees beyond best-effort attempts to stop
     * processing actively executing tasks.  For example, typical
     * implementations will cancel via {@link Thread#interrupt}, so any
     * task that fails to respond to interrupts may never terminate.
     *
     * @return list of tasks that never commenced execution
     */
    List<Runnable> shutdownNow();

它只是尽量保证停止所有tasks,因为,如果耗时操作没有做完,finished掉activity,同时unsubscribe 掉Subscription的话,可能还有后台线程在做一些耗时任务。那么会不会造成内存泄露呢?

我觉得还是要源码来说说话吧

 /**
     * Unsubscribe from all of the subscriptions in the list, which stops the receipt of notifications on
     * the associated {@code Subscriber}.
     */
    @Override
    public void unsubscribe() {
        if (!unsubscribed) {
            List<Subscription> list;
            synchronized (this) {
                if (unsubscribed) {
                    return;
                }
                unsubscribed = true;
                list = subscriptions;
                subscriptions = null;
            }
            // we will only get here once
            unsubscribeFromAll(list);
        }
    }

    private static void unsubscribeFromAll(Collection<Subscription> subscriptions) {
        if (subscriptions == null) {
            return;
        }
        List<Throwable> es = null;
        for (Subscription s : subscriptions) {
            try {
                s.unsubscribe();
            } catch (Throwable e) {
                if (es == null) {
                    es = new ArrayList<Throwable>();
                }
                es.add(e);
            }
        }
        Exceptions.throwIfAny(es);
    }

实际上会做一些清除引用,暂停任务的操作。因此,一般来讲在activity的ondestroy中调用unsubscribe之后,是不会造成内存泄露的。但是真的是这样的吗?让我们来做做实验吧,结果说明一切。

为了能够更好的证明这一点,我还特意做了一个app demo去验证。

主要代码:

secondActivity.png 耗时任务rx封装

demo地址已经放到了github上:

内存泄露分析

启动app,首先进入的是MainActivity,然后,我们进入SecondActivity这时候,onresume执行,我们的任务也就开始了,稍微过几秒,我们退出SecondActivity,回到MainActivity,这之后,显然,SecondActivity的ondestory方法会被执行,我们可以发现日志也停止了打印。


耗时任务正在执行

如上图所示,停留在了5就不在执行了。

这时候,我们GC一下,在导出hprof文件,注意,为什么要手动GC一下呢?因为android虚拟机去GC也是有策略的,有GC周期的。这时候可能并没有GC过,也就是说,SecondActivity的内存可能并没有被释放,但并不等于说,SecondActivity就泄露了,因为他也有可能是可以被GC的,只是还没有来得及被GC而已。总之,在导出hprof文件之前,最好先手动GC一下。就是下图那个车子,嗯,点一下吧,放心点。

GC.png

然后熟悉查看hprof文件的同学这时候可能就看到了,执行分析之后,并没有看到内存泄露。

检查内存泄漏神器.png

从上图我们看到SecondeActivity已经是红色,标明被回收了,不存在内存泄漏。

同时,我调试跟踪了一下unsubscribe调用栈,因为是一堆抽象类及接口,又有一堆的实现类,所以,最效率的方法还是调试跟踪,这时候路径就出来了,具体怎么个调发请看我的手稿,比较粗糙。

最终发现,最后的根源就是handerremoveCallbacksAndMessages 方法被调用了。

unsubscribe removeCallbacksAndMessages.png

因此是不存在内存泄漏的,是这样的吗??让我们来在看一个例子!

假如耗时任务本来就是一个异步任务呢?


修改一下

跑几秒钟,然后回到MainActivity,这时候你在GC一下,hprof文件导出看看,我去,泄漏了。

真的泄漏了

在看看控制台,我去,一直执行到跑完。


一直跑完了

然后等跑完了,在GC一下,在导出hprof文件看看,内存泄漏依然还在,SecondActivity永久放入了你的内存,知道APP进程死掉才会释放。

不信的话,可以多启动SecondActivity,退出SecondActivity几次 ,你会发现内存不断飙升~~

内存不断飙升

我继续在思考,是不是这个耗时任务本身就丢在一个线程中执行,所以,如果我们rx不切换线程,是不是就不会泄露呢?

所以,还是不服,在改改代码,继续~

rx不切换线程了,反正是在非主线程做耗时操作

结果,并没有什么卵用,和上述情况一致,多次启动、关闭SecondActivity ,你会发现内存一样会飙升,GC后,导出hprof文件看看,一样泄露了了。

所以,大家应该懂了使用 rx的正确知识,自己的任务都同步写,线程切换交给Rx,因为Rx更懂你~~。

相关文章

网友评论

  • 4Four:我觉得应该是你的new Thread造成的,匿名对象间接持有了SecondActivity的引用,所以导致的内存不能回收SecondActivity,如果把new Thread换成静态类,然后实例化一个非匿名对象,然后调用start,应该就不会存在内存泄漏了,我理解的应该是这样的。
    qweorqwrq:我也正想说这原因来着。其实很多的内存泄露都是匿名内部类引起的。本身Rx这种写法就有问题。都提供了线程切换管理了,还自己去创建线程,这个线程Rx压根就控制不了,再怎么写都避免不了内存泄露的可能。
    4Four:@brzhang :wink:
    brzhang:@4Four 没错,你理解正确
  • 1琥珀川1:最终发现,最后的根源就是hander 的 removeCallbacksAndMessages 方法被调用了。
    就实现线程终止运行了??????不靠谱
  • 1e2578a410bd:引用一下 :smile:
  • ml_bright:那要是用一些第三方的请求网络,若没有提供同步的方法该如何处理?
  • 玩鸿蒙:所以加上这个就行了是吗.subscribeOn(Schedulers.io())
    8311bb8c0b34:@liangjianxun 作者意思是自己写的方法就不用异步了,同步就可以,然后rx加上subscribeOn(Scheduler.io())就可以让自己的方法异步
  • 捡淑:mark
  • Ztiany: return Observable.create(new Observable.OnSubscribe<Object>() {
    int count;
    @Override
    public void call(final Subscriber<? super Object> subscriber) {
    if (subscriber.isUnsubscribed()) {
    return;
    }
    new Thread() {
    @Override
    public void run() {
    try {
    while (!subscriber.isUnsubscribed()) {
    SystemClock.sleep(1000);
    subscriber.onNext(count++);
    }
    } catch (Exception e) {
    subscriber.onError(e);
    }
    }
    }.start();
    }
    });

    在实现Observable的时候应该判断subscriber.isUnsubscribed()吧。
    brzhang:@Ztiany 这是个反面例子,你写了一个也改变不了泄漏
  • 一息尚存:我去,看到你这篇文章才知道这样的操作会导致内存泄漏,我项目里就有这样的操作,但这又不能改,因为是第三方的东西,没有提供同步操作,改不了啊!泄漏的根源一看就知道是线程里引用的那个subsciber,线程执行结束之前没有得到释放,因此导致内存泄漏了。所以从这个subsciber入手应该是可以解决这个内存泄漏问题的。嗯,回去研究下。。。
    一息尚存:@brzhang http://www.jianshu.com/p/aedadec2dc1a
    brzhang:@一息尚存 :+1:
  • cuixbo:有几个问题不解:
    一、使用RX线程处理
    1.内存泄漏的根本原因是什么?
    2.为什么removeCallbacksAndMessages之后就不存在内存泄漏了?
    二、使用自己线程处理
    1.在线程未执行完毕之前,确实是存在泄漏的,但是一旦线程执行完毕了,系统GC之后,为什么还会存在内存泄漏呢?
    brzhang:@崔小波 1、这里内存泄漏的根本原因是activity在destory之后,因为还被其他对象引用着,所以无法被GC。
    2、对于这个问题,我希望你读一下这篇:http://bgj.iteye.com/blog/2109095
    3、第三点是实验数据得出的结论,我之前也并没有这么觉得,对于这个结论,你最好自己更具demo去试一试,我启动,关闭8此,等到保证任务都执行完,在GC,看hprof文件,分析还有5个没有被释放,还有3个释放了你怎么说,据比较有研究的同事说,这工具也是有bug的,不全部准,单可以给你一个大概,我猜测原因可能是,有些过程是不能重入的,错过了就错过了,引用清除不了,因此内存顽固泄漏了。
  • 岁月留痕:张知识了,我有时候就会在rxjava中启动线程
    brzhang:@岁月留痕 :smiley:

本文标题:你使用Rxjava时,内存泄漏了吗?

本文链接:https://www.haomeiwen.com/subject/wmcejttx.html