案例分析- 错误的 ExecutorService 用法导致的内存泄露

JDK 提供了 ExecutorService 接口以及默认的实现类, 并通过 Executors 工具类暴露了一些常见的用法. 如果使用不当, 将会很容易造成线上问题. 这里介绍一个曾经遇到的这样的问题.

一开始看到了某个应用里面的一台机器开始 GC overhead 告警, 通过查看 C overhead 指标数据, 发现该应用里其它几台机器也快要报警了. 感觉像是一个慢慢的内存泄漏, 完全把 heap 吃完可能需要比较长的时间.

找到那台告警的机器, 首先下载分享 verbose GC log, 发现已经开始频繁 Full GC, 老年代内存基本耗尽. 拉长时间看, 还是可以看到一开始老年代还是有空闲内存的, 然后渐渐被吃光.

既然是 heap 问题, 那就做了一个 heap dump, 同时做了一个 thread dump. 对 heap dump 使用 MAT 进行分析, 发现大量 io.netty.buffer.PoolThreadCache, 占用了一半多的 heap 空间, 而这些对象实例都是 ThreadLocal 的对象.

ThreadLocal 对象是每个 thread 对应一个实例, 那么必然有这么多 live thread. 查看刚才做的 thread dump, 发现共有 6352 个线程, 其中有 5465 个线程的名字有个共同的模式: pool-xxxx-thread-1. 这是线程池里面线程默认的名字, 并且没有发现 thread-2 这样的名字. 这些线程没有任何任务可做, 都在等待任务的到来, 看上去永远也不会等到.

从上面的数量和名字大概可以猜测, 有人用了线程池, 并且创建了非常多的线程池. git clone 该应用的源代码, 搜了一下 ExecutorService 关键字, 果然验证了这个猜想:

有个新手在一个方法里面创建了 ExexutorService, 方法结束就丢弃, 并且没有调用 shutdown() 或 shutdownNow() 方法, 这是新手很容易出现的问题.

一般说来, 线程池都是作为全局存在, 在需要的时候创建, 根据需要设置 core pool size 和 max pool size, 当线程池不在需要的时候, 一定要 shutdown, 否则这些线程会一直存活. 首先, 这个例子里面的在一个方法里面创建线程池, 本来就是不对的, 线程池是为了线程复用, 显然在这里并没有达到这个效果, 方法结束就不能再复用了. 其次, 忘记关闭导致泄露.

虽然这里是由太多的 io.netty.buffer.PoolThreadCache 所暴露的, 即使不由这个 PoolThreadCache 暴露, 早晚会由太多的线程导致 heap 被用光.

原文链接: http://www.tianxiaohui.com/index.php/interestingbug.html