Pitest内存泄露分析（工具使用IDEA、Jprofiler）

https://github.com/YKRY35/pitest/blob/master/pitest/src/main/java/org/pitest/mutationtest/mocksupport/JavassistInputStreamInterceptorAdapater.java#L64

@Override

  public void visitMethodInsn(final int opcode, final String owner,

    final String name, final String desc, boolean itf) {

  if ((opcode == Opcodes.INVOKEINTERFACE)

      && owner.equals("javassist/ClassPath") && name.equals("openClassfile")) {

    this.mv.visitMethodInsn(Opcodes.INVOKESTATIC, this.interceptorClass, name,

        "(Ljava/lang/Object;Ljava/lang/String;)Ljava/io/InputStream;", false);

  } else {

    this.mv.visitMethodInsn(opcode, owner, name, desc, itf);

  }

  

}

它将javassist的ClassPath/openClassfile方法调用全部替换为自己框架内的JavassistCoverageInterceptor/openClssfile，所以在mock之前pitest就能拿到没被修改过的字节码文件了。

但是！！！注意：

https://github.com/YKRY35/pitest/blob/master/pitest/src/main/java/org/pitest/coverage/execute/JavassistCoverageInterceptor.java#L102

决定是否对这个类进程注入的关键函数：

private static boolean isInstrumentedClass(final String name) {

return true;

}

return的true，因此所有加载进来的类全部被插入探针。像java/lang/Object，第三方框架类啊什么的，全部插了探针，再结合MockClassLoader会反复加载类，最后探针数成倍增长。

内存达到8G时，已经插入3000万个探针了。

这算是一个bug，估计是作者想先return个true测试一下，但是后面功能实现完了，前面这里忘记改了。

子进程(CoverageMinion)

子进程算是设计问题引发的内存泄漏了。

pitest内存泄漏问题本质

先谈本质：

子进程用主线程跑所有的单测，所有单测是共享一个jvm虚拟机的
PowerMock为了性能，没有完全做到环境隔离，有的虚拟机类例如包名是java./javax.的类，PowerMock又不会自己加载，而是deferTo，交给高级别的例如AppClassLoader去加载。
单测脚本或者是单测脚本用到的第三方依赖向虚拟机类中静态变量保存了数据。

这三个特性结合起来，导致了内存泄漏。

举个栗子：

如果UserService向ApplicationShutdownHooks的static变量保存了UserService的实例。

高等级ClassLoader加载的ApplicationShutdownHooks是不会被回收的，它的static变量成为Gc Root后，保持着对Class<UserService> @1实例的引用，而UserService这个实例的clasLoader又会引用MockClassLoader @1，MockClassLoader又会引用到所有它加载过的类，最后就会导致，链路的形成，即使这个单测结束，在用MockClassLoader @2时，MockClassLoader @1加载过的所有类都不会被释放（注意这里的类指的是Class<?>，而不是类的实例）。内存泄漏。

而我用到的那个被测项目，实际发现，每个MockClassLoader的深堆引用大多达到5M，200个TestUnit（一个单测文件会有多个测试单元），内存泄漏就达到1G了。

这里发生泄漏的具体原因：

原因1：log4j子线程没结束

Log4j的AsyncAppender会开子线程，来写数据库，或者写文件。在跑单测时，这个子线程在单测跑完没有结束。子线程它对应的类Java.lang.Thread虽然不是MockClassLoader加载的，但是子线程中用到的类存在MockClassLoader加载的。所以保持引用。

即AyncAppender$AsyncThread.run()在java stack里作为Gc Root了。

原因2：log4j将子线程加入jvm的shutdownHooks

不仅如此，log4j还会把这个子线程addShutdownHook，估计是想在jvm结束前将内存缓冲写入硬盘。

addShutdownHook最终会存在java/lang/ApplicationShutdownHooks中

private static IdentityHashMap<Thread, Thread> hooks;

前面说到这个不会被回收，引用存在。

原因3：log4j保存了一些数据到MbeanServerFactory

这个原理和前面的类似，javax/management/MbeanServerFacotry的classLoader也是null，即bootstrapClassLoader。

只是这个引用存在的数据结构更深，更难发现一些。

原因4：PowerMock会缓存一个类所有的方法

org/powermock/reflect/internal/WhiteboxImpl中，有个static变量allClassMethodsCache，类型是ConcurrentMap<Class, Method[]>。

类名相同的类由不同加载器加载，则是不同的Class对象，在allClassMethodsCache中则是不同的key。同时，WhiteboxImpl这个类的加载器是AppClassloader，主进程结束前WhiteboxImpl及其static引用的对象就不会被回收了。

原因5：ThreadLocal引用

Powermock会把一下Class<?>写入threadlocal，而threadlocal是保存在Thread.threadLocals数据结构中的。

不过这个问题只会直接导致最后一次执行的单测脚本的MockClassLoader泄漏。

原因n：还有别的很多。。。。

以上几个问题，通过反射，手工在每个单测脚本执行完后将那些涉及的数据结构恢复成执行前的，能够释放掉一部分MockClassLoader，但是这么手工释放，没有解决本质问题。

还有有一部分MockClassLoader被没被释放，说明还有别的引用。

三、过程分析

3.1调试环境搭建

主/子进程远程调试

先加个测试工程，包含单测的工程，和pitest工程在一个idea窗口下，这样主进程可以直接debug。

Run中添加maven。

点击debug可以调试到pitest的maven插件主进程。

Commit：

https://github.com/YKRY35/pitest/commit/2dc40dc9d11d133718edbd8f2e975084f54a5eb4

子进程，在WrappingProcess中加入远程调试参数：

if (DEBUG_FLAG) {

  cmd.add("-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=7999");

}

Commit:

https://github.com/YKRY35/pitest/commit/ac8c30cef27a36656cf8c8a42fa171d766eb86eb

添加远程调试：

如此一来，工程所有的代码都能调试到了。

Jprofiler远程调试

Jprofiler分析内存，堆对象，以及classloader加载情况，线程情况等。

1. 主进程jprofiler调试

可以在主进程运行后，jprofiler attach上去，不过开头一部分信息会丢失。

也可以在run的maven中加参数：

对应的，jprofiler中Session – integration wizards – new remote integration ，配置好就行：

端口别重了。

这样，主进程就会等待jprofiler attach上去以后，才会继续执行代码了。

2. 子进程jprofiler调试

见：

Commit:

https://github.com/YKRY35/pitest/commit/ac8c30cef27a36656cf8c8a42fa171d766eb86eb

jprofiler操作和《主进程 jprofiler远程调试》一致。

3.2子进程内存分析

内存泄漏确定

典型的增长火焰图。

每次gc完，谷底的高度都比上次高。

当然，实际高的没有这么明显，可能每个单测跑完就泄漏5M，为了这个图表现更直观，我小P了一手。望看官见谅。

占主要堆空间的对象

Heap Walker 先Mark Heap，合适的时候Take snapshot，那么显示的对象就是在mark之后，堆里新生成的对象了。

点击计算retained size，会出现最后一列，深堆引用。

Size只是这个对象自身占用的大小，每个对象都是固定的，没有参考价值。Retained size会计算这个对象所引用的所有对象（递归下去）的总大小。

按最后一列排序，java.lang.Class，java.lang.Object这种没有分析价值（或者是我目前水平不够，还无法利用这些信息）。可以看到第三方框架类MockClassLoader，占用了主要的内存，而且这个是在主动gc以后的（上方有个绿色的圈圈写着Run GC）。而且这个内存占用基本接近Memory的谷底内存。

基本可以断定，内存泄漏主要是因为MockClassLoader没有被释放。

占主要空间对象补充。。

如果上一个步骤，有相同多的第三方框架对象实例占用，可以分析一下它们之间的引用关系，来抓住主要矛盾。

例如，我最开始，分析的是javassist.bytecode.Utf8Info，但是在references中，选择merged incoming references，可以合并同类引用，并给出百分比。

可以推断出还是MockClassLoader的问题。

分析MockClassLoader被引用情况

双击MockClassLoader，进入References，选择Incoming references（incoming是谁引用了它，outgoing是它引用了谁）。

接下来，点击Show Paths To GC Root。来分析它的引用链。

官方说，大多数情况下，Single root可以解决大部分问题，但是，这里有的对象，例如ClassA, ClassA如果中间用了比如ClassA.class的情况，可能就会出现循环引用，自己引用自己的情况，这时就需要All roots，目标工程比较庞大，single root解决不了的，我就all root。

All root出来的路会很多，也不容易找到最终的那个GC root。

这一步，分析MockClassLoader的被引用，没有得到太多有价值的信息。想到这个类加载器没被gc，是它加载过的类的实例还在堆里被引用所导致的。

因此我觉定，分析MockClassLoader加载过的类的instance的引用情况。

监控ClassLoader

之后在监控面板，看到那些没有被回收的MockClassLoader，右键，show in heap walker。

然后选择show loaded instances，查看它加载过的类。

之后在Heap Walker中显示。

接下来举几个分析GC Root栗子。

子线程未结束

在Thread那里，可以看到线程越来越多，然后开启CPU recording，

查看创建线程的方法栈。可以确定是log4j框架的AsyncAppender.

然后在MockClassLoader加载过的类中(Show in Heap Walker)，搜索这个类，点击这个类的GC Root，可以看到这个：

可以注意钩子形状的那个符号（非高亮行），看了这个就是看到了胜利。

进一步印证想法，这里导致MockClassLoader没释放的第一原因（后面可以看到还有第二、第三、第n原因）。

这个对象的某些方法还在方法栈里。

然后在每个单测结束后，搜索所有线程，interrupt结束多余线程。

出现下一个问题。

子线程被加入shutdownHooks

类似的，一步步分析（A的引用链路找到B，那就再去找B，依次下去），最后找到这个：

ApplicationShutdownHooks是BootstrapClassLoader加载的，它的static变量hooks里头若干层存了Thread实例，Thread的contextClassLoader是MockClassLoader，MockClassLoader的classes变量又保存了AsyncAppenderAdmin。

关键在于这个Thread实例。

在单测结束后，通过反射，拿到hooks变量，将其还原为单测前的状态，接下来出现了下一个引用问题。