線上故障主要會包括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方面做進一步分析。
上下文切換
針對頻繁上下文問題，我們可以使用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掉的問題對象來定位問題。
搜索Java知音，回覆“後端面試”，送你一份面試寶典.pdf
網絡
涉及到網絡層面的問題一般都比較複雜，場景多，定位難，成爲了大多數開發的噩夢，應該是最複雜的了。這裏會舉一些例子，並從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相關文章，學習資料都會在裏面更新，整理的資料也會放在裏面。
覺得寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！