JAVA應用運維，線上故障排查全套路

原文連接： https: //fredal.xin/java-error-check

線上故障主要會包括cpu、磁盤、內存以及網絡問題，而大多數故障可能會包含不止一個層面的問題，因此進行排查時候儘可能四個方面依次排查一遍。同時例如jstack、jmap等工具也是不囿於一個方面的問題的，基本上出問題就是df、free、top 三連，而後依次jstack、jmap伺候，具體問題具體分析便可。

CPU

通常來說咱們首先會排查cpu方面的問題。cpu異常每每仍是比較好定位的。緣由包括業務邏輯問題(死循環)、頻繁gc以及上下文切換過多。而最多見的每每是業務邏輯(或者框架邏輯)致使的，可使用jstack來分析對應的堆棧狀況。

使用jstack分析cpu問題

咱們先用ps命令找到對應進程的pid(若是你有好幾個目標進程，能夠先用top看一下哪一個佔用比較高)。

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

而後將佔用最高的pid轉換爲16進制printf '%x\n' pid獲得nid

接着直接在jstack中找到相應的堆棧信息jstack pid |grep 'nid' -C5 –color

能夠看到咱們已經找到了nid爲0x42的堆棧信息，接着只要仔細分析一番便可。

固然更常見的是咱們對整個jstack文件進行分析，一般咱們會比較關注WAITING和TIMED_WAITING的部分，BLOCKED就不用說了。咱們可使用命令cat jstack.log | grep "java.lang.Thread.State" | sort -nr | uniq -c來對jstack的狀態有一個總體的把握，若是WAITING之類的特別多，那麼多半是有問題啦。

頻繁gc

固然咱們仍是會使用jstack來分析問題，但有時候咱們能夠先肯定下gc是否是太頻繁，使用jstat -gc pid 1000命令來對gc分代變化狀況進行觀察，1000表示採樣間隔(ms)，S0C/S1C、S0U/S1U、EC/EU、OC/OU、MC/MU分別表明兩個Survivor區、Eden區、老年代、元數據區的容量和使用量。YGC/YGT、FGC/FGCT、GCT則表明YoungGc、FullGc的耗時和次數以及總耗時。若是看到gc比較頻繁，再針對gc方面作進一步分析，具體能夠參考一下gc章節的描述。

上下文切換

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

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

若是咱們但願對特定的pid進行監控那麼可使用 pidstat -w pid命令，cswch和nvcswch表示自願及非自願切換。

磁盤

磁盤問題和cpu同樣是屬於比較基礎的。首先是磁盤空間方面，咱們直接使用df -hl來查看文件系統狀態

更多時候，磁盤問題仍是性能上的問題。咱們能夠經過iostatiostat -d -k -x來進行分析

最後一列%util能夠看到每塊磁盤寫入的程度，而rrqpm/s以及wrqm/s分別表示讀寫速度，通常就能幫助定位到具體哪塊磁盤出現問題了。

另外咱們還須要知道是哪一個進程在進行讀寫，通常來講開發本身內心有數，或者用iotop命令來進行定位文件讀寫的來源。

不過這邊拿到的是tid，咱們要轉換成pid，能夠經過readlink來找到pidreadlink -f /proc/*/task/tid/../..。

找到pid以後就能夠看這個進程具體的讀寫狀況cat /proc/pid/io

咱們還能夠經過lsof命令來肯定具體的文件讀寫狀況lsof -p pid

內存

內存問題排查起來相對比CPU麻煩一些，場景也比較多。主要包括OOM、GC問題和堆外內存。通常來說，咱們會先用free命令先來檢查一發內存的各類狀況。

堆內內存

內存問題大多還都是堆內內存問題。表象上主要分爲OOM和StackOverflow。

一、OOM

JMV中的內存不足，OOM大體能夠分爲如下幾種：

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

這個意思是沒有足夠的內存空間給線程分配java棧，基本上仍是線程池代碼寫的有問題，好比說忘記shutdown，因此說應該首先從代碼層面來尋找問題，使用jstack或者jmap。若是一切都正常，JVM方面能夠經過指定Xss來減小單個thread stack的大小。另外也能夠在系統層面，能夠經過修改/etc/security/limits.confnofile和nproc來增大os對線程的限制；

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

這個意思是堆的內存佔用已經達到-Xmx設置的最大值，應該是最多見的OOM錯誤了。解決思路仍然是先應該在代碼中找，懷疑存在內存泄漏，經過jstack和jmap去定位問題。若是說一切都正常，才須要經過調整Xmx的值來擴大內存；

• Caused by: java.lang.OutOfMemoryError: Meta space

這個意思是元數據區的內存佔用已經達到XX:MaxMetaspaceSize設置的最大值，排查思路和上面的一致，參數方面能夠經過XX:MaxPermSize來進行調整(這裏就不說1.8之前的永久代了)；

二、Stack Overflow

棧內存溢出，這個你們見到也比較多。

Exception in thread "main" java.lang.StackOverflowError

表示線程棧須要的內存大於Xss值，一樣也是先進行排查，參數方面經過Xss來調整，但調整的太大可能又會引發OOM。

三、使用JMAP定位代碼內存泄漏

上述關於OOM和StackOverflow的代碼排查方面，咱們通常使用JMAPjmap -dump:format=b,file=filename pid來導出dump文件

經過mat(Eclipse Memory Analysis Tools)導入dump文件進行分析，內存泄漏問題通常咱們直接選Leak Suspects便可，mat給出了內存泄漏的建議。另外也能夠選擇Top Consumers來查看最大對象報告。和線程相關的問題能夠選擇thread overview進行分析。除此以外就是選擇Histogram類概覽來本身慢慢分析，你們能夠搜搜mat的相關教程。

平常開發中，代碼產生內存泄漏是比較常見的事，而且比較隱蔽，須要開發者更加關注細節。好比說每次請求都new對象，致使大量重複建立對象；進行文件流操做但未正確關閉；手動不當觸發gc；ByteBuffer緩存分配不合理等都會形成代碼OOM。

另外一方面，咱們能夠在啓動參數中指定-XX:+HeapDumpOnOutOfMemoryError來保存OOM時的dump文件。

四、gc問題和線程

gc問題除了影響cpu也會影響內存，排查思路也是一致的。通常先使用jstat來查看分代變化狀況，好比youngGC或者fullGC次數是否是太多呀；EU、OU等指標增加是否是異常呀等。

線程的話太多並且不被及時gc也會引起oom，大部分就是以前說的unable to create new native thread。除了jstack細細分析dump文件外，咱們通常先會看下整體線程，經過pstreee -p pid |wc -l。

或者直接經過查看/proc/pid/task的數量即爲線程數量。

堆外內存

若是碰到堆外內存溢出，那可真是太不幸了。首先堆外內存溢出表現就是物理常駐內存增加快，報錯的話視使用方式都不肯定，若是因爲使用Netty致使的，那錯誤日誌裏可能會出現OutOfDirectMemoryError錯誤，若是直接是DirectByteBuffer，那會報OutOfMemoryError: Direct buffer memory。

堆外內存溢出每每是和NIO的使用相關，通常咱們先經過pmap來查看下進程佔用的內存狀況pmap -x pid | sort -rn -k3 | head -30，這段意思是查看對應pid倒序前30大的內存段。這邊能夠再一段時間後再跑一次命令看看內存增加狀況，或者和正常機器比較可疑的內存段在哪裏。

咱們若是肯定有可疑的內存端，須要經過gdb來分析gdb --batch --pid {pid} -ex "dump memory filename.dump {內存起始地址} {內存起始地址+內存塊大小}"

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

NMT是Java7U40引入的HotSpot新特性，配合jcmd命令咱們就能夠看到具體內存組成了。須要在啓動參數中加入 -XX:NativeMemoryTracking=summary 或者 -XX:NativeMemoryTracking=detail，會有略微性能損耗。

通常對於堆外內存緩慢增加直到爆炸的狀況來講，能夠先設一個基線jcmd pid VM.native_memory baseline。

而後等放一段時間後再去看看內存增加的狀況，經過jcmd pid VM.native_memory detail.diff(summary.diff)作一下summary或者detail級別的diff。

能夠看到jcmd分析出來的內存十分詳細，包括堆內、線程以及gc(因此上述其餘內存異常其實均可以用nmt來分析)，這邊堆外內存咱們重點關注Internal的內存增加，若是增加十分明顯的話那就是有問題了。

detail級別的話還會有具體內存段的增加狀況，以下圖。

此外在系統層面，咱們還可使用strace命令來監控內存分配 strace -f -e "brk,mmap,munmap" -p pid，這邊內存分配信息主要包括了pid和內存地址。

不過其實上面那些操做也很難定位到具體的問題點，關鍵仍是要看錯誤日誌棧，找到可疑的對象，搞清楚它的回收機制，而後去分析對應的對象。好比DirectByteBuffer分配內存的話，是須要full GC或者手動system.gc來進行回收的(因此最好不要使用-XX:+DisableExplicitGC)。那麼其實咱們能夠跟蹤一下DirectByteBuffer對象的內存狀況，經過jmap -histo:live pid手動觸發fullGC來看看堆外內存有沒有被回收。若是被回收了，那麼大機率是堆外內存自己分配的過小了，經過-XX:MaxDirectMemorySize進行調整。若是沒有什麼變化，那就要使用jmap去分析那些不能被gc的對象，以及和DirectByteBuffer之間的引用關係了。

GC問題

堆內內存泄漏老是和GC異常相伴。不過GC問題不僅是和內存問題相關，還有可能引發CPU負載、網絡問題等系列併發症，只是相對來講和內存聯繫緊密些，因此咱們在此單獨總結一下GC相關問題。

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

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

針對gc日誌，咱們就能大體推斷出youngGC與fullGC是否過於頻繁或者耗時過長，從而對症下藥。咱們下面將對G1垃圾收集器來作分析，這邊也建議你們使用G1-XX:+UseG1GC。

youngGC過頻繁

youngGC頻繁通常是短週期小對象較多，先考慮是否是Eden區/新生代設置的過小了，看可否經過調整-Xmn、-XX:SurvivorRatio等參數設置來解決問題。若是參數正常，可是young gc頻率仍是過高，就須要使用Jmap和MAT對dump文件進行進一步排查了。

youngGC耗時過長

耗時過長問題就要看GC日誌裏耗時耗在哪一塊了。以G1日誌爲例，能夠關注Root Scanning、Object Copy、Ref Proc等階段。Ref Proc耗時長，就要注意引用相關的對象。Root Scanning耗時長，就要注意線程數、跨代引用。Object Copy則須要關注對象生存週期。並且耗時分析它須要橫向比較，就是和其餘項目或者正常時間段的耗時比較。好比說圖中的Root Scanning和正常時間段比增加較多，那就是起的線程太多了。

觸發fullGC

G1中更多的仍是mixedGC，但mixedGC能夠和youngGC思路同樣去排查。觸發fullGC了通常都會有問題，G1會退化使用Serial收集器來完成垃圾的清理工做，暫停時長達到秒級別，能夠說是半跪了。

fullGC的緣由可能包括如下這些，以及參數調整方面的一些思路：

• 併發階段失敗：在併發標記階段，MixGC以前老年代就被填滿了，那麼這時候G1就會放棄標記週期。這種狀況，可能就須要增長堆大小，或者調整併發標記線程數-XX:ConcGCThreads；

• 晉升失敗：在GC的時候沒有足夠的內存供存活/晉升對象使用，因此觸發了Full GC。這時候能夠經過-XX:G1ReservePercent來增長預留內存百分比，減小-XX:InitiatingHeapOccupancyPercent來提早啓動標記，-XX:ConcGCThreads來增長標記線程數也是能夠的；

• 大對象分配失敗：大對象找不到合適的region空間進行分配，就會進行fullGC，這種狀況下能夠增大內存或者增大-XX:G1HeapRegionSize；

• 程序主動執行System.gc()：不要隨便寫就對了。

另外，咱們能夠在啓動參數中配置-XX:HeapDumpPath=/xxx/dump.hprof來dump fullGC相關的文件，並經過jinfo來進行gc先後的dump

jinfo -flag +HeapDumpBeforeFullGC pid 

jinfo -flag +HeapDumpAfterFullGC pid

這樣獲得2份dump文件，對比後主要關注被gc掉的問題對象來定位問題。

網絡

涉及到網絡層面的問題通常都比較複雜，場景多，定位難，成爲了大多數開發的噩夢，應該是最複雜的了。這裏會舉一些例子，並從tcp層、應用層以及工具的使用等方面進行闡述。

超時

超時錯誤大部分處在應用層面，因此這塊着重理解概念。超時大致能夠分爲鏈接超時和讀寫超時，某些使用鏈接池的客戶端框架還會存在獲取鏈接超時和空閒鏈接清理超時。

• 讀寫超時。readTimeout/writeTimeout，有些框架叫作so_timeout或者socketTimeout，均指的是數據讀寫超時。注意這邊的超時大部分是指邏輯上的超時。soa的超時指的也是讀超時。讀寫超時通常都只針對客戶端設置；

• 鏈接超時。connectionTimeout，客戶端一般指與服務端創建鏈接的最大時間。服務端這邊connectionTimeout就有些五花八門了，jetty中表示空閒鏈接清理時間，tomcat則表示鏈接維持的最大時間；

• 其餘。包括鏈接獲取超時connectionAcquireTimeout和空閒鏈接清理超時idleConnectionTimeout。多用於使用鏈接池或隊列的客戶端或服務端框架。

咱們在設置各類超時時間中，須要確認的是儘可能保持客戶端的超時小於服務端的超時，以保證鏈接正常結束。

在實際開發中，咱們關心最多的應該是接口的讀寫超時了。

如何設置合理的接口超時是一個問題。若是接口超時設置的過長，那麼有可能會過多地佔用服務端的tcp鏈接。而若是接口設置的太短，那麼接口超時就會很是頻繁。

服務端接口明明rt下降，但客戶端仍然一直超時又是另外一個問題。這個問題其實很簡單，客戶端到服務端的鏈路包括網絡傳輸、排隊以及服務處理等，每個環節均可能是耗時的緣由。

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指示的執行。

tcp_abort_on_overflow 0表示若是三次握手第三步的時候accept queue滿了那麼server扔掉client發過來的ack。tcp_abort_on_overflow 1則表示第三步的時候若是全鏈接隊列滿了，server發送一個rst包給client，表示廢掉這個握手過程和這個鏈接，意味着日誌裏可能會有不少connection reset / connection reset by peer。

那麼在實際開發中，咱們怎麼能快速定位到tcp隊列溢出呢？

• netstat命令，執行netstat -s | egrep "listen|LISTEN"

如上圖所示，overflowed表示全鏈接隊列溢出的次數，sockets dropped表示半鏈接隊列溢出的次數。

• ss命令，執行ss -lnt

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

接着咱們看看怎麼設置全鏈接、半鏈接隊列大小吧：

全鏈接隊列的大小取決於min(backlog, somaxconn)。backlog是在socket建立的時候傳入的，somaxconn是一個os級別的系統參數。而半鏈接隊列的大小取決於max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog)。

在平常開發中，咱們每每使用servlet容器做爲服務端，因此咱們有時候也須要關注容器的鏈接隊列大小。在tomcat中backlog叫作acceptCount，在jetty裏面則是acceptQueueSize。

RST異常

RST包表示鏈接重置，用於關閉一些無用的鏈接，一般表示異常關閉，區別於四次揮手。

在實際開發中，咱們每每會看到connection reset / connection reset by peer錯誤，這種狀況就是RST包致使的。

一、端口不存在

若是像不存在的端口發出創建鏈接SYN請求，那麼服務端發現本身並無這個端口則會直接返回一個RST報文，用於中斷鏈接。

二、主動代替FIN終止鏈接

通常來講，正常的鏈接關閉都是須要經過FIN報文實現，然而咱們也能夠用RST報文來代替FIN，表示直接終止鏈接。實際開發中，可設置SO_LINGER數值來控制，這種每每是故意的，來跳過TIMED_WAIT，提供交互效率，不閒就慎用。

三、客戶端或服務端有一邊發生了異常，該方向對端發送RST以告知關閉鏈接

咱們上面講的tcp隊列溢出發送RST包其實也是屬於這一種。這種每每是因爲某些緣由，一方沒法再能正常處理請求鏈接了(好比程序崩了，隊列滿了)，從而告知另外一方關閉鏈接。

四、接收到的TCP報文不在已知的TCP鏈接內

好比，一方機器因爲網絡實在太差TCP報文失蹤了，另外一方關閉了該鏈接，而後過了許久收到了以前失蹤的TCP報文，但因爲對應的TCP鏈接已不存在，那麼會直接發一個RST包以便開啓新的鏈接。

五、一方長期未收到另外一方的確認報文，在必定時間或重傳次數後發出RST報文

這種大多也和網絡環境相關了，網絡環境差可能會致使更多的RST報文。

以前說過RST報文多會致使程序報錯，在一個已關閉的鏈接上讀操做會報connection reset，而在一個已關閉的鏈接上寫操做則會報connection reset by peer。一般咱們可能還會看到broken pipe錯誤，這是管道層面的錯誤，表示對已關閉的管道進行讀寫，每每是在收到RST，報出connection reset錯後繼續讀寫數據報的錯，這個在glibc源碼註釋中也有介紹。

咱們在排查故障時候怎麼肯定有RST包的存在呢？固然是使用tcpdump命令進行抓包，並使用wireshark進行簡單分析了。tcpdump -i en0 tcp -w xxx.cap，en0表示監聽的網卡。

接下來咱們經過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的數量

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

一、TIME_WAIT

time_wait的存在一是爲了丟失的數據包被後面鏈接複用，二是爲了在2MSL的時間範圍內正常關閉鏈接。它的存在其實會大大減小RST包的出現。

過多的time_wait在短鏈接頻繁的場景比較容易出現。這種狀況能夠在服務端作一些內核參數調優:

#表示開啓重用。容許將TIME-WAIT sockets從新用於新的TCP鏈接，默認爲0，表示關閉

net.ipv4.tcp_tw_reuse = 1

#表示開啓TCP鏈接中TIME-WAIT sockets的快速回收，默認爲0，表示關閉

net.ipv4.tcp_tw_recycle = 1

固然咱們不要忘記在NAT環境下由於時間戳錯亂致使數據包被拒絕的坑了，另外的辦法就是改小tcp_max_tw_buckets，超過這個數的time_wait都會被幹掉，不過這也會致使報time wait bucket table overflow的錯。

二、CLOSE_WAIT

close_wait每每都是由於應用程序寫的有問題，沒有在ACK後再次發起FIN報文。close_wait出現的機率甚至比time_wait要更高，後果也更嚴重。每每是因爲某個地方阻塞住了，沒有正常關閉鏈接，從而漸漸地消耗完全部的線程。

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

開發同窗說應用上線後CLOSE_WAIT就一直增多，直到掛掉爲止，jstack後找到比較可疑的堆棧是大部分線程都卡在了countdownlatch.await方法，找開發同窗瞭解後得知使用了多線程可是卻沒有catch異常，修改後發現異常僅僅是最簡單的升級sdk後常出現的class not found。