Java OOM原因以及问题分析排查步骤

Java服务OOM，最常见的原因为：

（1）有可能是内存分配确实过小，而正常业务需要使用更大的内存；

（2）某一个对象被频繁申请，却没有释放，内存不断泄露，导致内存耗尽；

（3）某一个资源被不断申请，系统资源耗尽，例如：不断创建线程，不断发起网络连接

排查过程

如果知道具体服务和接口，可以ps -ef|grep java查看pid

1. jmap -heap pid 确认内存本身是否分配过小，可以看到新生代老生代的参数配置

[root@bird74 ~]# jmap -heap 6598
Attaching to process ID 6598, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.161-b12

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

Heap Configuration:
   MinHeapFreeRatio         = 0
   MaxHeapFreeRatio         = 100
   MaxHeapSize              = 32210157568 (30718.0MB)
   NewSize                  = 715653120 (682.5MB)
   MaxNewSize               = 10736369664 (10239.0MB)
   OldSize                  = 1431830528 (1365.5MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 3437756416 (3278.5MB)
   used     = 442139392 (421.656982421875MB)
   free     = 2995617024 (2856.843017578125MB)
   12.861277487322708% used
From Space:
   capacity = 81788928 (78.0MB)
   used     = 19657352 (18.74671173095703MB)
   free     = 62131576 (59.25328826904297MB)
   24.03424580891927% used
To Space:
   capacity = 117440512 (112.0MB)
   used     = 0 (0.0MB)
   free     = 117440512 (112.0MB)
   0.0% used
PS Old Generation
   capacity = 2432696320 (2320.0MB)
   used     = 131810152 (125.7039566040039MB)
   free     = 2300886168 (2194.296043395996MB)
   5.418273991551892% used

51800 interned Strings occupying 5721192 bytes.

2. 查看该pid下线程对应的系统占用情况

top -Hp pid

3. 找到最耗内存的对象

jmap -histo:live pid | more

输入命令后，会以表格的形式显示存活对象的信息，并按照所占内存大小排序：

字段分别代表实例数；所占内存大小；类名

4. 测试堆栈溢出：jstat -gcutil <pid> 时间间隔毫秒；看下是否正常

S0：幸存1区当前使用比例

S1：幸存2区当前使用比例

E：伊甸园区使用比例

O：老年代使用比例

M：元数据区使用比例

CCS：压缩使用比例

YGC：年轻代垃圾回收次数

YGCT：年轻代垃圾回收时间

FGC：老年代垃圾回收次数

FGCT：老年代垃圾回收消耗时间

GCT：垃圾回收消耗总时间

5. 生成对应pid的dump文件

jmap -dump:format=b,file=heap.hprof <pid>

注意：pid对应的项目是哪个用户启动的，就用哪个用户权限生成文件，否则会报错 Unable to open socket file: target process not responding or HotSpot VM not loaded

6. heap.hprof文件导出用MAT分析，可以用sz导出

Histogram可以列出内存中的对象，对象的个数以及大小。
Dominator Tree可以列出那个线程，以及线程下面的那些对象占用的空间。
Top consumers通过图形列出最大的object。
Leak Suspects通过MA自动分析泄漏的原因

更多MAT使用教程还是查一下吧

主要的流程在这里，大家可以根据自己情况选择

问题出来了要最快定位问题，紧急解决眼前问题让业务正常，然后再优化

Java OOM原因以及问题分析排查步骤

猜你喜欢