leak suspect_MemoryAnalyzer.exe_celebrity leak(3)

* especially native resources, are released.

*/

public void dispose() {

}

找到这个原因时很兴奋，所以我们将try中的reader.dispose()代码注释掉，直接做截图测试，100，1000，然后打印JVM堆栈转存用MAT分析，印证了上面的分析结果。

然后修复这个Java类+log（不符合预期的log打印），部署上线了。

因为已知道了JPEGImageReader实例未被释放，故可通过命令jmap -histo:live <pid> | grepImageReader 【jmap -histo:live <pid> 分析具体的对象数目和占用内存大小】

上来查看JPEGImageReader instances数量变化，大概观察1个小时左右，发现JPEGImageReader instances>5了，而且也没有不符合条件的log输出，正常应该释放掉的，难道还是有内存泄漏？

然后，继续分析代码，根据ImageReader搜索了下整个代码库，发现有个PgcAuditServiceImpl.java PGC审核里也有引用的代码。

这块仅使用了ImageReader获取width和height，之后并没有调用dispose方法，尽快修复重新上线。leak suspect

持续观察一段时间，jmap查看类及对象情况：

[root@cdn ~]# jmap -histo:live 28093 | grep ImageReader

1905:188com.sun.imageio.plugins.gif.GIFImageReaderSpi

1913:188com.sun.imageio.plugins.bmp.BMPImageReaderSpi

1917:188com.sun.imageio.plugins.wbmp.WBMPImageReaderSpi

1922:188com.sun.imageio.plugins.png.PNGImageReaderSpi

1924:188com.sun.imageio.plugins.jpeg.JPEGImageReaderSpi

2685:248com.sun.imageio.plugins.jpeg.JPEGImageReader$CallBackLock$State

3881:124[Lcom.sun.imageio.plugins.jpeg.JPEGImageReader$CallBackLock$State;

com.sun.imageio.plugins.jpeg.JPEGImageReader$CallBackLock$State，内部静态类CallBackLock和State，所以有2个instances

[Lcom.sun.imageio.plugins.jpeg.JPEGImageReader$CallBackLock$State;1个Class对象

持续观察几天性能指标平稳，服务器cpu、swap、load对于内存泄漏前占用都非常少了。

经过以上分析，实际本次故障罪魁祸首是在PGC审核截图引起。香港vrs因运营没有使用到PGC审核功能所以也不会触发内存泄漏问题。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-48515-3.html