系列文章目录
第一章
JVM 排查问题命令汇总
第三章 Java服务使用CAT监控导致OOM的分析
目录
1.2.1 Shortest Paths To the Accumulation Point (GC root到聚集点的最短路径,就是持有可能泄漏内存对象的最近一层)
1.2.2 Accumulated Objects in Dominator Tree （对象聚集详情,这个地方我们经常用来看完整的reference chain）
1.2.3 Accumulated Objects by Class in Dominator Tree （这里能找到被聚集的对象实例的类名,可以看到某个类被实例化多少次）
CAT客户端版本：
<dependency>
<groupId>com.dianping.cat</groupId>
<artifactId>cat-client</artifactId>
<version>3.0.2</version>
</dependency>
1.dump文件分析
使用MAT自动报告分析
1.1查看整体报告（System Overview）
1.1.1.Histogram 直方图统计
shallow 很小对应的Retained确很大这就有问题了。
1.1.2.TOP Consumers 找到大对象
点击该对象选择list objects ->with outgoing references : 查看这个对象持有的外部对象引用。
可以发现是“
com.dianping.cat.message.io
.TcpSocketSender” 是个发送消息入口，真正占内存的是“com.dianping.cat.message.spi.internal.DefaultMessageTree” 消息实体 。
1.2.问题详情
1.2.1. Shortest Paths To the Accumulation Point (GC root到聚集点的最短路径,就是持有可能泄漏内存对象的最近一层)
1.2.2. Accumulated Objects in Dominator Tree （对象聚集详情,这个地方我们经常用来看完整的reference chain）
可以发现在引用链及聚集详情：
com.dianping.cat.message.io.TcpSocketSender ——>
com.dianping.cat.message.io.DefaultMessageQueue —–>
java.util.concurrent.ArrayBlockingQueue —–>
com.dianping.cat.message.spi.internal.DefaultMessageTree
1.2.3. Accumulated Objects by Class in Dominator Tree （这里能找到被聚集的对象实例的类名,可以看到某个类被实例化多少次）
进一步明确被聚集的对象是com.dianping.cat.message.spi.internal.DefaultMessageTree 的实例，及数量（和cat 代码m_queue size吻合）。
2.分析的结果
分析的结果是: CAT消息队列堆积导致的oom。
其源码使用的是ArrayBlockingQueue（
默认值
）
queue_size = 5000
, 使用offer 将消息入队、 使用poll将消息出队并发送cat服务端
。
为什么消息堆积验证两个场景：
1) 发生断网channel无法重连cat服务器。
经本地断网再重连验证，channel可以重连并重新消费消息。
2）消息消费逻辑有bug导致消息无法消费
TOP Consumers —（TcpSocketSender）–> list objects ->with outgoing references找到DefaultMessageTree中发现了多条heartbeat jstack（每分钟一次） 内容，说明队列至少已经超过几分钟没有出队了，再分析其代码发现问题原因。
