我寫了乙個服務，並為每個請求分配乙個執行緒來處理，我這樣做的原因是因為基本上每個請求都是一次資料庫的查詢操作。我使用了乙個執行緒池的庫來減少執行緒的建立和銷毀。
我的問題是：像這樣的i/o多執行緒，什麼才是乙個好的臨界點？我知道這需要乙個粗略的估計值，但這個值應該是幾百呢還是幾千？
更新:
非常感謝你們所有的回答，看起來我需要去測試找出執行緒數上限，問題是：我怎麼知道執行緒數已經到達了上限？我究竟該如何去測量？
有的人可能會說，兩個執行緒就算是太多的執行緒了。我不是特別同意這種看法。
我的建議是：測試，而不是猜想。我建議把執行緒數設定為可配置的，並初始化為100個執行緒，然後執行你的軟體並對它進行監控。
如果執行緒的使用峰值才為3，那說明100個執行緒就是太多了。如果一天中的大部分時間都保持在100個執行緒，那就將執行緒的數量提高到200，然後再監視其運**況。
你確實可以讓你的**自動監控執行緒的使用，並在下次啟動的時候自動修改配置選項，但沒必要這麼做。
我不支援經常變動你的執行緒池，而是盡可能的使用某乙個值，你可能會問乙個執行緒池合適的臨界點是什麼，現假定你的執行緒池可以限制執行緒池的最大執行緒數（這是一件非常好的事情）。
我寫過執行緒池和資料庫連線池，他們擁有以下最基本的特徵（我認為這些對系統的效能來說是必要的）：
第一條是為了確保執行緒池的最低效能標準（這些執行緒是一直可以被使用的）。第二條是為了限制活動執行緒的資源使用。第三條是在一定的時間內將執行緒數返回到基準的設定，以減少資源的使用。
你需要去平衡執行緒未被完全使用（情況a）和沒有足夠的工作執行緒（情況b）的情況。
a通常指記憶體的使用（棧等等），因為乙個不工作的執行緒不會占用太多的cpu資源。b通常會延遲處理到達請求，直到有可以使用的執行緒。
這就是為什麼要去測算，正如你遇到的這種情況，絕大部分執行緒需要等待資料庫的響應才能執行。這就有兩個主要因素影響執行緒的數量：
第乙個因素是資料庫的有效連線數。這是乙個硬性的限制，除非你能通過資料庫管理系統增加資料庫的連線數。在這裡，我假設你的資料庫管理系統能夠承擔的資料庫連線數是無限制的。（雖然，理想情況下，你也應該測量一下）
其次，執行緒數量應該依賴於你系統的歷史運**況。最小的執行緒數你應該設定為在歷史最低的執行緒數的基礎上加上a%和乙個絕對的最小數值（例如，讓它也可被配置，就像a一樣）5。
執行緒池的最大數應該設定為在歷史最大執行緒數的基礎上加上b%。
你也應該監控你系統運**況的變化，如果因為某些原因，在某乙個非常重要的時刻，你的執行緒池使用率達到100%（這將影響你客戶端的效能），這就應該增加你執行緒池所允許的最大執行緒的數量，使其再增加b%。
多執行緒，到底該設定多少個執行緒？
不好了，線上伺服器超時嚴重，請求非常慢，好像報連線數too many了，怎麼辦？小夥伴們在反饋。一般我們的技術老大的處理方式，把連線數和執行緒池調大點，重啟，再觀察。往往這個方式是應急措施，治標不治本，因為不知道問題的原因。有個嚴重誤區，以為執行緒池設定太小了，調大點請求就會快了。今天就帶著小夥伴們...
多執行緒，到底該設定多少個執行緒？
不好了，線上伺服器超時嚴重，請求非常慢，好像報連線數too many了，怎麼辦？小夥伴們在反饋。一般我們的技術老大的處理方式，把連線數和執行緒池調大點，重啟，再觀察。往往這個方式是應急措施，治標不治本，因為不知道問題的原因。有個嚴重誤區，以為執行緒池設定太小了，調大點請求就會快了。今天就帶著小夥伴們...
多執行緒，到底該設定多少個執行緒？
不好了，線上伺服器超時嚴重，請求非常慢，好像報連線數too many了，怎麼辦？小夥伴們在反饋。一般我們的技術老大的處理方式，把連線數和執行緒池調大點，重啟，再觀察。往往這個方式是應急措施，治標不治本，因為不知道問題的原因。有個嚴重誤區，以為執行緒池設定太小了，調大點請求就會快了。今天就帶著小夥伴們...