JAVA 線上故障排查完整套路，從 CPU、磁盤、內(nèi)存、網(wǎng)絡(luò)、GC 一條龍！

線上故障主要會包括cpu、磁盤、內(nèi)存以及網(wǎng)絡(luò)問題，而大多數(shù)故障可能會包含不止一個層面的問題，所以進行排查時候盡量四個方面依次排查一遍。

同時例如jstack、jmap等工具也是不囿于一個方面的問題的，基本上出問題就是df、free、top 三連，然后依次jstack、jmap伺候，具體問題具體分析即可。

CPU

一般來講我們首先會排查cpu方面的問題。cpu異常往往還是比較好定位的。原因包括業(yè)務(wù)邏輯問題(死循環(huán))、頻繁gc以及上下文切換過多。而最常見的往往是業(yè)務(wù)邏輯(或者框架邏輯)導致的，可以使用jstack來分析對應(yīng)的堆棧情況。

使用jstack分析cpu問題

我們先用ps命令找到對應(yīng)進程的pid(如果你有好幾個目標進程，可以先用top看一下哪個占用比較高)。

接著用top -H -p pid來找到cpu使用率比較高的一些線程

然后將占用最高的pid轉(zhuǎn)換為16進制printf '%x\n' pid得到nid

接著直接在jstack中找到相應(yīng)的堆棧信息jstack pid |grep 'nid' -C5 –color

可以看到我們已經(jīng)找到了nid為0x42的堆棧信息，接著只要仔細分析一番即可。

當然更常見的是我們對整個jstack文件進行分析，通常我們會比較關(guān)注WAITING和TIMED_WAITING的部分，BLOCKED就不用說了。我們可以使用命令cat jstack.log | grep "java.lang.Thread.State" | sort -nr | uniq -c來對jstack的狀態(tài)有一個整體的把握，如果WAITING之類的特別多，那么多半是有問題啦。

頻繁gc

當然我們還是會使用jstack來分析問題，但有時候我們可以先確定下gc是不是太頻繁，使用jstat -gc pid 1000命令來對gc分代變化情況進行觀察，1000表示采樣間隔(ms)，S0C/S1C、S0U/S1U、EC/EU、OC/OU、MC/MU分別代表兩個Survivor區(qū)、Eden區(qū)、老年代、元數(shù)據(jù)區(qū)的容量和使用量。YGC/YGT、FGC/FGCT、GCT則代表YoungGc、FullGc的耗時和次數(shù)以及總耗時。如果看到gc比較頻繁，再針對gc方面做進一步分析。

上下文切換

針對頻繁上下文問題，我們可以使用vmstat命令來進行查看

cs(context switch)一列則代表了上下文切換的次數(shù)。

如果我們希望對特定的pid進行監(jiān)控那么可以使用 pidstat -w pid命令，cswch和nvcswch表示自愿及非自愿切換。

磁盤

磁盤問題和cpu一樣是屬于比較基礎(chǔ)的。首先是磁盤空間方面，我們直接使用df -hl來查看文件系統(tǒng)狀態(tài)

更多時候，磁盤問題還是性能上的問題。我們可以通過iostatiostat -d -k -x來進行分析

最后一列%util可以看到每塊磁盤寫入的程度，而rrqpm/s以及wrqm/s分別表示讀寫速度，一般就能幫助定位到具體哪塊磁盤出現(xiàn)問題了。

另外我們還需要知道是哪個進程在進行讀寫，一般來說開發(fā)自己心里有數(shù)，或者用iotop命令來進行定位文件讀寫的來源。

不過這邊拿到的是tid，我們要轉(zhuǎn)換成pid，可以通過readlink來找到pidreadlink -f /proc/*/task/tid/../..。

找到pid之后就可以看這個進程具體的讀寫情況cat /proc/pid/io

我們還可以通過lsof命令來確定具體的文件讀寫情況lsof -p pid

內(nèi)存

內(nèi)存問題排查起來相對比CPU麻煩一些，場景也比較多。主要包括OOM、GC問題和堆外內(nèi)存。一般來講，我們會先用free命令先來檢查一發(fā)內(nèi)存的各種情況。

堆內(nèi)內(nèi)存

內(nèi)存問題大多還都是堆內(nèi)內(nèi)存問題。表象上主要分為OOM和StackOverflow。

OOM

JMV中的內(nèi)存不足，OOM大致可以分為以下幾種：

Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread

這個意思是沒有足夠的內(nèi)存空間給線程分配java棧，基本上還是線程池代碼寫的有問題，比如說忘記shutdown，所以說應(yīng)該首先從代碼層面來尋找問題，使用jstack或者jmap。如果一切都正常，JVM方面可以通過指定Xss來減少單個thread stack的大小。

另外也可以在系統(tǒng)層面，可以通過修改/etc/security/limits.confnofile和nproc來增大os對線程的限制

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

這個意思是堆的內(nèi)存占用已經(jīng)達到-Xmx設(shè)置的最大值，應(yīng)該是最常見的OOM錯誤了。解決思路仍然是先應(yīng)該在代碼中找，懷疑存在內(nèi)存泄漏，通過jstack和jmap去定位問題。如果說一切都正常，才需要通過調(diào)整Xmx的值來擴大內(nèi)存。

Caused by: java.lang.OutOfMemoryError: Meta space

這個意思是元數(shù)據(jù)區(qū)的內(nèi)存占用已經(jīng)達到XX:MaxMetaspaceSize設(shè)置的最大值，排查思路和上面的一致，參數(shù)方面可以通過XX:MaxPermSize來進行調(diào)整(這里就不說1.8以前的永久代了)。

Stack Overflow

棧內(nèi)存溢出，這個大家見到也比較多。

Exception in thread "main" java.lang.StackOverflowError

表示線程棧需要的內(nèi)存大于Xss值，同樣也是先進行排查，參數(shù)方面通過Xss來調(diào)整，但調(diào)整的太大可能又會引起OOM。

使用JMAP定位代碼內(nèi)存泄漏

上述關(guān)于OOM和StackOverflow的代碼排查方面，我們一般使用JMAPjmap -dump:format=b,file=filename pid來導出dump文件

通過mat(Eclipse Memory Analysis Tools)導入dump文件進行分析，內(nèi)存泄漏問題一般我們直接選Leak Suspects即可，mat給出了內(nèi)存泄漏的建議。另外也可以選擇Top Consumers來查看最大對象報告。和線程相關(guān)的問題可以選擇thread overview進行分析。除此之外就是選擇Histogram類概覽來自己慢慢分析，大家可以搜搜mat的相關(guān)教程。

日常開發(fā)中，代碼產(chǎn)生內(nèi)存泄漏是比較常見的事，并且比較隱蔽，需要開發(fā)者更加關(guān)注細節(jié)。比如說每次請求都new對象，導致大量重復創(chuàng)建對象；進行文件流操作但未正確關(guān)閉；手動不當觸發(fā)gc；ByteBuffer緩存分配不合理等都會造成代碼OOM。

另一方面，我們可以在啟動參數(shù)中指定-XX:+HeapDumpOnOutOfMemoryError來保存OOM時的dump文件。

搜索Java知音，回復“后端面試”，送你一份面試寶典.pdf

gc問題和線程

gc問題除了影響cpu也會影響內(nèi)存，排查思路也是一致的。一般先使用jstat來查看分代變化情況，比如youngGC或者fullGC次數(shù)是不是太多呀；EU、OU等指標增長是不是異常呀等。

線程的話太多而且不被及時gc也會引發(fā)oom，大部分就是之前說的unable to create new native thread。除了jstack細細分析dump文件外，我們一般先會看下總體線程，通過pstreee -p pid |wc -l。

或者直接通過查看/proc/pid/task的數(shù)量即為線程數(shù)量。

堆外內(nèi)存

如果碰到堆外內(nèi)存溢出，那可真是太不幸了。首先堆外內(nèi)存溢出表現(xiàn)就是物理常駐內(nèi)存增長快，報錯的話視使用方式都不確定，如果由于使用Netty導致的，那錯誤日志里可能會出現(xiàn)OutOfDirectMemoryError錯誤，如果直接是DirectByteBuffer，那會報OutOfMemoryError: Direct buffer memory。

堆外內(nèi)存溢出往往是和NIO的使用相關(guān)，一般我們先通過pmap來查看下進程占用的內(nèi)存情況pmap -x pid | sort -rn -k3 | head -30，這段意思是查看對應(yīng)pid倒序前30大的內(nèi)存段。這邊可以再一段時間后再跑一次命令看看內(nèi)存增長情況，或者和正常機器比較可疑的內(nèi)存段在哪里。

我們?nèi)绻_定有可疑的內(nèi)存端，需要通過gdb來分析gdb --batch --pid {pid} -ex "dump memory filename.dump {內(nèi)存起始地址} {內(nèi)存起始地址+內(nèi)存塊大小}"

獲取dump文件后可用heaxdump進行查看hexdump -C filename | less，不過大多數(shù)看到的都是二進制亂碼。

NMT是Java7U40引入的HotSpot新特性，配合jcmd命令我們就可以看到具體內(nèi)存組成了。需要在啟動參數(shù)中加入 -XX:NativeMemoryTracking=summary 或者 -XX:NativeMemoryTracking=detail，會有略微性能損耗。

一般對于堆外內(nèi)存緩慢增長直到爆炸的情況來說，可以先設(shè)一個基線jcmd pid VM.native_memory baseline。

然后等放一段時間后再去看看內(nèi)存增長的情況，通過jcmd pid VM.native_memory detail.diff(summary.diff)做一下summary或者detail級別的diff。

可以看到j(luò)cmd分析出來的內(nèi)存十分詳細，包括堆內(nèi)、線程以及gc(所以上述其他內(nèi)存異常其實都可以用nmt來分析)，這邊堆外內(nèi)存我們重點關(guān)注Internal的內(nèi)存增長，如果增長十分明顯的話那就是有問題了。

detail級別的話還會有具體內(nèi)存段的增長情況，如下圖。

此外在系統(tǒng)層面，我們還可以使用strace命令來監(jiān)控內(nèi)存分配 strace -f -e "brk,mmap,munmap" -p pid

這邊內(nèi)存分配信息主要包括了pid和內(nèi)存地址。

不過其實上面那些操作也很難定位到具體的問題點，關(guān)鍵還是要看錯誤日志棧，找到可疑的對象，搞清楚它的回收機制，然后去分析對應(yīng)的對象。比如DirectByteBuffer分配內(nèi)存的話，是需要full GC或者手動system.gc來進行回收的(所以最好不要使用-XX:+DisableExplicitGC)。

那么其實我們可以跟蹤一下DirectByteBuffer對象的內(nèi)存情況，通過jmap -histo:live pid手動觸發(fā)fullGC來看看堆外內(nèi)存有沒有被回收。如果被回收了，那么大概率是堆外內(nèi)存本身分配的太小了，通過-XX:MaxDirectMemorySize進行調(diào)整。如果沒有什么變化，那就要使用jmap去分析那些不能被gc的對象，以及和DirectByteBuffer之間的引用關(guān)系了。

搜索Java知音，回復“后端面試”，送你一份面試寶典.pdf

GC問題

堆內(nèi)內(nèi)存泄漏總是和GC異常相伴。不過GC問題不只是和內(nèi)存問題相關(guān)，還有可能引起CPU負載、網(wǎng)絡(luò)問題等系列并發(fā)癥，只是相對來說和內(nèi)存聯(lián)系緊密些，所以我們在此單獨總結(jié)一下GC相關(guān)問題。

我們在cpu章介紹了使用jstat來獲取當前GC分代變化信息。而更多時候，我們是通過GC日志來排查問題的，在啟動參數(shù)中加上-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps來開啟GC日志。

常見的Young GC、Full GC日志含義在此就不做贅述了。

針對gc日志，我們就能大致推斷出youngGC與fullGC是否過于頻繁或者耗時過長，從而對癥下藥。我們下面將對G1垃圾收集器來做分析，這邊也建議大家使用G1-XX:+UseG1GC。

youngGC過頻繁

youngGC頻繁一般是短周期小對象較多，先考慮是不是Eden區(qū)/新生代設(shè)置的太小了，看能否通過調(diào)整-Xmn、-XX:SurvivorRatio等參數(shù)設(shè)置來解決問題。如果參數(shù)正常，但是young gc頻率還是太高，就需要使用Jmap和MAT對dump文件進行進一步排查了。

youngGC耗時過長

耗時過長問題就要看GC日志里耗時耗在哪一塊了。以G1日志為例，可以關(guān)注Root Scanning、Object Copy、Ref Proc等階段。Ref Proc耗時長，就要注意引用相關(guān)的對象。

Root Scanning耗時長，就要注意線程數(shù)、跨代引用。Object Copy則需要關(guān)注對象生存周期。而且耗時分析它需要橫向比較，就是和其他項目或者正常時間段的耗時比較。比如說圖中的Root Scanning和正常時間段比增長較多，那就是起的線程太多了。

觸發(fā)fullGC

G1中更多的還是mixedGC，但mixedGC可以和youngGC思路一樣去排查。觸發(fā)fullGC了一般都會有問題，G1會退化使用Serial收集器來完成垃圾的清理工作，暫停時長達到秒級別，可以說是半跪了。

fullGC的原因可能包括以下這些，以及參數(shù)調(diào)整方面的一些思路：

• 并發(fā)階段失敗：在并發(fā)標記階段，MixGC之前老年代就被填滿了，那么這時候G1就會放棄標記周期。這種情況，可能就需要增加堆大小，或者調(diào)整并發(fā)標記線程數(shù)-XX:ConcGCThreads。
• 晉升失敗：在GC的時候沒有足夠的內(nèi)存供存活/晉升對象使用，所以觸發(fā)了Full GC。這時候可以通過-XX:G1ReservePercent來增加預(yù)留內(nèi)存百分比，減少-XX:InitiatingHeapOccupancyPercent來提前啟動標記，-XX:ConcGCThreads來增加標記線程數(shù)也是可以的。
• 大對象分配失敗：大對象找不到合適的region空間進行分配，就會進行fullGC，這種情況下可以增大內(nèi)存或者增大-XX:G1HeapRegionSize。
• 程序主動執(zhí)行System.gc()：不要隨便寫就對了。

另外，我們可以在啟動參數(shù)中配置-XX:HeapDumpPath=/xxx/dump.hprof來dump fullGC相關(guān)的文件，并通過jinfo來進行g(shù)c前后的dump

jinfo?-flag?+HeapDumpBeforeFullGC?pid?
jinfo?-flag?+HeapDumpAfterFullGC?pid

這樣得到2份dump文件，對比后主要關(guān)注被gc掉的問題對象來定位問題。

搜索Java知音，回復“后端面試”，送你一份面試寶典.pdf

網(wǎng)絡(luò)

涉及到網(wǎng)絡(luò)層面的問題一般都比較復雜，場景多，定位難，成為了大多數(shù)開發(fā)的噩夢，應(yīng)該是最復雜的了。這里會舉一些例子，并從tcp層、應(yīng)用層以及工具的使用等方面進行闡述。

超時

超時錯誤大部分處在應(yīng)用層面，所以這塊著重理解概念。超時大體可以分為連接超時和讀寫超時，某些使用連接池的客戶端框架還會存在獲取連接超時和空閑連接清理超時。

• 讀寫超時。readTimeout/writeTimeout，有些框架叫做so_timeout或者socketTimeout，均指的是數(shù)據(jù)讀寫超時。注意這邊的超時大部分是指邏輯上的超時。soa的超時指的也是讀超時。讀寫超時一般都只針對客戶端設(shè)置。

• 連接超時。connectionTimeout，客戶端通常指與服務(wù)端建立連接的最大時間。服務(wù)端這邊connectionTimeout就有些五花八門了，jetty中表示空閑連接清理時間，tomcat則表示連接維持的最大時間。

• 其他。包括連接獲取超時connectionAcquireTimeout和空閑連接清理超時idleConnectionTimeout。多用于使用連接池或隊列的客戶端或服務(wù)端框架。

我們在設(shè)置各種超時時間中，需要確認的是盡量保持客戶端的超時小于服務(wù)端的超時，以保證連接正常結(jié)束。

在實際開發(fā)中，我們關(guān)心最多的應(yīng)該是接口的讀寫超時了。

如何設(shè)置合理的接口超時是一個問題。如果接口超時設(shè)置的過長，那么有可能會過多地占用服務(wù)端的tcp連接。而如果接口設(shè)置的過短，那么接口超時就會非常頻繁。

服務(wù)端接口明明rt降低，但客戶端仍然一直超時又是另一個問題。這個問題其實很簡單，客戶端到服務(wù)端的鏈路包括網(wǎng)絡(luò)傳輸、排隊以及服務(wù)處理等，每一個環(huán)節(jié)都可能是耗時的原因。

TCP隊列溢出

tcp隊列溢出是個相對底層的錯誤，它可能會造成超時、rst等更表層的錯誤。因此錯誤也更隱蔽，所以我們單獨說一說。

如上圖所示，這里有兩個隊列：syns queue(半連接隊列）、accept queue（全連接隊列）。三次握手，在server收到client的syn后，把消息放到syns queue，回復syn+ack給client，server收到client的ack，如果這時accept queue沒滿，那就從syns queue拿出暫存的信息放入accept queue中，否則按tcp_abort_on_overflow指示的執(zhí)行。

tcp_abort_on_overflow 0表示如果三次握手第三步的時候accept queue滿了那么server扔掉client發(fā)過來的ack。tcp_abort_on_overflow 1則表示第三步的時候如果全連接隊列滿了，server發(fā)送一個rst包給client，表示廢掉這個握手過程和這個連接，意味著日志里可能會有很多connection reset / connection reset by peer。

那么在實際開發(fā)中，我們怎么能快速定位到tcp隊列溢出呢？

netstat命令，執(zhí)行netstat -s | egrep "listen|LISTEN"

如上圖所示，overflowed表示全連接隊列溢出的次數(shù)，sockets dropped表示半連接隊列溢出的次數(shù)。

ss命令，執(zhí)行ss -lnt

上面看到Send-Q 表示第三列的listen端口上的全連接隊列最大為5，第一列Recv-Q為全連接隊列當前使用了多少。

接著我們看看怎么設(shè)置全連接、半連接隊列大小吧：

全連接隊列的大小取決于min(backlog, somaxconn)。backlog是在socket創(chuàng)建的時候傳入的，somaxconn是一個os級別的系統(tǒng)參數(shù)。而半連接隊列的大小取決于max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog)。

在日常開發(fā)中，我們往往使用servlet容器作為服務(wù)端，所以我們有時候也需要關(guān)注容器的連接隊列大小。在tomcat中backlog叫做acceptCount，在jetty里面則是acceptQueueSize。

RST異常

RST包表示連接重置，用于關(guān)閉一些無用的連接，通常表示異常關(guān)閉，區(qū)別于四次揮手。

在實際開發(fā)中，我們往往會看到connection reset / connection reset by peer錯誤，這種情況就是RST包導致的。

端口不存在

如果像不存在的端口發(fā)出建立連接SYN請求，那么服務(wù)端發(fā)現(xiàn)自己并沒有這個端口則會直接返回一個RST報文，用于中斷連接。

主動代替FIN終止連接

一般來說，正常的連接關(guān)閉都是需要通過FIN報文實現(xiàn)，然而我們也可以用RST報文來代替FIN，表示直接終止連接。實際開發(fā)中，可設(shè)置SO_LINGER數(shù)值來控制，這種往往是故意的，來跳過TIMED_WAIT，提供交互效率，不閑就慎用。

客戶端或服務(wù)端有一邊發(fā)生了異常，該方向?qū)Χ税l(fā)送RST以告知關(guān)閉連接

我們上面講的tcp隊列溢出發(fā)送RST包其實也是屬于這一種。這種往往是由于某些原因，一方無法再能正常處理請求連接了(比如程序崩了，隊列滿了)，從而告知另一方關(guān)閉連接。

接收到的TCP報文不在已知的TCP連接內(nèi)

比如，一方機器由于網(wǎng)絡(luò)實在太差TCP報文失蹤了，另一方關(guān)閉了該連接，然后過了許久收到了之前失蹤的TCP報文，但由于對應(yīng)的TCP連接已不存在，那么會直接發(fā)一個RST包以便開啟新的連接。

一方長期未收到另一方的確認報文，在一定時間或重傳次數(shù)后發(fā)出RST報文

這種大多也和網(wǎng)絡(luò)環(huán)境相關(guān)了，網(wǎng)絡(luò)環(huán)境差可能會導致更多的RST報文。

之前說過RST報文多會導致程序報錯，在一個已關(guān)閉的連接上讀操作會報connection reset，而在一個已關(guān)閉的連接上寫操作則會報connection reset by peer。通常我們可能還會看到broken pipe錯誤，這是管道層面的錯誤，表示對已關(guān)閉的管道進行讀寫，往往是在收到RST，報出connection reset錯后繼續(xù)讀寫數(shù)據(jù)報的錯，這個在glibc源碼注釋中也有介紹。

我們在排查故障時候怎么確定有RST包的存在呢？當然是使用tcpdump命令進行抓包，并使用wireshark進行簡單分析了。tcpdump -i en0 tcp -w xxx.cap，en0表示監(jiān)聽的網(wǎng)卡。

接下來我們通過wireshark打開抓到的包，可能就能看到如下圖所示，紅色的就表示RST包了。

TIME_WAIT和CLOSE_WAIT

TIME_WAIT和CLOSE_WAIT是啥意思相信大家都知道。

在線上時，我們可以直接用命令netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'來查看time-wait和close_wait的數(shù)量

用ss命令會更快ss -ant | awk '{++S[$1]} END {for(a in S) print a, S[a]}'

TIME_WAIT

time_wait的存在一是為了丟失的數(shù)據(jù)包被后面連接復用，二是為了在2MSL的時間范圍內(nèi)正常關(guān)閉連接。它的存在其實會大大減少RST包的出現(xiàn)。

過多的time_wait在短連接頻繁的場景比較容易出現(xiàn)。這種情況可以在服務(wù)端做一些內(nèi)核參數(shù)調(diào)優(yōu):

#表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認為0，表示關(guān)閉
net.ipv4.tcp_tw_reuse?=?1
#表示開啟TCP連接中TIME-WAIT?sockets的快速回收，默認為0，表示關(guān)閉
net.ipv4.tcp_tw_recycle?=?1

當然我們不要忘記在NAT環(huán)境下因為時間戳錯亂導致數(shù)據(jù)包被拒絕的坑了，另外的辦法就是改小tcp_max_tw_buckets，超過這個數(shù)的time_wait都會被干掉，不過這也會導致報time wait bucket table overflow的錯。

CLOSE_WAIT

close_wait往往都是因為應(yīng)用程序?qū)懙挠袉栴}，沒有在ACK后再次發(fā)起FIN報文。close_wait出現(xiàn)的概率甚至比time_wait要更高，后果也更嚴重。往往是由于某個地方阻塞住了，沒有正常關(guān)閉連接，從而漸漸地消耗完所有的線程。

想要定位這類問題，最好是通過jstack來分析線程堆棧來排查問題，具體可參考上述章節(jié)。這里僅舉一個例子。

開發(fā)同學說應(yīng)用上線后CLOSE_WAIT就一直增多，直到掛掉為止，jstack后找到比較可疑的堆棧是大部分線程都卡在了countdownlatch.await方法，找開發(fā)同學了解后得知使用了多線程但是確沒有catch異常，修改后發(fā)現(xiàn)異常僅僅是最簡單的升級sdk后常出現(xiàn)的class not found。