將Java進程轉移到“解剖臺”之前，法醫都干了什么？
作為法醫，不怕高度腐爛的尸體，也不怕錯綜復雜的案情。最怕的，是沒留下任何東西。空無一物，任何高超的技術，豐富的經驗，都無從下手。
生產環境錯綜復雜，幾分鐘前活蹦亂跳的進程，此刻就奄奄一息的躺在那里，茍延殘喘。作為第一時間發現的目擊者，一定要注意保存好現場。有時，最壞的情況就是引火上身，糾纏不清，這都是我們不愿看到的。
在進程的生命煙消云散之前，我們還有很多事要做。本篇文章，將介紹常用的保留線索方法。最后，將這個過程，使用Shell腳本自動化。
系統環境，不說謊的案發現場
1、系統當前網絡連接
- ss -antp > $DUMP_DIR/ss.dump 2>&1
本命令將系統的所有網絡連接輸出到ss.dump文件中。使用ss命令而不是netstat的原因，是因為netstat在網絡連接非常多的情況下，執行非常緩慢。
后續的處理，通過查看各種網絡連接狀態的梳理，來排查TIME_WAIT或者CLOSE_WAIT，或者其他連接過高的問題，非常有用。
2、網絡狀態統計
- netstat -s > $DUMP_DIR/netstat-s.dump 2>&1
將網絡統計狀態，輸出到netstat-s.dump文件中。它能夠按照各個協議進行統計輸出，對把握當時整個網絡狀態，有非常大的作用。
- sar -n DEV 1 2 > $DUMP_DIR/sar-traffic.dump 2>&1
上面這個命令，會使用sar輸出當前的網絡流量。在一些速度非常高的模塊上，比如redis、kafka，就經常發生跑滿網卡的情況。
3、進程資源
- lsof -p $PID > $DUMP_DIR/lsof-$PID.dump
這是個非常強大的命令。可以查看進程打開了哪些文件，這是一個神器，可以以進程的維度查看整個資源的使用情況。這個命令在資源非常多的情況下，輸出稍慢，耐心等待。
4、CPU資源
- mpstat > $DUMP_DIR/mpstat.dump 2>&1
- vmstat 1 3 > $DUMP_DIR/vmstat.dump 2>&1
- sar -p ALL > $DUMP_DIR/sar-cpu.dump 2>&1
- uptime > $DUMP_DIR/uptime.dump 2>&1
這幾個命令，我們在
《Linux之《荒島余生》(二)CPU篇》
這篇文章，已經有了比較詳細的介紹。主要輸出當前系統的CPU和負載，便于事后排查。
這幾個命令的功能，有不少重合，使用者要注意甄別。
5、I/O資源
- iostat -x > $DUMP_DIR/iostat.dump 2>&1
一般，以計算為主的服務節點，I/O資源會比較正常。但有時候也是會發生問題的，比如日志輸出過多，或者磁盤問題等。此命令可以輸出每塊磁盤的基本性能信息，用來排查I/O問題。
6、內存問題
- free -h > $DUMP_DIR/free.dump 2>&1
內存問題較為復雜，有興趣可以看下xjjdog堆外內存排查小結這篇文章。一般發生的問題是JVM內存溢出，我們在進程小節說明。
free命令能夠大體展現操作系統的內存概況，是故障排查中一個非常重要的點。
7、其他全局
- ps -ef > $DUMP_DIR/ps.dump 2>&1
- dmesg > $DUMP_DIR/dmesg.dump 2>&1
- sysctl -a > $DUMP_DIR/sysctl.dump 2>&1
在xjjdog的其他文章，我們不止一次說到dmesg。dmesg是許多靜悄悄死掉的服務留下的最后一點線索。
當然，ps作為執行頻率最高的一個命令，它當時的輸出信息，也必然有一些可以參考的價值。
由于內核的配置參數，會對系統產生非常大的影響。所以我們也輸出了一份。
進程快照，最后的遺言
1、jinfo
- ${JDK_BIN}jinfo $PID > $DUMP_DIR/jinfo.dump 2>&1
此命令將輸出java的基本進程信息。包括環境變量和參數配置。
2、gc信息
- ${JDK_BIN}jstat -gcutil $PID > $DUMP_DIR/jstat-gcutil.dump 2>&1
- ${JDK_BIN}jstat -gccapacity $PID > $DUMP_DIR/jstat-gccapacity.dump 2>&1
jstat將輸出當前的gc信息。一般，能大體看出一個端倪，如果不能，將借助jmap進行分析。
3、堆信息
- ${JDK_BIN}jmap $PID > $DUMP_DIR/jmap.dump 2>&1
- ${JDK_BIN}jmap -heap $PID > $DUMP_DIR/jmap-heap.dump 2>&1
- ${JDK_BIN}jmap -histo $PID > $DUMP_DIR/jmap-histo.dump 2>&1
- ${JDK_BIN}jmap -dump:format=b,file=$DUMP_DIR/heap.bin $PID > /dev/null 2>&1
jmap將會得到當前java進程的dump信息。如上所示，其實最有用的就是第4個命令，但是前面三個能夠讓你初步對系統概況進行大體判斷。
因為，第4個命令產生的文件，一般都非常的大。而且，需要下載下來，導入MAT這樣的工具進行深入分析，才能獲取結果。
4、執行棧
- ${JDK_BIN}jstack $PID > $DUMP_DIR/jstack.dump 2>&1
jstack將會獲取當時的執行棧。一般都會多次取值，我們這里取一次即可。這些信息非常有用，能夠還原你的java進程中線程情況。
- top -Hp $PID -b -n 1 -c > $DUMP_DIR/top-$PID.dump 2>&1
為了能夠得到更加精細的信息，我們使用top命令，來獲取進程中所有線程的cpu信息。這樣，就可以看到資源到底是耗費在什么地方。
5、高級替補
- kill -3 $PID
有時候，jstack并不能夠運行。有很多原因，比如java進程幾乎不響應了。我們會嘗試向進程發送kill -3信號。這個信號是java進程享有的，將會打印jstack的trace信息到日志文件中。是jstack的一個替補方案。
- gcore -o $DUMP_DIR/core $PID
對于jmap無法執行的問題，也有替補，那就是GDB組件中的gcore。將會生成一個core文件。我們可以使用如下的命令去生成dump
- ${JDK_BIN}jhsdb jmap --exe ${JDK}java --core $DUMP_DIR/core --binaryheap
瞬時態和歷史態
xjjdog這里創建兩個名詞。瞬時態是指當時發生的，快照類型的元素;歷史態是指按照頻率抓取的，有固定監控項的資源變動圖。
上面有很多信息，比如CPU，比如系統內存等，瞬時態的價值就不如歷史態來的直觀一些，因為它還存在一個基線問題。所以如果有監控系統一類的工具，將美好的多。
但對于lsof，heap等，這種沒有時間序列概念的混雜信息，無法進入監控系統，產生有用價值，就只能夠通過瞬時態進行分析。這種情況下，瞬時態的價值反而更大一些。
我已經把上面的過程，寫成了一個shell腳本。你可以在github上找到它。點擊左下角的查看原文，也能和它見面。
https://github.com/sayhiai/shell
但值得注意的是，分布式環境的故障原因，往往會出乎意料，你的這份單機證據，可能就只是一個表象。它沒有說謊，但它背后的意義，往往對問題本質進行了錯誤的引導。
