線程閒置=壞？

Question

我想在一小羣機器上支持大約10,000個同時HTTP客戶機（儘可能小）。我想在用戶使用應用程序時保持與每個客戶端的連接，以允許服務器推送更新。

我相信異步IO通常被推薦用於這種長期連接，以避免大量線程閒置。但是讓線程閒置的問題是什麼？我發現線程模型在心理上更容易處理，但我不想做一些會讓我頭痛的事情。我想我必須進行實驗，但是我想知道是否有人知道沿着這些線的任何以前的實驗？

Answer 1

異步I/O基本上意味着您的應用程序執行大部分線程調度。而不是讓操作系統隨機掛起你的線程並安排另一個線程，而只有線程達到一個I/O操作時，你的線程只有CPU核心的線程數量，並且在最合適的點—上屈服於其他任務。時間。

上面似乎是從性能的角度來看一個明確的勝利，但異步編程模型是在幾個方面要複雜得多：

1. 它不能被表達爲一個函數調用使工作流程不明顯，特別是考慮到由於例外而導致的控制流量轉移時;
2. 沒有專門針對編程語言的支持，成語非常混亂：意大利麪代碼和/或極其微弱的信噪比是常態;
3. 主要歸因於以上原因1.上面的調試要困難得多，因爲堆棧跟蹤不能代表整個工作單元內的進度;
4. 執行從一個線程跳轉到一個線程池（甚至是幾個池，其中每個抽象層都有自己的線程），因此使用通常的工具進行分析和監視幾乎變得毫無用處。

在另一方面，許多有利於改進和優化都發生在現代操作系統的其中大多是消除同步我的表現缺點/ O編程：

• 地址空間是巨大的，所以預留空間對於堆棧不是問題;
• 調用堆棧的實際物理RAM負載並不是很大，因爲只有線程實際使用的堆棧部分被提交給RAM，並且調用堆棧通常不會超過64K;
• 上下文切換對於較大的線程數量而言過去是非常昂貴的，已經得到改進，其開銷對於所有實際目的而言可忽略不計。

一個經典論文通過多以上和其他一些點會是一個很好的補充，我所說的是什麼：

https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/index.html

Answer 2

在你的問題的評論中已經有一些好的指針。

不使用10K線程的原因是這種成本內存資源和內存成本的能源。編程模型沒有參數，因爲坐在客戶端連接上的線程不能與要發佈事件的線程相同。

請看看Servlet 3.0標準中的websockets標準和異步請求處理模型。所有最近的Java Web應用程序服務器現在都實現它（例如Glassfish和Tomcat），它是解決您的問題的方案。

由於您使用的操作系統，JVM和應用程序服務器缺失，此問題本身無法應答。但是，您可以自己快速測試它，只需創建一個帶有Thread.sleep(9999999)的servlet或JSP並對其執行siege -c 10000 ...即可。

Answer 3

10,000個同時HTTP客戶端...線程坐着閒置有什麼問題？

空閒線程的代價似乎只是爲內核結構（幾kb）和線程堆棧（512kb-mb）分配的內存。但...

顯然，你會不時喚醒你的每一個n百線程，對不對？那是你付出上下文切換的代價的時候，這個時間可能不是很短（調用系統調度器的時間，更多的緩存未命中等）。例如，請參閱： http://www.cs.rochester.edu/u/cli/research/switch.pdf

而且您必須非常仔細地固定您的線程，以免影響系統。因此，每個連接的線程數量（阻塞IO）架構可以增加系統與異步IO的延遲。但是如果幾乎所有的線程都停在大部分時間內，它仍然適用於你的情況。

最後的話。我們不知道您的線程將在read（）中被阻塞多少次，以及他們需要做多少工作來處理接收到的數據。將使用什麼硬件，操作系統和網絡接口......因此，測試一下你係統的原型。