java jvm oom 内存溢出排查过程

一、问题定位

直接导出了dump文件

1.1 查看占比最多的类

1.2 点进去查看实例

1.3 查看path to gc root

1.4 查看该对象到底包含了那些东西

发现，都是MQ消费者线程。

到此，问题定位出来了：由于LVIE_SET里面有大量的MQ消费者线程，导致OOM。属于内存泄漏

二 为何发生了内存泄漏

这个问题，就得探究LIVE_SET是个啥东西？

撸了一圈源码后，有以下收获：

1、它是netty的类：io.netty.util.internal.ObjectCleaner 下面的一个属性

private static final Set LIVE_SET = new ConcurrentSet();
2、它是一个Set集合类，存储的是AutomaticCleanerReference类型

那么AutomaticCleanerReference类是啥呢？一看就知道是个弱引用类。 关于java的四种引用可以百度一下。

private static final class AutomaticCleanerReference extends WeakReference<Object> {
      private final Runnable cleanupTask;
 
      AutomaticCleanerReference(Object referent, Runnable cleanupTask) {
          super(referent, REFERENCE_QUEUE);
          this.cleanupTask = cleanupTask;
      }
 
      void cleanup() {
          cleanupTask.run();
      }
 
      @Override
      public Thread get() {
          return null;
      }
 
      @Override
      public void clear() {
          LIVE_SET.remove(this);
          super.clear();
      }
  }

AutomaticCleanerReference 类中有几个属性很重要：referent，cleanupTask，ReferenceQueue queue;

那么referent虽然是个Object类型，但是在这里我们关注的要是什么类型呢？从内存分析那里得出，我们需要关注的是Thread类型。如下：

那AutomaticCleanerReference这个类，它的作用是啥呢？

简单说一下：它的referent属性引用的对象，被销毁后，AutomaticCleanerReference实例对象会被丢进queue队列里。用于对象销毁后的通知。

进一步结论：LIVE_SET 不断的添加AutomaticCleanerReference对象，却一直没有移除它，导致OOM。那么是为何呢？

1、需要找到在那里添加的，在哪里会移除。

添加处：

移除处：

2、消费者线程调用处（netty更高版本该处代码注释掉了）

其实还有一处调用了，不过和OOM没有关系，就不探究了。（实际是探究了一圈，才发现没关系的）

进过断点排查、对比正常dump文件，发现是因为下面那个代码没有为ture，没有return，走到了下面register函数，不断的向LIVE_SET里面添加对象。

继续跟进，发现在所有消费者线程执行完任务后，都会执行这个清理方法，而这个清理方法把所有的threadlocal清理掉了。导致

 threadLocalMap.isCleanerFlagSet(index)为false。

到此：问题原因已定位清楚。

方案也有了：清理方法，只清理业务的threadlocal。为了MQ消费者统一清理ThreadLocal，我们定义的ThreadLocal需要使用自定义的MegviiThreadLocal。

其实排查过程远比里面写的要曲折一下。

总结一下知识点：

ThreadLocal

FastThreadLocal

WeekRefrence

ObjectCleaner

ConsumeThread原理

内存分析工具：jvisualvm.exe或者MAT

相关概念

理解shallow heap 和 retained heap

shallow heap：对象的 Shallow heap 是其自身在内存中的大小

retained heap：指的就是在垃圾回收特定对象时将释放的内存量

java四种引用类型

https://www.cnblogs.com/liyutian/p/9690974.html

强引用：

默认声明的，只要强引用存在，垃圾回收器将永远不会回收被引用的对象，哪怕内存不足时，JVM也会直接抛出OutOfMemoryError，不会去回收。如果想中断强引用与对象之间的联系，可以显示的将强引用赋值为null，这样一来，JVM就可以适时的回收对象了

软引用：

软引用是用来描述一些非必需但仍有用的对象。在内存足够的时候，软引用对象不会被回收，只有在内存不足时，系统则会回收软引用对象，如果回收了软引用对象之后仍然没有足够的内存，才会抛出内存溢出异常。这种特性常常被用来实现缓存技术，比如网页缓存，图片缓存等。
在 JDK1.2 之后，用java.lang.ref.SoftReference类来表示软引用。

弱引用：

弱引用的引用强度比软引用要更弱一些，无论内存是否足够，只要 JVM 开始进行垃圾回收，那些被弱引用关联的对象都会被回收。在 JDK1.2 之后，用 java.lang.ref.WeakReference 来表示弱引用。

虚引用：

虚引用是最弱的一种引用关系，如果一个对象仅持有虚引用，那么它就和没有任何引用一样，它随时可能会被回收，在 JDK1.2 之后，用 PhantomReference 类来表示，通过查看这个类的源码，发现它只有一个构造函数和一个 get() 方法，而且它的 get() 方法仅仅是返回一个null，也就是说将永远无法通过虚引用来获取对象，虚引用必须要和 ReferenceQueue 引用队列一起使用。

引用队列：

引用队列可以与软引用、弱引用以及虚引用一起配合使用，当垃圾回收器准备回收一个对象时，如果发现它还有引用，那么就会在回收对象之前，把这个引用加入到与之关联的引用队列中去。程序可以通过判断引用队列中是否已经加入了引用，来判断被引用的对象是否将要被垃圾回收，这样就可以在对象被回收之前采取一些必要的措施。

与软引用、弱引用不同，虚引用必须和引用队列一起使用。

问题定位；

直接导出了dump文件

FastThreadLocal 源码解析

https://ziheliu.github.io/2020/netty/FastThreadLocal/

https://www.cnblogs.com/stateis0/p/9062144.html