教你如何成為Java的OOM Killer
前言
雖然事隔半年，當時排查線上OOM事故的過程記憶猶新，每一個步驟都歷歷在目，感謝業(yè)務組、系統(tǒng)部、壓測組、監(jiān)控與應急部對架構組的強力支持，得以讓這個Java內存問題水落石出，經過半年多的全面的應用日志切割方式的改造，現(xiàn)在基本沒有OOM的問題了，線上服務運行非常健康，對可用性的保障起到了很大的作用，如果你在經歷OOM，讀了這個文章會有很大的啟發(fā)。
Become OOM Killer
我們都知道JVM的內存管理是自動化的，Java語言的程序指針也不需要開發(fā)人員手工釋放，JVM的GC會自動的進行回收，但是，如果編程不當，JVM仍然會發(fā)生內存泄露，導致Java程序產生了OutOfMemoryError(OOM)錯誤。
產生OutOfMemoryError錯誤的原因包括：
- java.lang.OutOfMemoryError: Java heap space
- java.lang.OutOfMemoryError: PermGen space及其解決方法
- java.lang.OutOfMemoryError: unable to create new native thread
- java.lang.OutOfMemoryError：GC overhead limit exceeded
對于第1種異常，表示Java堆空間不夠，當應用程序申請更多的內存，而Java堆內存已經無法滿足應用程序對內存的需要，將拋出這種異常。
對于第2種異常，表示Java永久帶(方法區(qū))空間不夠，永久帶用于存放類的字節(jié)碼和長常量池，類的字節(jié)碼加載后存放在這個區(qū)域，這和存放對象實例的堆區(qū)是不同的，大多數(shù)JVM的實現(xiàn)都不會對永久帶進行垃圾回收，因此，只要類加載的過多就會出現(xiàn)這個問題。一般的應用程序都不會產生這個錯誤，然而，對于Web服務器來講，會產生有大量的JSP，JSP在運行時被動態(tài)的編譯成Java Servlet類，然后加載到方法區(qū)，因此，太多的JSP的Web工程可能產生這個異常。
對于第3種異常，本質原因是創(chuàng)建了太多的線程，而能創(chuàng)建的線程數(shù)是有限制的，導致了這種異常的發(fā)生。
對于第4種異常，是在并行或者并發(fā)回收器在GC回收時間過長、超過98%的時間用來做GC并且回收了不到2%的堆內存，然后拋出這種異常進行提前預警，用來避免內存過小造成應用不能正常工作。
下面兩個異常與OOM有關系，但是，又沒有絕對關系。
- java.lang.StackOverflowError ...
- java.net.SocketException: Too many open files
對于第1種異常，是JVM的線程由于遞歸或者方法調用層次太多，占滿了線程堆棧而導致的，線程堆棧默認大小為1M。
對于第2種異常，是由于系統(tǒng)對文件句柄的使用是有限制的，而某個應用程序使用的文件句柄超過了這個限制，就會導致這個問題。
上面介紹了OOM相關的基礎知識，接下來我們開始講述筆者經歷的一次OOM問題的定位和解決的過程。
1. 產生問題的現(xiàn)象
在某一段時間內，我們發(fā)現(xiàn)不同的業(yè)務服務開始偶發(fā)的報OOM的異常，有的時候是白天發(fā)生，有的時候是晚上發(fā)生，有的時候是基礎服務A發(fā)生，有的時候是上層服務B發(fā)生，有的時候是上層服務C發(fā)生，有的時候是下層服務D發(fā)生，絲毫看不到一點規(guī)律。
產生問題的異常如下：
- Caused by: java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method)
- at java.lang.Thread.start(Thread.java:597)
- at java.util.Timer.<init>(Timer.java:154)
2. 解決問題的思路和過程
經過細心觀察發(fā)現(xiàn)，產生問題雖然在不同的時間發(fā)生在不同的服務池，但是，晚上0點發(fā)生的時候概率較大，也有其他時間偶發(fā)，但是都在整點。
這個規(guī)律很重要，雖然不是一個時間，但是基本都在整點左右發(fā)生，并且晚上0點居多。從這個角度思考，整點或者0點系統(tǒng)是否有定時，與出問題的每個業(yè)務系統(tǒng)技術負責人核實，0點沒有定時任務，其他時間的整點有定時任務，但是與發(fā)生問題的時間不吻合，這個思路行不通。
到現(xiàn)在為止，從現(xiàn)象的規(guī)律上我們已經沒法繼續(xù)分析下去了，那我們回顧一下錯誤本身：
- java.lang.OutOfMemoryError: unable to create new native thread
顧名思義，錯誤產生的原因就是應用不能創(chuàng)建線程了，但是，應用還需要創(chuàng)建線程。為什么程序不能創(chuàng)建線程呢?
有兩個具體原因造成這個異常:
- 由于線程使用的資源過多，操作系統(tǒng)已經不能再提供給應用資源了。
- 操作系統(tǒng)設置了應用創(chuàng)建線程的最大數(shù)量，并且已經達到了最大允許數(shù)量。
上面第1條資源指的是內存，而第2條中，在Linux下線程使用輕量級進程實現(xiàn)的，因此線程的最大數(shù)量也是操作系統(tǒng)允許的進程的最大數(shù)量。
內存計算
操作系統(tǒng)中的最大可用內存除去操作系統(tǒng)本身使用的部分，剩下的都可以為某一個進程服務，在JVM進程中，內存又被分為堆、本地內存和棧等三大塊，Java堆是JVM自動管理的內存，應用的對象的創(chuàng)建和銷毀、類的裝載等都發(fā)生在這里，本地內存是Java應用使用的一種特殊內存，JVM并不直接管理其生命周期，每個線程也會有一個棧，是用來存儲線程工作過程中產生的方法局部變量、方法參數(shù)和返回值的，每個線程對應的棧的默認大小為1M。
Linux和JVM的內存管理示意圖如下：
內存結構模型
因此，從內存角度來看創(chuàng)建線程需要內存空間，如果JVM進程正當一個應用創(chuàng)建線程，而操作系統(tǒng)沒有剩余的內存分配給此JVM進程，則會拋出問題中的OOM異常：unable to create new native thread。
如下公式可以用來從內存角度計算允許創(chuàng)建的最大線程數(shù)：
- 最大線程數(shù) = (操作系統(tǒng)最大可用內存 - JVM內存 - 操作系統(tǒng)預留內存)/ 線程棧大小
根據(jù)這個公式，我們可以通過剩余內存計算可以創(chuàng)建線程的數(shù)量。
下面是問題出現(xiàn)的時候，從生產機器上執(zhí)行前面小節(jié)介紹的Linux命令free的輸出：
- free -m >> /tmp/free.log
- total used free shared buffers cached
- Mem: 7872 7163 709 0 31 3807
- -/+ buffers/cache: 3324 4547
- Swap: 4095 173 3922
- Tue Jul 5 00:27:51 CST 2016
從上面輸出可以得出，生產機器8G內存，使用了7G，剩余700M可用，其中操作系統(tǒng)cache使用3.8G。操作系統(tǒng)cache使用的3.8G是用來緩存IO數(shù)據(jù)的，如果進程內存不夠用，這些內存是可以釋放出來優(yōu)先分配給進程使用。然而，我們暫時并不需要考慮這塊內存，剩余的700M空間完全可以繼續(xù)用來創(chuàng)建線程數(shù)：
- 700M / 1M = 700個線程
因此，根據(jù)內存可用計算，當OOM異常：unable to create new native thread問題發(fā)生的時候，還有700M可用內存，可以創(chuàng)建700個線程。
到現(xiàn)在為止可以證明此次OOM異常不是因為線程吃光所有的內存而導致的。
線程數(shù)對比
上面提到，有兩個具體原因造成這個異常，我們上面已經排除了第1個原因，那我們現(xiàn)在從第2個原因入手，評估是否操作系統(tǒng)設置了應用創(chuàng)建線程的最大數(shù)量，并且已經達到了最大允許數(shù)量。
在問題出現(xiàn)的生產機器上使用ulimit -a來顯示當前的各種系統(tǒng)對用戶使用資源的限制：
- robert@robert-ubuntu1410：~$ ulimit -a
- core file size (blocks, -c) 0
- data seg size (kbytes, -d) unlimited
- scheduling priority (-e) 0
- file size (blocks, -f) unlimited
- pending signals (-i) 62819
- max locked memory (kbytes, -l) 64
- max memory size (kbytes, -m) unlimited
- open files (-n) 65535
- pipe size (512 bytes, -p) 8
- POSIX message queues (bytes, -q) 819200
- real-time priority (-r) 0
- stack size (kbytes, -s) 10240
- cpu time (seconds, -t) unlimited
- max user processes (-u) 1024
- virtual memory (kbytes, -v) unlimited
- file locks (-x) unlimited
這里面我們看到生產機器設置的允許使用的最大用戶進程數(shù)為1024：
- max user processes (-u) 1024
現(xiàn)在，我們必須獲得問題出現(xiàn)的時候，用戶下創(chuàng)建的線程情況。
在問題產生的時候，我們使用前面小結介紹的JVM監(jiān)控命令jstack命令打印出了Java線程情況,jstack命令的示例輸出如下：
- robert@robert-ubuntu1410:~$ jstack 2743
- 2017-04-09 12:06:51
- Full thread dump Java HotSpot(TM) Server VM (25.20-b23 mixed mode):
- "Attach Listener" #23 daemon prio=9 os_prio=0 tid=0xc09adc00 nid=0xb4c waiting on condition [0x00000000]
- java.lang.Thread.State: RUNNABLE
- "http-nio-8080-Acceptor-0" #22 daemon prio=5 os_prio=0 tid=0xc3341000 nid=0xb02 runnable [0xbf1bd000]
- java.lang.Thread.State: RUNNABLE
- at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
- at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:241)
- - locked <0xcf8938d8> (a java.lang.Object)
- at org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:688)
- at java.lang.Thread.run(Thread.java:745)
- "http-nio-8080-ClientPoller-1" #21 daemon prio=5 os_prio=0 tid=0xc35bc400 nid=0xb01 runnable [0xbf1fe000]
- java.lang.Thread.State: RUNNABLE
- at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
- at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
- at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
- at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- - locked <0xcf99b100> (a sun.nio.ch.Util$2)
- - locked <0xcf99b0f0> (a java.util.Collections$UnmodifiableSet)
- - locked <0xcf99aff8> (a sun.nio.ch.EPollSelectorImpl)
- at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
- at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1052)
- at java.lang.Thread.run(Thread.java:745)
- ......
從jstack命令的輸出并統(tǒng)計后，我們得知，JVM一共創(chuàng)建了904個線程，但是，這還沒有到最大的進程限制1024。
- robert@robert-ubuntu1410:~$ grep "Thread " js.log | wc -l
- 904
這是我們思考，除了JVM創(chuàng)建的應用層線程，JVM本身可能會有一些管理線程存在，而且操作系統(tǒng)內用戶下可能也會有守護線程在運行。
我們繼續(xù)從操作系統(tǒng)的角度來統(tǒng)計線程數(shù)，我們使用上面小結介紹的Linux操作系統(tǒng)命令pstack，并得到如下的輸出：
- PID LWP USER %CPU %MEM CMD
- 1 1 root 0.0 0.0 /sbin/init
- 2 2 root 0.0 0.0 [kthreadd]
- 3 3 root 0.0 0.0 [migration/0]
- 4 4 root 0.0 0.0 [ksoftirqd/0]
- 5 5 root 0.0 0.0 [migration/0]
- 6 6 root 0.0 0.0 [watchdog/0]
- 7 7 root 0.0 0.0 [migration/1]
- 8 8 root 0.0 0.0 [migration/1]
- 9 9 root 0.0 0.0 [ksoftirqd/1]
- 10 10 root 0.0 0.0 [watchdog/1]
- 11 11 root 0.0 0.0 [migration/2]
- 12 12 root 0.0 0.0 [migration/2]
- 13 13 root 0.0 0.0 [ksoftirqd/2]
- 14 14 root 0.0 0.0 [watchdog/2]
- 15 15 root 0.0 0.0 [migration/3]
- 16 16 root 0.0 0.0 [migration/3]
- 17 17 root 0.0 0.0 [ksoftirqd/3]
- 18 18 root 0.0 0.0 [watchdog/3]
- 19 19 root 0.0 0.0 [events/0]
- 20 20 root 0.0 0.0 [events/1]
- 21 21 root 0.0 0.0 [events/2]
- 22 22 root 0.0 0.0 [events/3]
- 23 23 root 0.0 0.0 [cgroup]
- 24 24 root 0.0 0.0 [khelper]
- ......
- 7257 7257 zabbix 0.0 0.0 /usr/local/zabbix/sbin/zabbix_agentd: active checks #2 [idle 1 sec]
- 7258 7258 zabbix 0.0 0.0 /usr/local/zabbix/sbin/zabbix_agentd: active checks #3 [idle 1 sec]
- 7259 7259 zabbix 0.0 0.0 /usr/local/zabbix/sbin/zabbix_agentd: active checks #4 [idle 1 sec]
- ......
- 9040 9040 app 0.0 30.5 /apps/prod/jdk1.6.0_24/bin/java -Dnop -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Ddbconfigpath=/apps/dbconfig/ -Djava.io.tmpdir=/apps/data/java-tmpdir -server -Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=512m -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=192.168.10.194 -Dcom.sun.management.jmxremote.port=6969 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Xshare:off -Dhostname=sjsa-trade04 -Djute.maxbuffer=41943040 -Djava.net.preferIPv4Stack=true -Dfile.encoding=UTF-8 -Dworkdir=/apps/data/tomcat-work -Djava.endorsed.dirs=/apps/product/tomcat-trade/endorsed -classpath commonlib:/apps/product/tomcat-trade/bin/bootstrap.jar:/apps/product/tomcat-trade/bin/tomcat-juli.jar -Dcatalina.base=/apps/product/tomcat-trade -Dcatalina.home=/apps/product/tomcat-trade -Djava.io.tmpdir=/apps/data/tomcat-temp/ org.apache.catalina.startup.Bootstrap start
- 9040 9041 app 0.0 30.5 /apps/prod/jdk1.6.0_24/bin/java -Dnop -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Ddbconfigpath=/apps/dbconfig/ -Djava.io.tmpdir=/apps/data/java-tmpdir -server -Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=512m -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=192.168.10.194 -Dcom.sun.management.jmxremote.port=6969 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Xshare:off -Dhostname=sjsa-trade04 -Djute.maxbuffer=41943040 -Djava.net.preferIPv4Stack=true -Dfile.encoding=UTF-8 -Dworkdir=/apps/data/tomcat-work -Djava.endorsed.dirs=/apps/product/tomcat-trade/endorsed -classpath commonlib:/apps/product/tomcat-trade/bin/bootstrap.jar:/apps/product/tomcat-trade/bin/tomcat-juli.jar -Dcatalina.base=/apps/product/tomcat-trade -Dcatalina.home=/apps/product/tomcat-trade -Djava.io.tmpdir=/apps/data/tomcat-temp/ org.apache.catalina.startup.Bootstrap start
- ......
通過命令統(tǒng)計用戶下已經創(chuàng)建的線程數(shù)為1021。
- $ grep app pthreads.log | wc -l
- 1021
現(xiàn)在我們確定，1021的數(shù)字已經相當?shù)慕咏?021的最大進程數(shù)了，正如前面我們提到，在Linux操作系統(tǒng)里，線程是通過輕量級的進程實現(xiàn)的，因此，限制用戶的最大進程數(shù)，就是限制用戶的最大線程數(shù)，至于為什么沒有精確達到1024這個最大值就已經報出異常，應該是系統(tǒng)的自我保護功能，在還剩下3個線程的前提下，就開始報錯。
到此為止，我們已經通過分析來找到問題的原因，但是，我們還是不知道為什么會創(chuàng)建這么多的線程，從第一個輸出得知，JVM已經創(chuàng)建的應用線程有907個，那么他們都在做什么事情呢?
于是，在問題發(fā)生的時候，我們又使用JVM的jstack命令，查看輸出得知，每個線程都阻塞在打印日志的語句上，log4j中打印日志的代碼實現(xiàn)如下：
- public void callAppenders(LoggingEvent event) {
- int writes = 0;
- for(Category c = this; c != null; c=c.parent) {
- // Protected against simultaneous call to addAppender, removeAppender,...
- synchronized(c) {
- if(c.aai != null) {
- writes += c.aai.appendLoopOnAppenders(event);
- }
- if(!c.additive) {
- break;
- }
- }
- }
- if(writes == 0) {
- repository.emitNoAppenderWarning(this);
- }
- }
在log4j中，打印日志有一個鎖，鎖的作用是讓打印日志可以串行，保證日志在日志文件中的正確性和順序性。
那么，新的問題又來了，為什么只有凌晨0點會出現(xiàn)打印日志阻塞，其他時間會偶爾發(fā)生呢?這時，我們帶著新的線索又回到問題開始的思路，凌晨12點應用沒有定時任務，系統(tǒng)會不會有其他的IO密集型的任務，比如說歸檔日志、磁盤備份等?
經過與運維部門碰頭，基本確定是每天凌晨0點日志切割導致磁盤IO被占用，于是堵塞打印日志，日志是每個工作任務都必須的，日志阻塞，線程池就阻塞，線程池阻塞就導致線程池被撐大，線程池里面的線程數(shù)超過1024就會報錯。
到這里，我們基本確定了問題的原因，但是還需要對日志切割導致IO增大進行分析和論證。
首先我們使用前面小結介紹的vmstat查看問題發(fā)生時IO等待數(shù)據(jù)：
- vmstat 2 1 >> /tmp/vm.log
- procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
- r b swpd free buff cache si so bi bo in cs us sy id wa st
- 3 0 177608 725636 31856 3899144 0 0 2 10 0 0 39 1 1 59 0
- Tue Jul 5 00:27:51 CST 2016
可見，問題發(fā)生的時候，CPU的IO等待為59%，同時又與運維部門同事復盤，運維同事確認，腳本切割通過cat命令方法，先把日志文件cat后，通過管道打印到另外一個文件，再清空原文件，因此，一定會導致IO的上升。
其實，問題的過程中，還有一個疑惑，我們認為線程被IO阻塞，線程池被撐開，導致線程增多，于是，我們查看了一下Tomcat線程池的設置，我們發(fā)現(xiàn)Tomcat線程池設置了800，按理說，永遠不會超過1024。
- <Connector port="8080"
- maxThreads="800" minSpareThreads="25" maxSpareThreads="75"
- enableLookups="false" redirectPort="8443" acceptCount="100"
- debug="0" connectionTimeout="20000"
- disableUploadTimeout="true" />
關鍵在于，筆者所在的支付平臺服務化架構中，使用了兩套服務化框架，一個是基于dubbo的框架，一個是點對點的RPC，用來緊急情況下dubbo服務出現(xiàn)問題，服務降級使用。
每個服務都配置了點對點的RPC服務，并且獨享一個線程池：
- <Connector port="8090"
- maxThreads="800" minSpareThreads="25" maxSpareThreads="75"
- enableLookups="false" redirectPort="8443" acceptCount="100"
- debug="0" connectionTimeout="20000"
- disableUploadTimeout="true" />
由于我們在對dubbo服務框架進行定制化的時候，設計了自動降級原則，如果dubbo服務負載變高，會自動切換到點對點的RPC框架，這也符合微服務的失效轉移原則，但是設計中沒有進行全面的考慮，一旦一部分服務切換到了點對點的RPC，而一部分的服務沒有切換，就導致兩個現(xiàn)場池都被撐滿，于是超過了1024的限制，就出了問題。
到這里，我們基本可以驗證，問題的根源是日志切割導致IO負載增加，然后阻塞線程池，最后發(fā)生OOM：unable to create new native thread。
剩下的任務就是最小化重現(xiàn)的問題，通過實踐來驗證問題的原因。我們與性能壓測部門溝通，提出壓測需求：
- Tomcat線程池最大設置為1500.
- 操作系統(tǒng)允許的最大用戶進程數(shù)1024.
- 在給服務加壓的過程中，需要人工制造繁忙的IO操作，IO等待不得低于50%。
經過壓測壓測部門的一下午努力，環(huán)境搞定，結果證明完全可以重現(xiàn)此問題。
最后，與所有相關部門討論和復盤，應用解決方案，解決方案包括：
- 全部應用改成按照小時切割，或者直接使用log4j的日志滾動功能。
- Tomcat線程池的線程數(shù)設置與操作系統(tǒng)的線程數(shù)設置不合理，適當?shù)臏p少Tomcat線程池線程數(shù)量的大小。
- 升級log4j日志，使用logback或者log4j2。
這次OOM問題的可以歸結為“多個因、多個果、多臺機器、多個服務池、不同時間”，針對這個問題，與運維部、監(jiān)控部和性能壓測部門的同事奮斗了幾天幾夜，終于通過在線上抓取信息、分析問題、在性能壓測部門同事的幫助下，最小化重現(xiàn)問題并找到問題的根源原因，最后，針對問題產生的根源提供了有效的方案。
3. 與監(jiān)控同事現(xiàn)場編寫的腳本
本節(jié)提供一個筆者在實踐過程中解決OOM問題的一個簡單腳本，這個腳本是為了解決OOM(unable to create native thread)的問題而在問題機器上臨時編寫，并臨時使用的，腳本并沒有寫的很專業(yè)，筆者也沒有進行優(yōu)化，保持原汁原味的風格，這樣能讓讀者有種身臨其境的感覺，只是為了抓取需要的信息并解決問題，但是在線上問題十分火急的情況下，這個腳本會有大用處。
- #!/bin/bash
- ps -Leo pid,lwp,user,pcpu,pmem,cmd >> /tmp/pthreads.log
- echo "ps -Leo pid,lwp,user,pcpu,pmem,cmd >> /tmp/pthreads.log" >> /tmp/pthreads.log
- echo `date` >> /tmp/pthreads.log
- echo 1
- pid=`ps aux|grep tomcat|grep cwh|awk -F ' ' '{print $2}'`
- echo 2
- echo "pstack $pid >> /tmp/pstack.log" >> /tmp/pstack.log
- pstack $pid >> /tmp/pstack.log
- echo `date` >> /tmp/pstack.log
- echo 3
- echo "lsof >> /tmp/sys-o-files.log" >> /tmp/sys-o-files.log
- lsof >> /tmp/sys-o-files.log
- echo `date` >> /tmp/sys-o-files.log
- echo 4
- echo "lsof -p $pid >> /tmp/service-o-files.log" >> /tmp/service-o-files.log
- lsof -p $pid >> /tmp/service-o-files.log
- echo `date` >> /tmp/service-o-files.log
- echo 5
- echo "jstack -l $pid >> /tmp/js.log" >> /tmp/js.log
- jstack -l -F $pid >> /tmp/js.log
- echo `date` >> /tmp/js.log
- echo 6
- echo "free -m >> /tmp/free.log" >> /tmp/free.log
- free -m >> /tmp/free.log
- echo `date` >> /tmp/free.log
- echo 7
- echo "vmstat 2 1 >> /tmp/vm.log" >> /tmp/vm.log
- vmstat 2 1 >> /tmp/vm.log
- echo `date` >> /tmp/vm.log
- echo 8
- echo "jmap -dump:format=b,file=/tmp/heap.hprof 2743" >> /tmp/jmap.log
- jmap -dump:format=b,file=/tmp/heap.hprof >> /tmp/jmap.log
- echo `date` >> /tmp/jmap.log
- echo 9
- echo end
如果讀者在線上已經遇到了OOM的問題，可以順著這個看似簡陋而又信息滿滿的Java服務的監(jiān)控腳本的思路，利用本文提供的各種腳本和命令來深挖問題的根本原因。
點擊《教你如何成為Java的OOM Killer》閱讀原文。
【本文為51CTO專欄作者“李艷鵬”的原創(chuàng)稿件，轉載可通過作者簡書號(李艷鵬)或51CTO專欄獲取聯(lián)系】
