大多數(shù)典型的應(yīng)用程序，如tomcat、tomcat，都是多線程的，數(shù)百個客戶機(jī)訪問同一個web應(yīng)用程序。在Tomcat訪問之后，所有后續(xù)處理都被拋出到一個新線程。新線程最終被調(diào)用到我們的servlet

大多數(shù)典型的應(yīng)用程序，如tomcat、tomcat，都是多線程的，數(shù)百個客戶機(jī)訪問同一個web應(yīng)用程序。在Tomcat訪問之后，所有后續(xù)處理都被拋出到一個新線程。新線程最終被調(diào)用到我們的servlet程序，比如doGet或者我們使用dopost方法。

如果我們不使用多線程機(jī)制，當(dāng)數(shù)百人同時訪問一個web應(yīng)用程序時，Tomcat將不得不排隊等待串行處理，因此客戶端根本無法忍受這種訪問速度。

還需要異步處理，您需要使用多線程。例如，任務(wù)a和任務(wù)B需要并行處理，單個線程只能串行處理。首先完成任務(wù)a，然后執(zhí)行任務(wù)B，如果要同時執(zhí)行多個任務(wù)，必須為每個任務(wù)分配一個線程，然后通過Java虛擬機(jī)的線程調(diào)度，同時執(zhí)行多個任務(wù)。例如，如果您的CPU是多核的，那么您可以讓CPU執(zhí)行一個線程。如果只有一個CPU，底層基于分時復(fù)用的原則，每個線程根據(jù)時間片獲得CPU資源。

線程串行和并行性能比較？

我經(jīng)歷了從java6到j(luò)ava8的“朝代更迭”，并給出了自己的看法。

首先，不可否認(rèn)的是，流絕對是優(yōu)雅的代名詞。它的串行調(diào)用模式和強(qiáng)大的API能力都賦予了程序員一種特殊的技能：高效和簡潔。

但事情并不是絕對的，但就性能而言，流真的比傳統(tǒng)迭代好嗎？事實(shí)上，情況并非如此。我們應(yīng)該根據(jù)實(shí)際情況來看待這個問題。

在極少量的迭代中，我們看不到性能效果的差異。以下幾點(diǎn)是建立在依賴大量數(shù)據(jù)迭代的前提下的。

分為以下幾點(diǎn)進(jìn)行討論：

1。不管是什么程序，它都必須在載體上運(yùn)行，而公共載體就是服務(wù)器。因此，很容易認(rèn)為CPU的處理能力直接影響性能。

如果它只是一個單核CPU，建議使用傳統(tǒng)的迭代。A） 實(shí)際測試結(jié)果表明，流的性能明顯低于for-loop等傳統(tǒng)處理方法。特別是當(dāng)它是單核CPU時，不要使用流的并行處理。原因是并行處理中還有另一個開銷，即上下文線程切換。這個時候，只有一個單核CPU，你不覺得當(dāng)CPU是多核的時候，隨著核數(shù)的增加，流的優(yōu)勢會逐漸顯現(xiàn)出來嗎。畢竟，并行處理仍然是由于串行處理。

2. 事情不是絕對的。并非所有情況下，流都不如串行處理中的傳統(tǒng)迭代好。例如，在復(fù)雜對象（公共順序?qū)ο?，包含大量信息）的處理中，測試結(jié)果表明流的性能仍然是由于普通的迭代，更不用說多核CPU下的并行處理了。這里再次強(qiáng)調(diào)，不要在單核下使用串行，你會發(fā)現(xiàn)性能并檢查它

！3. 最后，我想談?wù)勎业膫€人經(jīng)歷。在使用并行流時，在迭代處理中進(jìn)行多個外部接口調(diào)用時應(yīng)謹(jǐn)慎。您可能會發(fā)現(xiàn)，并行后上下文線程切換的代價并不一定比串行線程好，而且還會影響系統(tǒng)的穩(wěn)定性。

最后，在代碼整潔性方面，stream仍然有明顯的優(yōu)勢，但是在性能方面，我們還是要根據(jù)實(shí)際情況做出合理的選擇，這樣才能寫出最“優(yōu)雅”的代碼。

以上三點(diǎn)是個人觀點(diǎn)和日常工作中遇到的實(shí)際場景的總結(jié)。如果有什么不對勁或不同意見，可以留言指出，共同討論，共同進(jìn)步。