线上java.lang.OutOfMemoryError问题定位三板斧_线上项目报out of memory-优快云博客

本文链接：https://blog.youkuaiyun.com/change_on/article/details/77841989

本文介绍了如何定位和解决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.