问题解决：记录一次Java程序内存泄露的解决过程（proxool内存泄露）

文章目录

问题场景
问题环境
问题原因
解决方案
结果
总结
参考链接
随缘求赞

问题场景

在线上运行的程序，有一天突然前端响应缓慢，但是后台日志依旧还在正常输出。针对这种情况，本篇博客主要是进行问题解决的过程说明。

问题环境

软件	版本
Centos	6.4
JDK	1.6
proxool	0.9.0RC3

问题原因

1. 使用top命令查看进程情况

在这里插入图片描述

2. 使用jstat命令查看当前GC情况

 jstat -gcutil  13062 5000

在这里插入图片描述

从上图可以看出，现在项目是处于频繁GC的状态，内存基本都被占满了。

3. 使用jmap命令打印当前存活的最大20个对象

 jmap -histo:live 13062 | head -20

在这里插入图片描述

从上图可以看到，目前是数据库相关的类占用了比较大的空间。其中有proxool，这个时候猜测是因为proxool的问题导致的。

4. 使用jmap保存当前堆栈信息

jmap -dump:format=b,file=heap-dump.bin 13062

5. 使用MAT工具进行head.dump的分析

将第4步导出的堆栈信息，使用MAT工具打开，打开之后，进行分析，分析结果如下：
在这里插入图片描述

从图中，可以知道，Finalizer占用了最大的空间，达到了2.9GB。

6. 使用jstack命令获取进程的堆栈信息

之后，我们使用以下命令将该进程的堆栈信息dump下来，如下：

 jstack 13062 > 13062 _error.log

并搜索Finalizer字眼，结果如下：
在这里插入图片描述

7. 锁定问题

这个就是比较著名的proxool内存泄露问题，在JVM回收WrappedConnection对象时，由于代理类重写了finalize方法，WrappedConnection方法被丢进引用队列等待finalizer线程执行finalize方法，finalize本身没有额外的实现，但是代理类在执行该方法之前会做一个isClose的判断，而jdbc oracle的实现类则使用了synchronize修饰了isClose，导致业务逻辑从池里拿出来该连接使用的时候会与finalize线程竞争该锁，一旦业务逻辑处于繁忙状态则finalizer线程执行的频率大大减小，此时在队列中的引用依然存在，对象仍然会在堆中存活。