聲明：本文禁止未經本人同意的任何形式轉載！如有轉載需求，可與本人通過個人資料中的電子郵箱聯繫。對於未經同意的轉載，本人將保留進一步行動的權利
Java的調優文檔中很少建議確切的線程池大小的值。因爲該值關係到應用的具體情況，比如簡單和複雜類型的應用就不能混爲一談。
- 一個應用從內存中檢索字符串並轉發到JSP頁面做展現。
- 另一個應用，從數據庫中檢索1000條記錄，並計算平均值、方差。
第一個應用系統的響應速度較快，例如在0.25秒左右，也不需要耗費太多CPU的時間。第二個應用的響應時間大概在3秒左右，且對CPU敏感(即需要很多CPU的計算能力)。因此，在配置線程池時，給第一個應用配置100個線程就可能太低了，因爲它能同時處理起碼200個以上的併發請求；但100對第二個應用來說可能就太高了，因爲CPU可能最大能承受50個併發線程。
但是，顯示中大部分應用都是相似性很高的，所以可以考慮每個CPU配置50到75個線程。對於不同的應用，這個數字的適應性也不同，可根據對CPU監測的結果來做相應的調整。
線程池太大
除了可能將線程池配置得太小外，也有可能線程配置得太多了。在這種情況下，當系統負載增加時，CPU利用率持續保持很高，響應時間很長，因爲CPU在不同的線程上下文之間切換工作上花費了太多的時間，而在執行工作方面的時間卻顯得有限了。
線程池太大的一個重要表現就是CPU利用率持續走高。很多情況下，CPU的利用率與垃圾收集有關，但垃圾收集造成的CPU利用率高與線程池過大造成的有一個重要的區別在於：垃圾收集造成CPU的陡升陡降，而線程池的過飽和狀態則會造成CPU的持續偏高。
當這種情況發生時，減少線程池大小可能導致請求的等待，但是等待比在CPU飽和狀態下的處理要好，因爲飽和狀態的CPU會表現出極差的性能。最好的情況是請求到來了，就在隊列中等待一段時間，然後再利用較優化情況(非飽和狀態下)的CPU進行處理。
解決線程池過大的問題，就需要降低線程池的大小直至在通常的負荷狀態下，CPU的利用率在75%~85%之間。如果隊列的大小不易於管理，則可以：
- 調整代碼
- 添加新硬件
未完待續……
聲明：本文禁止未經本人同意的任何形式轉載！如有轉載需求，可與本人通過個人資料中的電子郵箱聯繫。對於未經同意的轉載，本人將保留進一步行動的權利！
