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

已于 2024-04-19 15:38:41 修改
阅读量989 收藏 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
    评论
记1次生产环境java进程内存泄漏问题定位（使用Arthas）
叶子叶来
03-30 5244
记1次生产环境Java内存泄漏问题定位（使用Arthas），堆外内存溢出；
java内存泄漏的定位与分析
weixin_30394633的博客
05-16 1805
转自:http://blog.csdn.net/gzh0222/article/details/8538727 1、为什么会发生内存泄漏 Java如何检测内在泄漏呢？我们需要一些工具进行检测，并发现内存泄漏问题，不然很容易发生down机问题。 编写java程序最为方便的地方就是我们不需要管理内存的分配和释放，一切由jvm来进行处理，当java对象不再被应用时，等到堆内存不够...
Java CPU或内存使用率过高问题定位教程
五道口
01-04 3685
Spring cloud微服务广泛应用后，服务的监控和运维压力也与日俱增，经常有服务出现CPU或者内存使用率过高的告警，那么遇到这样的问题我们该如何排查呢？本文介绍了通过系统日志、java JDK工具、JVM参数、linux系统命令、Arthas诊断工具等方法，定位和解决线上CPU使用率过高、内存使用率过高的方法，大家可以根据自己的环境灵活搭配使用上述方法，解决性能问题。
［Android进阶］Java、Android 内存泄漏总结
陶程的博客
05-27 4909
Java、Android 内存泄漏总结内存管理的目的就是让我们在开发中怎么有效的避免我们的应用出现内存泄漏的问题。内存泄漏大家都不陌生了，简单粗俗的讲，就是该被释放的对象没有释放，一直被某个或某些实例所持有却不再被使用导致 GC 不能回收。最近自己阅读了大量相关的文档资料，打算做个 总结 沉淀下来跟大家一起分享和学习，也给自己一个警示，以后 coding 时怎么避免这些情况，提高应用的体验和质量。我
JAVA内存泄漏与常见问题定位
weixin_43415481的博客
08-02 1684
JAVA后端开发知识总结（持续更新…） JAVA内存泄漏 文章目录JAVA内存泄漏一、内存溢出二、内存泄漏2.1 定位与解决 一、内存溢出   OutOfMemoryError：JVM内存过小；程序不严密，产生了过多的垃圾。其解决方法在于： 增加JVM的内存大小，特别是对启动参数内存值的设定。 从根本上解决Java内存溢出的唯一方法就是修改程序，及时地释放没用的对象，释放内存空间，避免死循环，防止一次载入太多的数据。 二、内存泄漏   内存泄露，是指程序在申请内存并且用完这块内存后（对象不再需要.
记一次 JAVA 的内存泄露分析
socct_yj的博客
12-17 1128
收到前端报错说应用无法访问，错误信息是Gc overhead limit exceeded，日志里有很多OOM，就开始了这一次内存泄露的排查之旅。 1、报错信息是：GC overhead limit exceeded。根据这个信息来看，应该是有很多对象垃圾回收失败了。 OOM 报错一般代表的情况： java.lang.OutOfMemoryError: GC overhead limit exceeded：当前已经没有可用内存，经过多次GC之后仍然没能有效释放内存。 java.lang
记一次堆外内存泄漏分析
苦行僧
01-01 8116
记一次堆外内存泄漏分析
记一次WebFlux应用内存泄漏排查
u012503481的博客
02-21 1355
背景 公司项目存在一个服务，类似于爬虫，需要解析给定的URL，从返回的HTML中提取页面的标题、封面图、摘要、icon等信息。由于这是一个无DB访问的纯内存服务，且下游服务（需解析的URL地址）并非内部服务，无需考虑并发压力，在服务搭建时选用WebFlux作为web层框架，选用spring的WebClient作为请求下游服务的HTTP客户端。 服务部署于k8s容器内，JDK版本为OpenJDK11，Pod配置4C4G，Java服务配置最大堆内存2G。 问题描述 服务上线后请求压力不大，但长时间运行后，服务堆
linux pmap 内存泄露,记一次堆外内存泄漏排查过程
weixin_39883065的博客
05-08 1899
本文涉及以下内容开启NMT查看JVM内存使用情况通过pmap命令查看进程物理内存使用情况smaps查看进程内存地址gdb命令dump内存块背景最近收到运维反馈，说有项目的一个节点的RSS已经是Xmx的两倍多了，因为是ECS机器所以项目可以一直运行，幸亏机器内存充足，不然就可能影响到其他应用了。排查问题通过跳板机登录到目标机器，执行top命令，再按c，看到对应的进程所占用的RES有8个多G(这里当时...
java使用JMAP定位代码内存泄漏在哪
11-09
Java编程语言在处理大型应用...总的来说，结合JMAP和MAT，我们可以有效地定位和解决Java应用程序中的内存泄漏问题。确保定期监控和分析内存使用情况，可以预防和早期发现潜在的内存问题，从而保持应用的高效稳定运行。
Android应用内存泄漏的定位、分析与解决策略
02-25
对于不同的语言平台来说，进行标记回收内存的算法是不一样的，像Android（Java）则采用GC-Root的标记回收算法。...有了上面的内存回收的栗子，那么接下来就可以说说什么是内存泄漏了。从定义上讲，Android（J
java内存泄露定位与分析共13页.pdf.zip
11-21
Java内存泄露是一个严重的问题，它可能导致系统性能下降，甚至服务中断。本文将深入探讨Java内存泄露的定位与分析，帮助开发者识别和解决这类问题。 首先，理解Java内存模型至关重要。Java内存主要分为堆（Heap）和...
Elsaticsearch java基本操作
最新发布
qq_62383709的博客
07-13 336
索引 基本操作 package com.orchids.elasticsearch.web.controller; import cn.hutool.core.collection.CollUtil; import cn.hutool.json.JSONUtil; import com.orchids.elasticsearch.web.po.User; import io.swagger.annotations.Api; import io.swagger.annotations.ApiOperatio
java版的上门家政系统和PHP版的上门家政有什么区别？
baina666的博客
07-12 376
综上所述，Java版和PHP版的上门家政系统各有优缺点，选择哪种语言主要取决于项目的具体需求、预算、开发团队的技术栈以及未来的扩展计划等因素。同时，由于Java生态系统的复杂性和多样性，也可能需要投入更多的时间和资源来学习和掌握相关的技术和工具。Java版：Java拥有庞大的生态系统和丰富的第三方库，这为家政系统的开发和扩展提供了强大的支持。Java版：由于Java的编译执行机制和高效的垃圾回收算法，Java版家政系统通常具有更高的运行效率和更好的性能表现，尤其是在处理高并发、大数据量等复杂场景时。
关于static定义初始化块和静态变量以及初始化块的执行顺序问题
你我约定有三的博客
07-08 436
第二步：在类加载的时候，按照从上到下执行static修饰的代码，此时执行static Test2 test1 = new Test2()，也就是创建出一个名为test1的对象。第六步：此时除了main方法，所有由static修饰的代码全部执行完毕(static修饰的代码只执行一次)，类初始化完成，开始执行main方法，main方法中只有一条语句(中的代码,此时输出aa以及a的值(由于第一步没赋初值，并且给了默认值为0 所以输出0)//首先输出a的值为10 然后输出bb，最后将a的值定义为11。
已解决 javax.xml.transform.TransformerFactoryConfigurationError 异常的正确解决方法，亲测有效！！！
小明的Java问道之路
07-08 2381
已解决 javax.xml.transform.TransformerFactoryConfigurationError 异常的正确解决方法，亲测有效！！！
java Object 转 Integer
servepeople的博客
07-09 1435
在 Java 中，可以通过多种方法将一个Object转换为Integer。
java内存泄漏排查定位
06-11
Java内存泄漏的排查和定位可以通过以下步骤进行： 1. 确认是否存在内存泄漏问题：可以通过内存监控工具查看应用程序的内存使用情况，如果发现内存使用一直在上升，而且垃圾回收无法回收内存，就有可能存在内存泄漏...

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

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

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值