用線程編程有什麼好處？

Question

給定一個單核CPU，使用線程編碼有什麼好處？

至少用Java實現，它似乎直觀的自然延伸到考慮到單核限制任何其他語言，你可能有多個線程執行各種行動，但過程有時間限制和切換。

由於工藝A和工藝B：

什麼是執行過程中A，結束進程B的一半的好處，然後完成進程A VS執行過程A的下半年則B？

看來，線程之間的切換將引入時間延遲，將延長兩個進程VS不交換，只是完成了那麼B.

Answer 1

一個執行線程不一定做任何有用的總體完成時間。規範的例子是從磁盤讀取 - 數據不會在那裏幾毫秒，在此期間處理器將閒置。線程允許程序的一部分使用CPU，而其他部分程序正在等待操作完成。

Answer 2

到單核系統上使用的線程的原因很簡單，讓原本使用所有的CPU處理通過需要得到更快完成其他任務搶佔。使系統成爲多線程的最常見原因是即使在執行長時間計算時也具有響應用戶界面。

當然，任何操作都需要很長時間（讀取文件，訪問數據庫，調整照片大小，重新計算電子表格），並且可以在單獨的線程上執行這些操作，以允許線程響應用戶輸入全程運作。例如，二十年前，很少有一個多CPU系統或允許多線程的操作系統，因此幾乎每個程序都是單線程的，並且創建了許多允許系統具有UI的框架並仍然做I/O。這個標準的機制是一個事件循環，所有的事件（UI，網絡，定時器等）都在一個大循環中處理。

這種類型的系統意味着UI在文件I/O和計算等事情中被阻擋。爲了不阻止用戶界面太多，你必須以塊的方式完成I/O（比如，一次讀取文件4k），處理塊之間的任何傳入UI事件。這實際上只是保持系統正常運行的一種手段，但很難讓系統像這樣順利運行，因爲您不知道需要多長時間來處理事件。

解決方案是有一個單獨的線程來重新計算電子表格或編寫文件。這樣，操作系統可以爲這些線程提供公平的時間片，同時仍然搶佔它們來運行用戶界面，從而使用戶界面始終處於響應狀態。

Answer 3

有很多原因。維基百科對其page about threads給出了一個體面的概述。

下面的幾個OTOH：

• I/O密集型任務從線程（特別是網絡應用程序）中受益。
• 即使在單核上，超線程處理器也可以加速多線程應用程序。
• 可以指示線程等待（阻止）並喚醒特定事件，啓用響應式事件驅動的編程。

Answer 4

如果你的程序需要「同時」做幾件事情，那麼線程是一個好方法，特別是這些任務中有一些是相當長的時間。否則，你會發現自己編寫的代碼看起來像是程序中的一個操作系統調度程序，如果你下面的操作系統已經非常好，那麼這往往是浪費時間。你會發現你的源代碼主要是'調度程序'，而不是'程序'，這非常不雅觀。一個好的線程程序可以在源代碼中非常優雅和經濟，這使得自己看起來不錯並且節省了時間。

一些運行時間錯誤。在Ada的早期，運行時環境會自行執行線程調度，並且從未令人滿意。部分原因在於，儘管Ada語言規範包含了線程的概念，但我們當時使用的操作系統往往不提供這些概念。當編譯器編寫者開始使用底層操作系統線程時，Ada得到了很多改進。

同樣，Python並沒有真正正確地使用底層操作系統線程;它用全球解釋器鎖破壞它。 Python通過改用多處理來避開整個問題（不一定是Windows主機上的好東西......）。

Windows的早期版本也沒有做線程，他們做了合作的多任務處理。這取決於整個機器中的每個進程至少不時調用任何OS例程。每個操作系統例程都會首先查閱「調度程序」，看看是否有其他任何東西在等待運行，然後繼續執行代表程序執行的任何操作。當時有許多可怕的程序不會玩弄整個機器。當有人開始進行長度計算時，你無法繼續玩紙牌遊戲。

Answer 5

你的程序的心智模式是什麼？

，如果它取決於在不可預知的訂單發生，如果你想在響應這些投入所做的事情並不簡單，並且可以在時間上重疊的多個外部輸入...

那麼它是有道理的爲每個輸入請求分配一個單獨的線程，並讓該線程執行該請求所需的響應。例如，如果您的程序正在等待來自外部通道的輸入請求，並且每個請求必須觸發其自己的傳出和傳入消息的協議，那麼它可以非常簡化創建新線程的代碼（或重新使用舊的）。

不知何故人們似乎進入勞動力市場，認爲線程只是爲了提高速度（通過並行）。 這是一個用途，只要它允許多個CPU芯片起動，但它絕不是唯一的用途。