Androdid中ExecutorService内存泄露原因分析

Androdid中ExecutorService内存泄露原因分析

　　我们都知道ExecutorService开启线程用于实现异步逻辑，ExecutorService维护一个线程池，但是因为我们大多数时候使用ExecutorService创建的线程的生命周期跟应用app的进程是一致的，所以没有造成任何的内存泄露的问题，但是实际上ExecutorService的使用如果不小心会给我们造成麻烦。所以本文对ExecutorService使用造成的内存泄露做了源码的分析（即分析线程池内部的线程为什么处于活着的状态在runnable执行完成之后）。
假定使用ExecutorService的代码如下：

    public static void testExecutorService() {
            ExecutorService executorService = Executors.newFixedThreadPool(1);
            executorService.execute(new Runnable() {

        @Override
        public void run() {
            //do something
        }
    });
}

　　函数内部实例化局部变量，通常按照我们的理解是在函数执行完成，出了executorService变量的作用域，就会被回收内存（假定runnable已经执行结束），但是实际上结果不是这样子的，因为executorService变量创建的线程池中的线程还处于活着的状态，通常我们创建一个Thread并执行runnable的时候，在runnable执行结束的时候，thread会处于die的状态，并内存得到回收，接下去分析下为什么线程会处于活着的状态。首先我们查看ExecutorService的实现类ThreadPoolExecutor，可以看到ThreadPoolExecutor维护Worker的一个集合
　　

　　Worker对象如：

　　并且查看ThreadPoolExecutor的execute方法
　　
　　
　　可以确定executorService对象持有内部线程池维护的Worker Set集合，而Worker内部持有一个thread和一个runnable，Worker本身也是一个runnable，如果曾经我们执行过execute的话，那他们之间的对应关系如下（当executorService没有出作用域的时候）：
　　
　　当未出函数执行作用域的时候executorService和thread均被gc root索引，当出函数作用域的时候，我们能够确定executorService索引已经释放，并且如开头所说thread还处于活着的状态（使用Android stuido查看是处于wait状态），分析如下：
　　查看 execute函数，当当前runnable执行的数量小于我们设置的核心线程数量的时候，如下if判断语句为true

    if (workerCountOf(c) < corePoolSize) {
        if (addWorker(command, true))
            return;
        c = ctl.get();
    }

函数执行addWorker（只抓取核心部分代码）

    private boolean addWorker(Runnable firstTask, boolean core) {
    try {
        w = new Worker(firstTask);
        final Thread t = w.thread;
        if (t != null) {
            final ReentrantLock mainLock = this.mainLock;
            mainLock.lock();
            try {
                    workers.add(w);
            } finally {
                mainLock.unlock();
            }
            if (workerAdded) {
                ***t.start();***
                workerStarted = true;
            }
        }
    } finally {
        if (! workerStarted)
            addWorkerFailed(w);
    }
    return workerStarted;
}

接下去查看t.start()，从前面我们知道，此处的thread持有的runnable对象是worker，所以t.start执行的是worker的run方法，最后执行runworker

final void runWorker(Worker w) {
        try {
            while (task != null || (task = getTask()) != null) {
                try {
                    try {
                        task.run();
                    } catch (RuntimeException x) {
                        thrown = x; throw x;
                    } catch (Error x) {
                        thrown = x; throw x;
                    } catch (Throwable x) {
                        thrown = x; throw new Error(x);
                    } finally {
                        afterExecute(task, thrown);
                    }
                } finally {
                    task = null;
                }
            }
            completedAbruptly = false;
        } finally {
            processWorkerExit(w, completedAbruptly);
        }
    }

　　　其中task是外部传入的runnable对象，我们看到此处有一个while循环，当当前的task执行完毕后，task为null，所以循环的执行我们到函数getTask查看

  private Runnable getTask() {
        boolean timedOut = false;
        for (;;) {
            int c = ctl.get();
            int rs = runStateOf(c);

            // Check if queue empty only if necessary.
            if (rs >= SHUTDOWN && (rs >= STOP || workQueue.isEmpty())) {
                decrementWorkerCount();
                return null;
            }

            int wc = workerCountOf(c);

            // Are workers subject to culling?
            boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;

            if ((wc > maximumPoolSize || (timed && timedOut))
                && (wc > 1 || workQueue.isEmpty())) {
                if (compareAndDecrementWorkerCount(c))
                    return null;
                continue;
            }

            try {
                Runnable r = timed ?
                    workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
                    workQueue.take();
                if (r != null)
                    return r;
                timedOut = true;
            } catch (InterruptedException retry) {
                timedOut = false;
            }
        }
    }

　　　其中我们看到workQueue.take();，我们知道队列的take方法在队列为空的情况下会阻塞线程。
　　　至此，分析结论是线程池内部的核心线程被队列的take阻塞。文章只做简单分析，相关部分需要还得查看源码。针对该问题修改：针对移动端建议不使用Executors.newFixedThreadPool()创建ExecutorService，改用Executors.newCachedThreadPool()，同时申请创建的线程池，如果生命周期不跟进程的生命周期一样，建议手动调用shutdown关闭线程池中的线程