多線程vs單線程

Question

我現在正在爲服務器客戶端應用程序工作（僅用於學習目的），並且正在嘗試獲取有關此應用程序中有關線程的設計決策的信息。

目前我有一個線程負責與客戶端的所有非阻塞io。當它接收到任何數據時，它將它發送給一個工作線程，該線程從這些字節中創建一個「指令集」，然後相應地對其執行操作。但是，根據指令集，它可以對任意數量的數百個對象起作用（每個對象將在2到12個可以與之交互的客戶端之間加蓋）。我想知道是否應該處理同一個線程上的所有指令集，並且在處理每個集合時阻塞，或者如果我應該爲每個對象創建單獨的線程，然後將每個接收到的指令集傳遞給給定的對象線程處理。

我的問題歸結爲什麼時候（如果有的話）有更多不活動的線程正在等待數據減慢系統，相比之下，有一個工作線程處理所有數據（以及處理每條指令時的塊組）。

如果我爲每個對象創建了一個單獨的線程，那麼我認爲它可以增加併發性，因爲一旦主工作線程創建了一個指令集，它就可以傳遞它來處理，並且無意地開始處理下一個指令系統。

但是，我一直聽說如何創建和管理線程有一個底層成本，因爲操作系統必須管理它們。因此，如果我爲最多可以有2個客戶端進行交互的對象創建一個線程，管理它的底層成本會否定它的併發利益，只有2個客戶端可以利用該併發？

與往常一樣，任何意見/文章不勝感激:)

Answer 1

我建議通過以下的Java EE應用服務器樹立了榜樣。

爲傳入請求和處理程序線程的池設有隊列。當請求進入時，讓控制器從池中取出一個處理程序線程，將請求從隊列中取出，並將其交給處理程序線程處理。線程完成後，將其放回池中。

如果請求數量大於處理程序線程的數量，則隊列允許它們累積並等待線程變爲可用。

這樣的設計給你帶來兩個好處：

1. 它可以讓你設定的處理線程池的大小和它匹配到你的服務器資源
2. 當他們超過池容量，因此會扼殺傳入的請求你沒有阻止和等待或失去請求。

併發是你的朋友在這裏。這將有助於保持服務器的可擴展性。

Answer 2

如果線程實際上處於睡眠狀態，則開銷成本應該不過是首先啓動它們而花費的成本。沉睡的線程有一個相當有效的方法，直到需要時才能入睡：等待中斷。 （注意一種常見的睡眠方法是在時鐘中斷後喚醒，這就是你如何指定應該睡眠的時間）。如果那些線程沒有利用硬件，因爲它們正在喚醒某些類似定時器的東西，而不是某個更特定於您的程序的東西，那麼開銷可能是天文數字，因爲處理器將強制執行所有上下文開關特別是清空緩存。

Answer 3

單向測試。有時你必須阻止，除非你確信自己的計算能力，否則你不能只是衝擊一切。機器越慢/功能越差，阻塞越多，就會變得無用。設計你的應用程序以適應這種情況。更好的是讓它跟蹤正在發生的事情並讓它自行調整。