转自:https://juejin.im/entry/57fb07255bbb50005b2f20ac
java内存泄露典型特征
- 现象一: 堆/Perm 区不断增长, 没有下降趋势(回收速度赶不上增长速度), 最后不断触发FullGC, 甚至crash(如下**两张图是同一个应用的GC和Perm数据, GC触发原因确认是Perm不足**) . 一般是现象二的晚期表现.
java内存泄露场景---PermGen space
-
原因: 说明Perm不足. Perm存放class,method相关对象,以及运行时常量对象. 如果一个应用加载了大量的class, 那么Perm区存储的信息一般会比较大.另外大量的intern String对象也会导致Perm区不断增长。 此区域大小由-XX:MaxPermSize参数进行设置. (jdk8相关参数已经改变, 这里不讨论)
-
案例: Groovy动态编译class, xstream String.intern
-
本质原因: ClassLoader.defineClass和java.lang.String.intern在大量不适宜的场景被调用.
-
**解决方案: **
-
方案1(直接有效): 使用btrace相关工具输出调用ClassLoader.defineClass栈信息, 从栈信息来追溯问题. (代码如下图). 但Btrace 不能trace jvm native方法(官方release btrace 1.3.1中版本声明可以trace native方法, 但尝试无效。如果你清楚如何使用,麻烦告知一下,谢谢).
- **用JProfiler来trace String.intern方法栈
-
方案2: dump heap, 看看哪些class有异常现象(数量), String被Perm区引用的对象信息等.但这种方式不太直观,可以从String数据看看发现可疑问题,没有方案1直观。(如下图: 如果能在日常调试推荐JProfiler**)
-
java内存泄露场景---Java heap space
-
原因: 长生命周期的对象引用了短生命周期(应该尽快GC回收掉)的对象,最后造成一个对象已经不能在堆区分配足够空间. 注: 这种现象不能完全肯定是内存泄露, 比如: heap本身的设置的过小.
-
案例: 我个人没有遇到过这种案例, 但模拟过这种情形的Demo: 参考我的《深入浅出JProfiler》文章, 也学习过其他同学的案例: 例如:参数过大并且频繁超时导致内存泄露
-
解决方案:
- 触发FullGC, dump live heap. 标记堆中对象数量, 重点关注可疑对象
- 触发FullGC, dump live heap. 标记堆中对象数量, 重点关注可疑对象
- 对比步骤1和步骤2 相同对象的数量和大小, 找出可疑对象一一进行排查确认。
- 如果步骤3依然无法明确有问题的对象, 那就多执行几次步骤1和步骤2。 在此过程中可以调整GC触发时间, 模拟真实的故障场景 :)
- 看看GC后堆的大小是否增长, 如果没有不断增长, 并且持续一段较长时间, 那基本正常(具体看看[深入浅出JProfiler][JProfiler]文章中的实践章节)。