一次zookeeper Curator客户端导致JVM OOM问题的分析记录

一次JVM OOM问题的分析记录

OOM问题发生在客户的开发环境，系统是一个监控系统，表现为先高CPU，页面极卡，最后发生OOM。问实施人员拿到Heap Dump文件。来看看到底是内存不够用溢出了，还是发生了内存泄漏。

Heap Dump

• jdk自带的jvisualvm可以用，但是表现在我电脑上卡的不行。Dump文件接近7G。
• jprofiler，商用。本次分析借用其试用的10天。

Classes

查看到LinkedBlockingQueue$Node的个数到达了1亿6千万的层次，占用了近4G的内存。这个类是jdk自带并发包下的阻塞队列的内部类，猜测是有人创建了一个无界队列，放在线程池里，或者其他地方使用。

Biggest Objects

• 从这两个CuratorZookeeperClient的大小接近4G，使用了全部的JVM的大小。点来开观察层次，引用。

• EventThread类的实例中创建的waitingEvents是导致本次OOM的元凶。这是zookeeper的客户端curator的代码，竟然会导致OOM？来查看代码一探究竟。

EventThread

    class EventThread extends ZooKeeperThread {
   
        // 看到没有，这个线程它持有了一个无界队列
        private final LinkedBlockingQueue<Object> waitingEvents =
            ne