先描述一下現(xiàn)象：
環(huán)境：
一個機房，均衡后帶20臺服務(wù)器，并發(fā)峰值大概在7萬不到一點，平均下來一臺服務(wù)器3000多并發(fā)
現(xiàn)象：
20臺服務(wù)器會隨機出現(xiàn)應(yīng)用服務(wù)器程序把cpu打滿的情況，而正常情況下，3000并發(fā)的時候，應(yīng)用服務(wù)器的cpu不超過10%，在cpu滿的情況下程序基本上停止提供服務(wù)器，只有重啟才能解決。
開始的時候，20臺服務(wù)器的程序一模一樣，會隨機有部分服務(wù)器出現(xiàn)情況。
現(xiàn)在換了一半的服務(wù)器，測試新程序。
昨天通過系統(tǒng)自帶的性能監(jiān)視器，將占用cpu的線程找出來了。在這部分線程池的處理過程中，有循環(huán)的地方都加了數(shù)量判斷，防止出現(xiàn)死循環(huán)。
今天問題仍然出現(xiàn)，新的老的程序上都出現(xiàn)過，出現(xiàn)的情況也不盡相同，有并發(fā)在1500左右，有3000左右。
沒有出問題的并發(fā)都在3000上下，所以單純說是并發(fā)造成的，可能不準(zhǔn)確。最大的可能還是服務(wù)器遇到一個特殊的數(shù)據(jù)導(dǎo)致處理的錯誤，但是還有一點比較奇怪的是，有線程繁忙的時候，很快就會有該線程池中的其他線程也繁忙起來，難道異常數(shù)據(jù)出現(xiàn)的頻率在這個點上如此之高？？
今天下午的修改是：
在單獨的一個線程中來監(jiān)視出現(xiàn)問題的線程池中的線程的狀態(tài)，如果發(fā)現(xiàn)對單個請求的處理時間過長，那么記錄下當(dāng)前線程中的狀態(tài)，希望能抓到究竟是什么情況下導(dǎo)致的問題？同時出現(xiàn)這種情況的時候，結(jié)束當(dāng)前線程，重啟一個線程放入線程池中，保證以下的工作正常處理。
結(jié)果如何，明日再觀察!