如何排查Java内存泄露(内附各种排查工具介绍)

简介: 今天刚刚才加一个故障review会议, 故障非常典型, 在google也可以找到相似案例介绍。 在排查问题的过程中,使用了大量的工具, 发现有问题的地方还不只一个,总结一下. (本篇文章不会重点描述案例本身,重点会介绍个人对java内存泄露问题的排查思路和各种工具的使用)。

今天刚刚才加一个故障review会议, 故障非常典型, google下也可以找到相似案例介绍。 在排查问题的过程中,使用了大量的工具, 发现有问题的地方还不只一个,总结一下. (本篇文章不会重点描述案例本身,重点会介绍个人对java内存泄露问题的排查思路和各种工具的使用)。

java内存泄露典型特征

  • 现象一: 堆/Perm 区不断增长, 没有下降趋势(回收速度赶不上增长速度), 最后不断触发FullGC, 甚至crash(如下两张图是同一个应用的GC和Perm数据, GC触发原因确认是Perm不足)
. 一般是现象二的晚期表现.

_2016_09_28_11_01_16
_2016_09_28_11_01_05

  • 现象二:每次FullGC后, 堆/Perm 区在慢慢的增长, 最后不断触发FullGC, 甚至crash(如下图: 示意图)
    _2016_09_29_12_44_16

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方法, 但尝试无效。如果你清楚如何使用,麻烦告知一下,谢谢).
 ![_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区中的内容, 初步确定是否存在问题 (如下图)

_2016_09_29_3_07_42

_2016_09_29_1_45_46

java内存泄露场景---Java heap space

  • 原因: 长生命周期的对象引用了短生命周期(应该尽快GC回收掉)的对象,最后造成一个对象已经不能在堆区分配足够空间. 注: 这种现象不能完全肯定是内存泄露, 比如: heap本身的设置的过小.

  • 案例: 我个人没有遇到过这种案例, 但模拟过这种情形的Demo: 参考我的《深入浅出JProfiler》文章, 也学习过其他同学的案例: 例如:参数过大并且频繁超时导致内存泄露
  • 解决方案:

    1. 触发FullGC, dump live heap. 标记堆中对象数量, 重点关注可疑对象
    2. 触发FullGC, dump live heap. 标记堆中对象数量, 重点关注可疑对象
    3. 对比步骤1和步骤2 相同对象的数量和大小, 找出可疑对象一一进行排查确认。
    4. 如果步骤3依然无法明确有问题的对象, 那就多执行几次步骤1和步骤2。 在此过程中可以调整GC触发时间, 模拟真实的故障场景 :)
    5. 看看GC后堆的大小是否增长, 如果没有不断增长, 并且持续一段较长时间, 那基本正常(具体看看深入浅出JProfiler文章中的实践章节)。

    注: Java内存泄露的场景还有很多(可以参考下官方的一些文档java memleaks), 有机会后面会继续补充.

目录
相关文章
|
4天前
|
存储 分布式计算 监控
Java一分钟之-Hazelcast:内存数据网格
【6月更文挑战第17天】**Hazelcast是开源的内存数据网格(IMDG),加速分布式环境中的数据访问,提供内存存储、分布式计算、线性扩展及高可用性。常见挑战包括内存管理、网络分区和数据分布不均。通过配置内存限制、优化网络和分区策略可避免问题。示例展示如何创建Hazelcast实例并使用分布式Map。使用Hazelcast提升性能和扩展性,关键在于理解和调优。**
18 1
|
1天前
|
监控 算法 Java
Java虚拟机(JVM)使用多种垃圾回收算法来管理内存,以确保程序运行时不会因为内存不足而崩溃。
【6月更文挑战第20天】Java JVM运用多种GC算法,如标记-清除、复制、标记-压缩、分代收集、增量收集、并行收集和并发标记,以自动化内存管理,防止因内存耗尽导致的程序崩溃。这些算法各有优劣,适应不同的性能和资源需求。垃圾回收旨在避免手动内存管理,简化编程。当遇到内存泄漏,可以借助VisualVM、JConsole或MAT等工具监测内存、生成堆转储,分析引用链并定位泄漏源,从而解决问题。
10 4
|
1天前
|
安全 Java 开发者
深入理解Java内存模型(JMM)及其对并发编程的影响
【6月更文挑战第19天】在Java的世界中,内存模型是构建高效、线程安全应用的基石。本文将通过探讨Java内存模型(JMM)的核心概念和原理,揭示它如何影响并发编程实践。我们将从JMM的基本定义出发,逐步解析它在同步机制、可见性规则以及有序性保证方面的作用。同时,我们也将讨论JMM对现代Java开发中常见的并发模式和框架的影响。最后,文章会提供一些实际的编码建议和最佳实践,帮助开发者更好地利用JMM来设计并发程序。
|
3天前
|
算法 Java
Java垃圾回收(Garbage Collection,GC)是Java虚拟机(JVM)的一种自动内存管理机制,用于在运行时自动回收不再使用的对象所占的内存空间
【6月更文挑战第18天】Java的GC自动回收内存,包括标记清除(产生碎片)、复制(效率低)、标记整理(兼顾连续性与效率)和分代收集(区分新生代和老年代,用不同算法优化)等策略。现代JVM通常采用分代收集,以平衡性能和内存利用率。
28 3
|
2天前
|
存储 监控 Java
Java内存管理:深入理解垃圾收集器
在Java的世界中,内存管理是程序高效运行的基石。本文将揭开Java内存管理的神秘面纱,着重探讨其核心机制——垃圾收集器。我们将从基础原理出发,逐步深入到不同垃圾收集器的工作原理和适用场景,最后通过实际案例分析,帮助读者更好地理解和应用垃圾收集器,提升Java应用程序的性能与稳定性。
|
2天前
|
存储 安全 Java
Java集合类是Java编程语言中用于存储和操作一组对象的工具
【6月更文挑战第19天】Java集合类,如`List`、`Set`、`Map`在`java.util`包中,提供高级数据结构。常用实现包括`ArrayList`(快速随机访问)、`LinkedList`(高效插入删除)、`HashSet`(无序不重复)、`TreeSet`(排序)、`HashMap`(键值对)和`TreeMap`(排序映射)。集合动态调整大小,支持对象引用,部分保证顺序。选择合适集合优化性能和数据组织。
8 1
|
4天前
|
缓存 监控 算法
【Java】Java内存溢出:原因、预防和解决方法
【Java】Java内存溢出:原因、预防和解决方法
13 2
|
5天前
|
消息中间件 存储 Kafka
实时计算 Flink版产品使用问题之 从Kafka读取数据,并与两个仅在任务启动时读取一次的维度表进行内连接(inner join)时,如果没有匹配到的数据会被直接丢弃还是会被存储在内存中
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
1天前
|
存储 安全 Java
SpringSecurity6从入门到实战之初始用户如何存储到内存
Spring Security 在 SpringBoot 应用中默认使用 `UserDetailsServiceAutoConfiguration` 类将用户信息存储到内存中。当classpath有`AuthenticationManager`、存在`ObjectPostProcessor`实例且无特定安全bean时,此配置生效。`inMemoryUserDetailsManager()`方法创建内存用户,通过`UserDetails`对象填充`InMemoryUserDetailsManager`的内部map。若要持久化到数据库,需自定义`UserDetailsService`接口实
|
1天前
|
存储
数据在内存中的存储(2)
数据在内存中的存储(2)
16 5