记一次 Java 应用内存泄漏的定位过程

已于 2024-04-19 15:38:41 修改
阅读量994 收藏 19
点赞数 8
文章标签： java 开发语言
于 2024-04-19 11:31:45 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/oYangYongJie/article/details/137949930
版权

问题现象

最近，笔者负责测试的某个算法模块机器出现大量报警，报警表现为机器CPU持续高占用。该算法模块是一个优化算法，本身就是CPU密集型应用，一开始怀疑可能是算法在正常运算，但很快这种猜测就被推翻：同算法同学确认后，该算法应用只使用了一个核心，而报警时，一个算法进程占用了服务机器的全部8个核心，这显然不是正常计算造成的。

定位步骤

首先按照CPU问题的定位思路进行定位，对 Java 调用堆栈进行分析：

1、使用top -c 查看 CPU 占用高的进程：

，从 top 命令的结果看，19272 号进程 CPU 占用率最高，基本确定问题是该进程引起，可以从 Command 栏看到这正是算法模块程序，注意图是线下4C机器上复现时的截图。

2、使用 ps -mp pid -o THREAD,tid,time命令定位问题线程。
 

ps -mp 19272 -o THREAD,tid,time
USER     %CPU PRI SCNT WCHAN  USER SYSTEM   TID     TIME
USER    191   -    - -         -      -     - 00:36:54
USER    0.0  19    - futex_    -      - 19272 00:00:00
USER   68.8  19    - futex_    -      - 19273 00:13:18
USER   30.2  19    - -         -      - 19274 00:05:50
USER   30.2  19    - -         -      - 19275 00:05:50
USER   30.2  19    - -         -      - 19276 00:05:50
USER   30.1  19    - -         -      - 19277 00:05:49
USER    0.4  19    - futex_    -      - 19278 00:00:05
USER    0.0  19    - futex_    -      - 19279 00:00:00
USER    0.0  19    - futex_    -      - 19280 00:00:00
USER    0.0  19    - futex_    -      - 19281 00:00:00
USER    0.4  19    - futex_    -      - 19282 00:00:04
USER    0.3  19    - futex_    -      - 19283 00:00:03
USER    0.0  19    - futex_    -      - 19284 00:00:00
USER    0.0  19    - futex_    -      - 19285 00:00:00
USER    0.0  19    - futex_    -      - 19286 00:00:00
USER    0.0  19    - skb_wa    -      - 19362 00:00:00

从结果可以看到，出现问题的线程主要是 19273-19277。

3、使用jstack查看出现问题的线程堆栈信息。

由于 jstack 使用的线程号是十六进制，因此需要先把线程号从十进制转换为十六进制。

$ printf "%x\n" 19273
4b49
$ jstack 12262 |grep -A 15 4b49
"main" #1 prio=5 os_prio=0 tid=0x00007f98c404c000 nid=0x4b49 runnable [0x00007f98cbc58000]
java.lang.Thread.State: RUNNABLE
    at java.util.ArrayList.iterator(ArrayList.java:840)
    at optional.score.MultiSkuDcAssignmentEasyScoreCalculator.updateSolution(MultiSkuDcAssignmentEasyScoreCalculator.java:794)
    at optional.score.MultiSkuDcAssignmentEasyScoreCalculator.calculateScore(MultiSkuDcAssignmentEasyScoreCalculator.java:80)
    at optional.score.MultiSkuDcAssignmentEasyScoreCalculator.calculateScore(MultiSkuDcAssignmentEasyScoreCalculator.java:17)
    at org.optaplanner.core.impl.score.director.easy.EasyScoreDirector.calculateScore(EasyScoreDirector.java:60)
    at org.optaplanner.core.impl.score.director.AbstractScoreDirector.doAndProcessMove(AbstractScoreDirector.java:188)
    at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.doMove(LocalSearchDecider.java:132)
    at org.optaplanner.core.impl.localsearch.decider.LocalSearchDecider.decideNextStep(LocalSearchDecider.java:116)
    at org.optaplanner.core.impl.localsearch.DefaultLocalSearchPhase.solve(DefaultLocalSearchPhase.java:70)
    at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:88)
    at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:191)
    at app.DistributionCenterAssignmentApp.main(DistributionCenterAssignmentApp.java:61)
 
"VM Thread" os_prio=0 tid=0x00007f98c419d000 nid=0x4b4e runnable
 
"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f98c405e800 nid=0x4b4a runnable
 
"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f98c4060800 nid=0x4b4b runnable
 
"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007f98c4062800 nid=0x4b4c runnable
 
"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007f98c4064000 nid=0x4b4d runnable
 
"VM Periodic Task Thread" os_prio=0 tid=0x00007f98c4240800 nid=0x4b56 waiting on condition

可以看到，除了 0x4b49 线程是正常工作线程，其它都是 gc 线程。

此时怀疑：是频繁 GC 导致的 CPU 被占满。

我们可以使用 jstat 命令查看 GC 统计：

$ jstat -gcutil 19272 2000 10
S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
0.00   0.00  22.71 100.00  97.16  91.53   2122   19.406   282  809.282  828.688
0.00   0.00 100.00 100.00  97.16  91.53   2122   19.406   283  809.282  828.688
0.00   0.00  92.46 100.00  97.16  91.53   2122   19.406   283  812.730  832.135
0.00   0.00 100.00 100.00  97.16  91.53   2122   19.406   284  812.730  832.135
0.00   0.00 100.00 100.00  97.16  91.53   2122   19.406   285  815.965  835.371
0.00   0.00 100.00 100.00  97.16  91.53   2122   19.406   285  815.965  835.371
0.00   0.00 100.00 100.00  97.16  91.53   2122   19.406   286  819.492  838.898
0.00   0.00 100.00 100.00  97.16  91.53   2122   19.406   286  819.492  838.898
0.00   0.00 100.00 100.00  97.16  91.53   2122   19.406   287  822.751  842.157
0.00   0.00  30.78 100.00  97.16  91.53   2122   19.406   287  825.835  845.240

重点关注一下几列：
YGC：年轻代垃圾回收次数
YGCT：年轻代垃圾回收消耗时间
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间
可以看到，20s 的时间中进行了 5 次 full GC，仅仅耗费在 GC 的时间已经到了 17s。

  1、增加启动参数，展示详细 GC 过程。通过增加 jvm 参数，更快暴露 GC 问题，并展示 GC 详细过程java -Xmx1024m -verbose:gc。

[Full GC (Ergonomics)  1046527K->705881K(1047552K), 1.8974837 secs]
[Full GC (Ergonomics)  1046527K->706191K(1047552K), 2.5837756 secs]
[Full GC (Ergonomics)  1046527K->706506K(1047552K), 2.6142270 secs]
[Full GC (Ergonomics)  1046527K->706821K(1047552K), 1.9044987 secs]
[Full GC (Ergonomics)  1046527K->707130K(1047552K), 2.0856625 secs]
[Full GC (Ergonomics)  1046527K->707440K(1047552K), 2.6273944 secs]
[Full GC (Ergonomics)  1046527K->707755K(1047552K), 2.5668877 secs]
[Full GC (Ergonomics)  1046527K->708068K(1047552K), 2.6924427 secs]
[Full GC (Ergonomics)  1046527K->708384K(1047552K), 3.1084132 secs]
[Full GC (Ergonomics)  1046527K->708693K(1047552K), 1.9424100 secs]
[Full GC (Ergonomics)  1046527K->709007K(1047552K), 1.9996261 secs]
[Full GC (Ergonomics)  1046527K->709314K(1047552K), 2.4190958 secs]
[Full GC (Ergonomics)  1046527K->709628K(1047552K), 2.8139132 secs]
[Full GC (Ergonomics)  1046527K->709945K(1047552K), 3.0484079 secs]
[Full GC (Ergonomics)  1046527K->710258K(1047552K), 2.6983539 secs]
[Full GC (Ergonomics)  1046527K->710571K(1047552K), 2.1663274 secs]

至此基本可以确定，CPU 高负载的根本原因是内存不足导致频繁 GC。

如何进行定位

以上介绍了一些常见的内存泄漏场景，在实际的问题中还需要针对具体的代码进行确定排查。下面结合之前的频繁 GC 问题，讲解一下定位的思路，以及相关工具的使用方法。

线上定位

对于线上服务，如果不能开启 Debug 模式，那么可用的工具较少。推荐方式：
使用 top -c 命令查询 Java 高内存占用程序的进程 pid。然后使用 jcmd 命令获取进程中对象的计数、内存占用信息。

$ jcmd 24600 GC.class_histogram |head -n 10
24600:
 
 num     #instances         #bytes  class name
----------------------------------------------
   1:       2865351      103154208  [J
   2:       1432655       45844960  org.optaplanner.core.impl.localsearch.scope.LocalSearchMoveScope
   3:       1432658       34383792  org.optaplanner.core.api.score.buildin.bendablelong.BendableLongScore
   4:       1193860       28652640  org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove
   5:        241961       11986056  [Ljava.lang.Object;
   6:        239984        5759616  java.util.ArrayList

结果中，#instances 为对象数量，#bytes 为占用内存大小，单位是 byte，class name 为对应的类名。
排名第一的是 Java 原生类型，实际上是 long 类型。

另外，要注意的是结果中的类可能存在包含关系，例如一个类中含有多个 long 类型数据，那 long 对应的计数也会增加，所以我们要排除一些基本类型，它们可能是我们程序中使用导致的计数增加，重点关注我们程序中的类。

如果仅仅有 jcmd 的结果，其实很难直接找到问题的根本原因。如果问题不能在线下复现，我们基本上只能针对计数较多的类名跟踪变量的数据流，重点关注 new 对象附近的代码逻辑。观察代码逻辑时，重点考虑上述几种常见内存泄漏场景。

线下定位

如果内存泄漏问题可以在线下复现，那么问题定位的工具就比较丰富了。下面主要推荐的两种工具，VisualVM & IDEA。

这里主要讲一下IDEA调试定位思路：

使用 IDEA 调试器定位内存泄漏问题

如果以上过程依然不能有效的分析出问题的根本原因，还可以使用 IDEA 的调试功能进行定位。
配置好程序的运行参数，正常复现问题之后，对程序打断点并逐步追踪。

重点关注的是程序需要大量运行时间的代码部分，我们可以使用调试暂停功能获得一个内存快照。
然后在此运行并暂停，这时候在调试的 Memory 视图中可以看到哪些类在快速增加。基本上可以断定问题的原因是两次运行中 new 该对象的语句。

码上农民
关注
  • 8
    点赞
  • 踩
  • 19
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
JAVA内存泄漏与常见问题定位
weixin_43415481的博客
08-02 1690
JAVA后端开发知识总结（持续更新…） JAVA内存泄漏 文章目录JAVA内存泄漏一、内存溢出二、内存泄漏2.1 定位与解决 一、内存溢出   OutOfMemoryError：JVM内存过小；程序不严密，产生了过多的垃圾。其解决方法在于： 增加JVM的内存大小，特别是对启动参数内存值的设定。 从根本上解决Java内存溢出的唯一方法就是修改程序，及时地释放没用的对象，释放内存空间，避免死循环，防止一次载入太多的数据。 二、内存泄漏   内存泄露，是指程序在申请内存并且用完这块内存后（对象不再需要.
Android应用内存泄漏的定位、分析与解决策略
02-25
对于不同的语言平台来说，进行标记回收内存的算法是不一样的，像Android（Java）则采用GC-Root的标记回收算法。...有了上面的内存回收的栗子，那么接下来就可以说说什么是内存泄漏了。从定义上讲，Android（J
java内存泄漏的定位与分析
weixin_30394633的博客
05-16 1806
转自:http://blog.csdn.net/gzh0222/article/details/8538727 1、为什么会发生内存泄漏 Java如何检测内在泄漏呢？我们需要一些工具进行检测，并发现内存泄漏问题，不然很容易发生down机问题。 编写java程序最为方便的地方就是我们不需要管理内存的分配和释放，一切由jvm来进行处理，当java对象不再被应用时，等到堆内存不够...
［Android进阶］Java、Android 内存泄漏总结
陶程的博客
05-27 4915
Java、Android 内存泄漏总结内存管理的目的就是让我们在开发中怎么有效的避免我们的应用出现内存泄漏的问题。内存泄漏大家都不陌生了，简单粗俗的讲，就是该被释放的对象没有释放，一直被某个或某些实例所持有却不再被使用导致 GC 不能回收。最近自己阅读了大量相关的文档资料，打算做个 总结 沉淀下来跟大家一起分享和学习，也给自己一个警示，以后 coding 时怎么避免这些情况，提高应用的体验和质量。我
Java CPU或内存使用率过高问题定位教程
五道口
01-04 3787
Spring cloud微服务广泛应用后，服务的监控和运维压力也与日俱增，经常有服务出现CPU或者内存使用率过高的告警，那么遇到这样的问题我们该如何排查呢？本文介绍了通过系统日志、java JDK工具、JVM参数、linux系统命令、Arthas诊断工具等方法，定位和解决线上CPU使用率过高、内存使用率过高的方法，大家可以根据自己的环境灵活搭配使用上述方法，解决性能问题。
java使用JMAP定位代码内存泄漏在哪
11-09
Java编程语言在处理大型应用...总的来说，结合JMAP和MAT，我们可以有效地定位和解决Java应用程序中的内存泄漏问题。确保定期监控和分析内存使用情况，可以预防和早期发现潜在的内存问题，从而保持应用的高效稳定运行。
java内存泄露定位与分析共13页.pdf.zip
11-21
Java内存泄露是一个严重的问题，它可能导致系统性能下降，甚至服务中断。本文将深入探讨Java内存泄露的定位与分析，帮助开发者识别和解决这类问题。 首先，理解Java内存模型至关重要。Java内存主要分为堆（Heap）和...
Java内存模型
最新发布
weixin_44267758的博客
07-19 337
此处的变量不是指java编程中的变量，它包括了实例字段，静态字段和构成数值对象的元素，但不包括局部变量和方法参数。JMM规定所有变量都存储在主内存中。每条线程有自己的工作内存，工作内存中保留了该线程使用到变量的主内存的副本。线程对变量的所有操作都必须在工作内存中进行，不能直接读写主内存的变量，不同的线程间也无法直接访问对方工作内存的变量，线程之间的变量值传递需要通过主内存来完成。
day04：Redis和店铺营业状态设置
m0_69266818的博客
07-15 874
介绍了Redis命令和用java操作redis还有营业额状态接口的书写
JVM-垃圾回收与内存分配
m0_50846237的博客
07-19 646
JVM-垃圾回收与内存分配
【Java算法】前缀和 下
2302_79806056的博客
07-18 925
这段代码实现了一个寻找数组中具有相等数量的0和1的最长子数组长度的算法。具体来说，它使用了前缀和（prefix sum）的概念以及哈希映射（HashMap）来优化查找过程。初始化哈希映射：计算前缀和：检查相等数量的0和1：更新哈希映射：返回结果：这种方法的时间复杂度为O(n)，因为我们只遍历数组一次，并且对每个元素执行常数时间的操作。空间复杂度也是O(n)，最坏情况下需要存储n个前缀和值。 初始化阶段:开始遍历数组:继续
【JAVA】相关程序组件
qq_44077764的博客
07-15 174
【JAVA】相关程序组件
Java 中有哪几种基本数据类型？请分别列出它们并简述每种数据类型的特点及其在内存中的占用空间？
liangzai215的专栏
07-15 512
在Java的世界里，数据是构建应用程序的基石。为了高效地处理这些数据，Java设计了一系列基础数据类型，它们直接映射到计算机硬件上，因此在性能和内存使用上更为高效。我们常说的Java八大基本数据类型，涵盖了整数、浮点数、字符和布尔值，下面我将一一介绍它们的特点以及在内存中的占用空间，并通过简单的代码实例来加深理解。
构建自动化的精粹：Gradle任务依赖性与执行顺序控制
liuxin33445566的博客
07-15 593
本文以"构建自动化的精粹：Gradle任务依赖性与执行顺序控制"为题，详细介绍了任务依赖性的重要性、基本配置、多个任务的依赖性、条件依赖性、错误处理、高级用法、多项目构建中的任务依赖性。随着Gradle的不断发展，我们可以预见到更多关于任务依赖性和构建自动化的高级特性的出现，这将进一步扩展Gradle的构建能力，满足更复杂的项目构建需求。任务依赖性定义了任务之间的执行关系，确保了在构建过程中，任务能够按照预期的顺序执行。任务是一个特殊的任务，它默认依赖于所有没有显式排除的任务。方法来指定任务的依赖性。
maven项目容器化运行之1-基于1Panel软件将docker镜像构建能力分享给局域网
qq_37372909的博客
07-15 533
docker核心功能包括镜像的构建和容器的运行，它可以开放端口将镜像构建的能力暴露。docker daeson就是docker的守护进程，开放能力是通过指定docker守护进程监听端口来实现的。后面开发人员就可以通过maven中docker插件来远程调用docker镜像构建能力了。
Java实验2
qq_64727229的博客
07-16 523
类的封装、继承、多态和接口（1）有理数四则运算（2）最终得分
每 日练 习
m0_67187271的博客
07-19 501
正确答案：C 解析：是正确的，这是最基本的类定义形式，没有继承任何类，也没有实现任何接口。也是正确的，这里定义了一个名为x的类，它继承了名为y的类。同样是正确的，这里定义了一个公共类x，它继承了Applet类，这在Java中是合法的，尤其是在创建GUI应用程序时常见。是不正确的，因为在Java中，我们不能使用static关键字来修饰一个类的定义。static关键字只能用于类的方法、变量或者是内部类（即嵌套类），但不能用于顶级类（非嵌套类）。所以，这个选项是错误的。因此，正确答案是C。
Java内存泄漏详解与对策
"Java内存泄漏通常发生在程序动态分配的堆内存未能被正确释放时，导致系统性能下降甚至崩溃。内存溢出则是应用消耗的内存超过了系统可提供的最大内存。Java的垃圾回收机制试图自动处理内存释放，但某些情况下，如长...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值