线上java.lang.OutOfMemoryError问题定位三板斧

本文介绍了如何定位和解决Java服务中的OOM问题,提出了三板斧策略:检查内存分配是否过小、找出最耗内存的对象、确认是否资源耗尽。通过jmap等工具进行分析,确保内存使用合理,避免对象泄漏和资源耗尽导致的故障。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


首先这是受一篇文章的启发:线上服务内存OOM问题定位三板斧


OOM(OutOfMemoryError) 问题归根结底三点原因
  • 本身资源不够

  • 申请的太多内存

  • 资源耗尽


解决思路,换成Java服务分析,三个原因也可以解读为
  • 有可能是内存分配确实过小,而正常业务使用了大量内存

  • 某一个对象被频繁申请,却没有释放,内存不断泄漏,导致内存耗尽

  • 某一个资源被频繁申请,系统资源耗尽,例如:不断创建线程,不断发起网络连接


因此,针对解决思路,快速定位OOM问题的三板斧是
  • 确认是不是内存本身就分配过小

  • 找到最耗内存的对象

  • 确认是否是资源耗尽


以正式线上的tomcat为例,tomcat运行5个ssm架构的java项目,启动时需要60秒左右,运行一段时间偶尔会有OOM出现,现在逐一排查:

(1) 确认是不是内存本身就分配过小

  • 在服务器(8核16G)上输入 top 查看 java启动时内存变化情况,顺便找到java的进程ID : 1246


这里写图片描述


  • 然后, 输入:jmap -heap 1246,观察堆、新生代、老年代的内存使用情况,发现大概都用了一半,可以确定,不是内存分配过小问题。
wen@S189919:/opt/tomcat8$ jmap -heap 1246
Attaching to process ID 1246, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.65-b04

using thread-local object allocation.
Parallel GC with 8 thread(s)

Heap Configuration:
   MinHeapFreeRatio = 0
   MaxHeapFreeRatio = 100
   MaxHeapSize      = 4208984064 (4014.0MB)
   NewSize          = 1310720 (1.25MB)
   MaxNewSize       = 17592186044415 MB
   OldSize          = 5439488 (5.1875MB)
   NewRatio         = 2
   SurvivorRatio    = 8
   PermSize         = 21757952 (20.75MB)
   MaxPermSize      = 85983232 (82.0MB)
   G1HeapRegionSize = 0 (0.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 1172307968 (1118.0MB)
   used     = 679248008 (647.781379699707MB)
   free     = 493059960 (470.21862030029297MB)
   57.94108941857845% used
From Space:
   capacity = 85983232 (82.0MB)
   used     = 0 (0.0MB)
   free     = 85983232 (82.0MB)
   0.0% used
To Space:
   capacity = 115343360 (110.
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值