線上故障主要會包括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，
看完三件事??
如果你覺得這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：
-
點贊，轉發，有你們的 『點贊和評論』，才是我創造的動力，
-
關注公眾號 『 java爛豬皮 』，不定期分享原創知識，
-
同時可以期待后續文章ing??
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/235902.html
標籤：其他