想象一下，我們有一個客戶端，它不斷髮送大量的雙重數據。
如何獲得最快的數據處理方式：分叉或/和多線程
現在我們正試圖使一臺服務器，它可以接收和處理來自客戶端的數據。
這是事實：
服務器可以在很短的時間內收到一個double。
有一個函數可以在服務器上處理一個double，這需要超過3分鐘才能處理一個double。
我們需要讓服務器儘可能快地處理來自客戶端的1000個雙重數據。
我如下的想法：
使用一個線程池來創建多個線程，每個線程都可以處理一個雙。
所有這些都是在Linux中。
我的問題：
現在我的服務器只是一個包含多線程的進程。我正在考慮如果我使用fork()，它會更快嗎？
我想只用fork()沒有多線程應該是一個壞主意，但如果我創建兩個過程和他們每個人都包含多線程是什麼？這種方法可以更快嗎？
順便說一句我已讀：
What is the difference between fork and thread?
Forking vs Threading
在某種程度上，這非常依賴底層硬件。這也取決於內存的限制，IO吞吐量，...
例如：如果你的CPU有4個內核，而且每一個都能夠運行兩個線程（而沒有多少人會在該系統上）;那麼你可能會更喜歡有4個進程的解決方案;每個人運行兩個線程！
或者，用fork（）的工作時，你會調用fork（）的4倍;但在每個分叉進程中，您應該將工作分配到兩個線程。長話短說，你真正想要做的是：到不是把自己鎖在某個角落。你想創建一個服務（如說，你正在建設一個服務器，而不是客戶端）具有聲音，設計合理。
並且考慮到您的要求，您希望構建該應用程序的方式允許您通過配置多少個進程來響應。它將使用的線程。然後你開始分析（意思是：你測量是怎麼回事）;也許你會做一些實驗來爲給定的硬件/操作系統堆棧尋找最佳選擇。
編輯：我覺得想說 - 歡迎來到真實的世界。您正面臨爲您的產品達到精確「性能目標」的要求。如果沒有這樣的目標，程序員的生活就會變得非常簡單：大多數時候，人們只是坐下來，把一個合理的產品放在一起，並賦予今天硬件的力量，「事情已經夠好了」。
但是，如果事情不夠好，那麼只有一種方法：你必須瞭解關於所有那些在這裏發揮作用的東西。從「我的操作系統中哪些系統調用可以用來獲取正確的核心/線程數量開始？」
換句話說：在您「逃脫」不知道你正在使用的硬件的實際容量的日子......已經結束了。如果你打算「玩這個遊戲」;那麼就沒有彎路：你將不得不學習規則！
最後：這裏的最重要的事情是不是過程與線程。你必須明白，你需要在這裏掌握整個圖片。如果您調整您的客戶端以獲得最高的CPU性能......然後發現網絡或IO問題導致10倍的「損失」，與您僅通過查看CPU而獲得的損失相比，這無濟於事。換句話說：您必須查看系統中的所有部分;然後您需要進行測量以瞭解您遇到瓶頸的位置。然後然後你決定採取的行動！
一個很好的閱讀，這將是「釋放它」由邁克爾·尼加德。當然，他的書主要是關於Java世界中的模式;但是他表現出的「表演」的確很出色。
fork荷蘭國際集團，因此是比開球線程方式慢。一個線程比完整的OS進程輕得多（傳統上，雖然進程已經在過去幾年中得到了發展），不僅在CPU需求方面，而且在內存佔用和一般操作系統開銷方面。
當你正在考慮線程或進程的預先安排的游泳池，設置時間的程序運行期間不會佔太大，所以你需要尋找到「什麼是進程間通信的成本」 - 這在線程之間（本地）通常比進程之間便宜（線程不需要通過操作系統來交換數據，僅用於同步，並且在某些情況下甚至可以在沒有這些的情況下離開）。但不幸的是，您沒有說明工作線程是否需要之間的IPC 。
概括：我看不到使用fork()的任何優勢，至少不會與問候效率。
請注意，你有你的倒退措辭：一** **服務器提供服務的調用。您正在描述一個安裝程序，其中*服務器*將數據發送給*客戶端*以進行處理。從術語的角度來看，這應該被顛倒過來。你有一個**客戶端**，它想要發送數據到**服務器**進行處理;而不是相反！ – GhostCat
@GhostCat謝謝。事實上，我把它稱爲「服務器」，因爲它是「服務器」，它是「listen」，它是「connect」的「客戶端」。 – Yves
只是說：你應該在你的措辭，文檔等方面確保你的團隊中的每個人都明白你的服務器客戶端的本質，或者是客戶端服務器？ – GhostCat