转载注明出处：简书-十个雨点
大家都知道，在Activity之类的组件中使用Handler，容易造成内存泄露，那是由于Handler作为内部类的时候，持有外部Activity的引用，在Activity退出以后，如果Handler还有未完成的工作，则可能导致Activity无法被销毁，内存无法回收。解决办法是将Handler声明为静态内部类，这样就不会持有Activity的引用了，如果Handler需要操作Activity中的对象，则通过弱引用或软引用的方式来引用Activity。
当然如果我要讲的只是这么简单的东西，也不值得用“奇葩”来形容了，先听我描述一下现象。
背景
我要做的是一个语言处理的功能（姑且称其为AudioHandler吧），主要流程是：在service中使用AudioRecord录音，然后不断的将录音的数据传给声音处理模块进行处理。因为要声音处理模块必须对声音进行串行处理，所以最佳的方法是HandlerThread和Handler配合使用。
HandlerThread mConsumerThread = new HandlerThread("MicAudioConsumerThread");
mConsumerThread.start();
Handler mConsumerHandler = new Handler(mConsumerThread.getLooper());
读取录音数据并使用Handler处理的代码如下：
int mReadBufferSize = 3200;
byte[] mReadBuffer = new byte[mReadBufferSize];
int realSize = mAudioRecord.read(mReadBuffer, 0, mReadBufferSize);
mConsumerHandler.post(new Runnable() {
@Override
public void run() {
mAudioDataConsumer.bufferReceived(mReadBuffer, realSize);
}
});
一切都很顺利，完美！
但是所谓bug，就是在我们想象不到的地方出现的。
问题
测试同学发现这样一种特殊情况：
- 在播放视频的时候，整个设备的cpu使用率会非常高（90%左右），而AudioHandler使用的内存会不断上涨，也就是发生了所谓的内存泄露。
- 这还没完，在播放结束的时候，AudioHandler程序会完全被卡死，没有任何反应，过一阵子才会恢复正常，设备卡死的期间，AudioHandler和系统的mediaservice进程基本上也会占用cpu90%以上，内存会逐步下降到正常。
从这些现象中，我们做了一个大胆的假设：在播放视频的时候，Handler线程处理任务的速度跟不上新增任务的速度，所以导致了buffer在内存中的堆积，引起内存泄露；而播放完以后，Handler开始处理堆积的任务，导致程序大量消耗cpu时间，产生卡死的现象。
按照这个假设，我对程序做了如下修改：
将HandlerThread和Handler改成Thread和BlockingDeque：
BlockingDeque<Runnable> workQueue = new LinkedBlockingDeque();
Thread mConsumerThread = new Thread(new Runnable() {
@Override
public void run() {
while(isRun) {
try {
Runnable runnable = workQueue.takeFirst();
if (runnable != null) {
runnable.run();
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
});
mConsumerThread.start();
读取录音数据并处理改成：
private final static int MAX_DEQUE_SIZE=30;
int mReadBufferSize = 3200;
byte[] mReadBuffer = new byte[mReadBufferSize];
int realSize = mAudioRecord.read(mReadBuffer, 0, mReadBufferSize);
enqueue(new Runnable() {
@Override
public void run() {
mAudioDataConsumer.bufferReceived(mReadBuffer, realSize);
}
});
private void enqueue(Runnable r) {
if (workQueue.size()>MAX_DEQUE_SIZE){
workQueue.pollFirst();//将最老的任务抛弃
}
workQueue.offerLast(r);
}
这样修改主要是限制了处理队列中的最大任务数量，如果我们的假设是正确的，就可以一次性解决上面出现的两个bug。后来经过测试，也确实颇有成效。
小结
我们能够做这样的修改的原因，在于语音处理本身的特点是对实时性要求较高的，所以可以把堆积的旧任务抛弃，只处理最新的任务。
虽然我们成功的修复了bug，但是深层的原因并没有找到：
- 为什么播放视频结束的时候会卡死，明明是在子线程中处理语音的，ui线程不应该被阻塞。
- mediaservice进程cpu使用率为什么在视频结束的时候反而很高。
ps：严格说来确实并不算是内存泄露，只是消费跟不上生产导致不断积累，说是内存堆积更准确。
