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

叁歲伎倆 2022-06-09 11:20 312阅读 0赞

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

#### **OOM(OutOfMemoryError) 问题归根结底三点原因**： ####

*  **本身资源不够**
 *  **申请的太多内存**
 *  **资源耗尽**

#### **解决思路，换成Java服务分析，三个原因也可以解读为**： ####

*  **有可能是内存分配确实过小，而正常业务使用了大量内存**
 *  **某一个对象被频繁申请，却没有释放，内存不断泄漏，导致内存耗尽**
 *  **某一个资源被频繁申请，系统资源耗尽，例如：不断创建线程，不断发起网络连接**

#### **因此，针对解决思路，快速定位OOM问题的三板斧是**： ####

*  **确认是不是内存本身就分配过小**
 *  **找到最耗内存的对象**
 *  **确认是否是资源耗尽**

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

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

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

![这里写图片描述][SouthEast]

*  然后， 输入：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.0MB)
       used     = 0 (0.0MB)
       free     = 115343360 (110.0MB)
       0.0% used
    PS Old Generation
       capacity = 259522560 (247.5MB)
       used     = 147065016 (140.25212860107422MB)
       free     = 112457544 (107.24787139892578MB)
       56.667526707504734% used
    PS Perm Generation
       capacity = 63963136 (61.0MB)
       used     = 32219528 (30.72693634033203MB)
       free     = 31743608 (30.27306365966797MB)
       50.37202678742956% used
    
    16612 interned Strings occupying 2080416 bytes.

(2) 找到最耗内存的对象

*  jmap -histo:live 1246| more
    
    输入命令后，会以表格的形式显示存活对象的信息，并按照所占内存大小排序：
    
     *  实例数
     *  所占内存大小
     *  类名
    
    通过观察，虽然我不知道 \[B 是什么类，但是最大也只有72M，对内存来说简直没有知觉。
    
    如果发现某类对象占用内存很大（例如几个G），很可能是类对象创建太多，且一直未释放。例如：
    
     *  申请完资源后，未调用close()或dispose()释放资源
     *  消费者消费速度慢（或停止消费了），而生产者不断往队列中投递任务，导致队列中任务累积过多

wen@S189919:/opt/tomcat8$ jmap -histo:live 1246 | more
    
     num     #instances #bytes class name
    ----------------------------------------------
       1:         79073       72095344  [B
       2:        103049       13630576  [C
       3:         57516        8155328  <constMethodKlass>
       4:         57516        7373456  <methodKlass>
       5:          5413        6128216  <constantPoolKlass>
       6:          5413        3861128  <instanceKlassKlass>
       7:          4455        3264960  <constantPoolCacheKlass>
       8:        101128        2427072  java.lang.String
       9:         46704        1868160  java.lang.ref.Finalizer
      10:          5314        1486584  [Ljava.util.HashMap$Entry;
      11:         22264        1419160  [Ljava.lang.Object;
      12:         17286        1382880  java.lang.reflect.Method
      13:         20810        1165360  java.util.zip.ZipFile$ZipFileInputStream
      14:         20389        1141784  java.util.zip.ZipFile$ZipFileInflaterInputStream
      15:         34592        1106944  java.util.HashMap$Entry
      16:          1963        1075048  <methodDataKlass>
      17:          1762         943992  [I
      18:         22136         708352  java.util.concurrent.ConcurrentHashMap$HashEntry
      19:          5866         704008  java.lang.Class
      20:         14549         581960  java.util.LinkedHashMap$Entry
      21:         21158         507792  java.util.ArrayList
      22:          7742         453448  [S
      23:          8839         450464  [[I
      24:          7362         412272  java.util.LinkedHashMap
      25:          3735         328416  [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
      26:         14544         322536  [Ljava.lang.Class;
      27:          7350         294000  com.sun.org.apache.xerces.internal.dom.DeferredTextImpl
      28:          2973         273488  [Ljava.util.WeakHashMap$Entry;
      29:          6660         266400  com.sun.org.apache.xerces.internal.dom.DeferredAttrImpl
      30:          5394         258912  java.util.HashMap
      31:          6441         257640  javax.servlet.jsp.tagext.TagAttributeInfo
      32:           436         237184  <objArrayKlassKlass>
      33:         14200         227200  java.lang.Object
      34:          2783         222640  sun.net.www.protocol.jar.URLJarFile
      35:          3914         219184  com.sun.org.apache.xerces.internal.dom.DeferredElementImpl
      36:          6016         192512  java.util.concurrent.locks.ReentrantLock$NonfairSync
      37:          4328         173120  java.lang.ref.SoftReference
      38:          2970         166320  java.util.WeakHashMap
      39:          3200         153184  [Ljava.lang.String;
      40:          3735         149400  java.util.concurrent.ConcurrentHashMap$Segment

(3) 确认是否是资源耗尽

*  通过查看 sshd 进程，得出句柄详情和线程数
    
     *  /proc/$\{PID\}/fd
     *  /proc/$\{PID\}/task

最终的结果句柄数和线程数8和4，更不可能引发内存溢出

root@S189919:/home/wen# ps -aux | grep sshd
    Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html
    root       749  0.0  0.0  50036  2928 ?        Ss   19:01   0:00 /usr/sbin/sshd -D
    root      1321  0.0  0.0  73440  3608 ?        Ss   19:15   0:00 sshd: wen [priv]
    wen       1464  0.0  0.0  73440  1528 ?        S    19:15   0:00 sshd: wen@pts/0
    root      1585  0.0  0.0   9388   940 pts/0    S+   19:20   0:00 grep --color=auto sshd
    root@S189919:/home/wen# ll /proc/749/fd
    total 0
    dr-x------ 2 root root  0 Sep  4 19:01 ./
    dr-xr-xr-x 8 root root  0 Sep  4 19:01 ../
    lrwx------ 1 root root 64 Sep  4 19:01 0 -> /dev/null
    lrwx------ 1 root root 64 Sep  4 19:01 1 -> /dev/null
    lrwx------ 1 root root 64 Sep  4 19:01 2 -> /dev/null
    lr-x------ 1 root root 64 Sep  4 19:01 3 -> socket:[7330]
    lrwx------ 1 root root 64 Sep  4 19:21 4 -> socket:[7332]
    root@S189919:/home/wen# ll /proc/749/task
    total 0
    dr-xr-xr-x 3 root root 0 Sep  4 19:21 ./
    dr-xr-xr-x 8 root root 0 Sep  4 19:01 ../
    dr-xr-xr-x 6 root root 0 Sep  4 19:21 749/
    root@S189919:/home/wen# ll /proc/749/fd | wc -l
    8
    root@S189919:/home/wen# ll /proc/749/task | wc -l
    4

(4) 合并相同的 jar 包

*  最后，想来想去，很有可能是项目启动时加载太多第三方jar包，于是，将5个ssm的jar包合并，覆盖掉相同的，放在tomcat的shared lib目录：

修改 ${ TOMCAT_HOME }/conf/catalina.properties文件中shared.loader= ${catalina.base}/shared/lib,${catalina.base}/shared/lib/*.jar  也可以将公用的jar全部放置${ TOMCAT_HOME }/lib包下

启动tomcat，加载完用了37秒，但愿能解决OOM问题，从此不再被领导说。

[OOM]: https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651960342&idx=1&sn=9b2dbbb2cfd7710f25be1a0862a9b2be&chksm=bd2d01ca8a5a88dcc14608cb00e0dbde11869d053ee8c83bc96e7b4a0fbd71d28d7fbb009c98&mpshare=1&scene=1&srcid=0821vNW5OUio7lHSX9dnLSC2#rd
[SouthEast]: /images/20220609/9e6e80ae8f83463690c4ebb4d2f004e8.png