先描述一下現(xiàn)象：
 環(huán)境：
       一個機房，均衡后帶20臺服務器，并發(fā)峰值大概在7萬不到一點，平均下來一臺服務器3000多并發(fā)
現(xiàn)象：
      20臺服務器會隨機出現(xiàn)應用服務器程序把cpu打滿的情況，而正常情況下，3000并發(fā)的時候，應用服務器的cpu不超過10%，在cpu滿的情況下程序基本上停止提供服務器，只有重啟才能解決。
     開始的時候，20臺服務器的程序一模一樣，會隨機有部分服務器出現(xiàn)情況。
     現(xiàn)在換了一半的服務器，測試新程序。

昨天通過系統(tǒng)自帶的性能監(jiān)視器，將占用cpu的線程找出來了。在這部分線程池的處理過程中，有循環(huán)的地方都加了數(shù)量判斷，防止出現(xiàn)死循環(huán)。

今天問題仍然出現(xiàn)，新的老的程序上都出現(xiàn)過，出現(xiàn)的情況也不盡相同，有并發(fā)在1500左右，有3000左右。
沒有出問題的并發(fā)都在3000上下，所以單純說是并發(fā)造成的，可能不準確。最大的可能還是服務器遇到一個特殊的數(shù)據(jù)導致處理的錯誤，但是還有一點比較奇怪的是，有線程繁忙的時候，很快就會有該線程池中的其他線程也繁忙起來，難道異常數(shù)據(jù)出現(xiàn)的頻率在這個點上如此之高？？
今天下午的修改是：
   在單獨的一個線程中來監(jiān)視出現(xiàn)問題的線程池中的線程的狀態(tài)，如果發(fā)現(xiàn)對單個請求的處理時間過長，那么記錄下當前線程中的狀態(tài)，希望能抓到究竟是什么情況下導致的問題？同時出現(xiàn)這種情況的時候，結束當前線程，重啟一個線程放入線程池中，保證以下的工作正常處理。

   結果如何，明日再觀察!