一类有趣的无限缓存OOM现象一般的线程池调度任务是啥场景？有个 Queue，来了任务先入队，有个 ThreadPool

许久没水文章了，今天突然想水水。给大家分享一下一年多以前遇到的一个无限缓存的 OOM 现象

首先

想必大家都知道OOM是啥吧，我就不扯花里胡哨的了，直接进入正题。先说一个背景故事，我司app扫码框架用的zxing，在很长一段时间以前，做过一系列的扫码优化，稍微列一下跟今天主题相关的改动：

串行处理改成并发处理，zxing的原生处理流程是通过CameraManager获取到一帧的数据之后，通过DecodeHandler去处理，处理完成之后再去获取下一帧，我们给改成了线程池去调度：

单帧decode任务入队列之后立即获取下一帧数据
二维码识别成功则停止其他解析任务

为了有更大的识别区域，选择对整张拍摄图片进行解码，保证中心框框没对准二维码也能识别到

现象

当时测试反馈，手上一个很古老的 Android 5.0 的机器，打开扫一扫必崩，一看错误栈，是个OOM。

机器找不到了，我就不贴现象的堆栈了（埋在时光里了，懒得挖了）。

排查OOM三板斧

板斧一、通过一定手段，抓取崩溃时的或者崩溃前的内存快照

咦，一年前的hprof文件还在？确实被我找到了。。。

从图中我们能获得哪些信息？

用户OOM时，byte数组的 java 堆占用是爆炸的
用户OOM时，byte数组里，有大量的 3M 的byte数组
3M的byte 数组是被 zxing 的 DecodeHandler$2 引用的

板斧二、从内存对照出发，大胆猜测找到坏死根源

我们既然知道了大对象是被 DecodeHandler$2 引用的，那么 DecodeHandler$2 是个啥呀？

mDecodeExecutor.execute(new Runnable() {
            @Override
            public void run() {
                for (Reader reader : mReaders) {
                    decodeInternal(data, width, height, reader, fullScreenFrame);
                }
            }
        });

所以稍微转动一下脑瓜子就能知道，必然是堆积了太多的 Runnable，每个Runnable 持有了一个 data 大对象才导致了这个OOM问题。

但是为啥会堆积太多 Runnable 呢？结合一下只有 Android 5.0 机器会OOM，我们大胆猜测一下，就是因为这个机器消费（或者说解码）单张 Bitmap 太慢，同时像上面所说的，我们单帧decode任务入队列之后立即获取下一帧数据并入队下一帧decode 任务，这就导致大对象堆积在了LinkedBlockingDeque中。

OK，到这里原因也清楚了，改掉就完事了。