我之前就說過，如果沒有能力解決錯誤就不要加工你的錯誤，最近又被線上的一個系統給坑到了~該坑出現的莫名其妙的，該系統使用人數不多，就公司內部的幾百個人（用於提單之類的），突然該系統停止了響應（任何操作都很慢）。
按照這種情況，我們一般情況下會有幾種操作。
1、查看項目日誌（查看無特殊現象）
2、查看數據庫健康狀態
3、查看服務器的CPU、內存 、負載等情況
4、查看jvm的gc等情況
5、回滾上一個版本（一般是最後的手段）
坑在於不知不覺纔會踩中，在所有的操作都無果之後~我發覺我踩坑了。後來放了一個html文件在那個項目裏面，發覺訪問之下也是幾乎訪問不了，最後想起這種情況應該屬於是web容器的work線程無法接受請求了（一般情況下work線程只有cpu的1-2倍數）。
因爲項目是java的web項目，java的項目因爲基於jvm運行，所以查看線程的狀態非常容易。直接用jstack就OK了~
jstack -F pid >jts.log（java進程id，可以用jps或者ps aux|grep java 去找），將線程的狀態輸出到jts.log文件
值得關注的線程狀態有：
死鎖，Deadlock（重點關注）
執行中，Runnable
等待資源，Waiting
on condition（重點關注）
等待獲取監視器，Waiting
on monitor entry（重點關注）
暫停，Suspended
對象等待中，Object.wait() 或 TIMED_WAITING
阻塞，Blocked（重點關注）
停止，Parked
Thread 30082: (state = BLOCKED)
- java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
- java.lang.ref.ReferenceQueue.remove(long) @bci=44, line=118 (Interpreted frame)
- java.lang.ref.ReferenceQueue.remove() @bci=2, line=134 (Interpreted frame)
- java.lang.ref.Finalizer$FinalizerThread.run() @bci=3, line=159 (Interpreted frame)
Thread 30081: (state = BLOCKED)
- java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
- java.lang.Object.wait() @bci=2, line=485 (Compiled frame)
- java.lang.ref.Reference$ReferenceHandler.run() @bci=46, line=116 (Compiled frame)
Thread 30076: (state = BLOCKED)
- java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise)
- com.caucho.server.resin.ResinWaitForExitService.waitForExit() @bci=139, line=135 (Interpreted frame)
- com.caucho.server.resin.Resin.waitForExit() @bci=35, line=1358 (Interpreted frame)
- com.caucho.server.resin.Resin.main(java.lang.String[]) @bci=25, line=1407 (Interpreted frame)這些就是dump出來的狀態，可以看到線程是blocked的，這個時候還有一個技巧。看看有沒有自己的代碼引起的線程阻塞，可以直接在裏面搜自己的代碼包名，比如 com.xxx，這個時候如果有的話，就可以直接定位到哪個method了。
好了，最後公佈下此事的結果，果然是個坑，開發這邊的記錄日誌到直接把異常給捕獲瞭然後吞掉了。數據庫連接不上（某些特殊原因，不細講），連接池會就重連，最後導致線程的資源消耗完了~~~~坑好大。。。。
