java jvm oom 内存溢出排查过程

一、问题定位

直接导出了dump文件

1.1 查看占比最多的类

java jvm oom 内存溢出排查过程_第1张图片

1.2 点进去查看实例

java jvm oom 内存溢出排查过程_第2张图片

1.3 查看path to gc root

java jvm oom 内存溢出排查过程_第3张图片

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

java jvm oom 内存溢出排查过程_第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类型。如下:

java jvm oom 内存溢出排查过程_第5张图片

那AutomaticCleanerReference这个类,它的作用是啥呢?

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

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

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

添加处:

java jvm oom 内存溢出排查过程_第6张图片移除处:

java jvm oom 内存溢出排查过程_第7张图片

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

java jvm oom 内存溢出排查过程_第8张图片

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

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

java jvm oom 内存溢出排查过程_第9张图片继续跟进,发现在所有消费者线程执行完任务后,都会执行这个清理方法,而这个清理方法把所有的threadlocal清理掉了。导致

 threadLocalMap.isCleanerFlagSet(index)为false。

java jvm oom 内存溢出排查过程_第10张图片

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

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

java jvm oom 内存溢出排查过程_第11张图片

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

总结一下知识点:

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

你可能感兴趣的:(#,JVM,虚拟机,java,jvm)