談到一個現實世界的例子,有幾個理由使用多線程,和我不會聘請不瞭解它的網絡開發人員。但最終,使用多線程的原因與標準和網絡開發相同:您要麼需要在後臺完成一段時間(也就是阻止),以便在用戶之間給予用戶某種響應,要麼您有一項任務可以通過在多個內核上運行來加速。當多線程實際上有用時,卻是一個不同的問題。
情況1:即確實需要一些處理並且具有低的命中Web服務器/第二
這裏多線程(如果適用於算法)是好事,因爲空閒內核被利用和線程可以導致對用戶的更快響應。
情況2:那確實需要一些處理,具有較高的命中Web服務器/秒
這裏多線程是可能的,但核心是平時忙於其他請求,不存在資源留下來正確使用它。事實上,將任務分散到多個線程中甚至可能對響應時間產生負面影響,因爲任務現在已經碎片化並且所有部分都需要完成,但線程的執行順序未定義。因此,一個客戶端可以立即收到響應,而其他客戶可能會等待超時,直到最後一個分段最終得到處理。
情況3: Web服務器必須做一些處理,需要一個很長的時間,需要
這裏多線程,有沒有辦法解決它。客戶不能等待幾分鐘或者幾個小時,直到收到響應。在這種情況下,通常會執行回調系統,因此基本上每個任務都有一個可以查詢當前狀態的「API」。大多數網上商店都是這樣的例子:您訂購了一些東西,稍後您可以查詢您的訂單狀態。
線程的替代方法是過程分支,就像Apache在其標準配置中那樣。好處是負載分佈在覈心之間(主要適用於情況2),並且Web代碼本身不必爲使用所有核心而做任何事情,因爲OS會自動處理這些核心。但是,如果負載不平衡,則某些內核可能處於空閒狀態,並且不會以最佳方式使用資源。線程情況幾乎總是更好的解決方案,如果它是正確的話。但是Apache/Tomcat標準配置使用非常過時的線程模型,爲每個請求產生一個線程。有效地給予一定的點擊次數/秒,CPU比線程更忙於實際處理這些請求。
恕我直言,你絕對正確的認爲,多線程在web應用中的主要作用是同時處理多個獨立的請求,從而使服務器響應。 – Ingo
舉個例子說,你有一個用戶註冊頁面,你需要發送該用戶關於註冊的電子郵件通知。在這種情況下,我們可以通過在單獨線程中發送電子郵件來使用多線程。 – Foolish
我正在使用多線程來解析xmls –