本文共 2037 字,大约阅读时间需要 6 分钟。
今天刚刚才加一个故障review会议, 故障非常典型, google下也可以找到相似案例介绍。 在排查问题的过程中,使用了大量的工具, 发现有问题的地方还不只一个,总结一下. (本篇文章不会重点描述案例本身,重点会介绍个人对java内存泄露问题的排查思路和各种工具的使用)。
解决方案:
![_2016_09_29_12_59_38](http://ata2-img.cn-hangzhou.img-pub.aliyun-inc.com/c5bbdd783fb0606a9817c8296babce42) * **用JProfiler来trace String.intern方法栈
* 方案2: dump heap, 看看哪些class有异常现象(数量), String被Perm区引用的对象信息等.但这种方式不太直观,可以从String数据看看发现可疑问题,没有方案1直观。(如下图: 如果能在日常调试推荐JProfiler**)
![_2016_09_29_1_46_59](http://ata2-img.cn-hangzhou.img-pub.aliyun-inc.com/8e5d32f29e6166695ea976ae8f9ba89d)
* 方案3: 增加-XX:+TraceClassLoading和-XX:+TraceClassUnloading, 看看哪些class加载了,哪些class卸载了. 如果一些特殊的class一直被加载而没有被卸载说明也是有问题的。(如下图) ![_2016_09_29_1_06_46](http://ata2-img.cn-hangzhou.img-pub.aliyun-inc.com/b826a15b81570c02590fda7e598100cd)
* 方案4:执行jmap -permgen(jstat -gcutil 可以查看内存增长速度和区域)命令看看Perm区中的内容, 初步确定是否存在问题 (如下图)
解决方案:
注: Java内存泄露的场景还有很多(可以参考下官方的一些文档), 有机会后面会继续补充.
转载地址:http://hbmia.baihongyu.com/