任何線程是否應該駐留在線程池之外？

當使用線程池時，是否仍然使用單個線程對象來執行特定任務是有益的。我想知道在Java中的服務器，是否正在監聽連接的線程應該與其他任何線程共享其資源，然後從這一個監聽線程分配它們？由於我對這個概念並不熟悉，所以我也可能會忽略這一點。任何線程是否應該駐留在線程池之外？

來源

2011-07-08 Titus

是的，我沒有看到爲什麼要將接受線程放入線程池的原因。 – Kaj

好吧，那太好了 - 我只想知道。 – Titus

是的，必須同時運行的單個任務可以在線程池之外擁有自己的線程。強制每個線程成爲池的一部分可能會掩蓋您的設計，因爲您需要各種機制來使併發任務看起來像工作線程。

來源

2011-07-08 14:07:10

我會創建兩個池，一個用於監聽，另一個用於內部任務。這樣你就永遠不會讓你的服務器處於無法監聽連接的風險之中。

如果內部任務只是一個線程，那麼它可以很小，但至少它是安全隔離的。

來源

2011-07-08 14:06:58

這個答案對我很有用，因爲我也不確定使用多線程池是否是好的做法，所以謝謝。 – Titus

我會聽完任務循環直到完成並且永不放棄線程。這樣，另一個線程就不能把聽力任務置於風險之中。 –

如果您的服務器需要維護全局應用程序狀態（例如，使用AtomicLong處理服務器提供的請求數量等），則可能需要資源共享。您的主線程通常會等待，準備好接受傳入的連接/請求。然後更新全局狀態（如命中計數器），根據新請求（通常是Runnable或Callable）創建一個新的「作業」，並將其提交給線程池（java.util.concurrent）提供它們。

來源

2011-07-08 14:07:32

線程池的目的只是爲了幫助您管理線程。換句話說，線程池爲您處理線程的創建和終止，併爲空閒線程提供工作。被阻塞或等待的線程將不會收到新任務。

您的連接偵聽器可能會處於等待連接的無限循環中，因此永遠不會閒置（儘管它可能處於等待狀態）。由於這種情況，連接監聽器線程將永遠無法接收新任務，因此將其與其他線程合併是沒有意義的。

連接監聽和連接處理也是兩回事。從這個角度來看，連接監聽器也不應該與連接處理器混合使用。

來源

2011-07-08 14:14:49