這取決于您的應用程序。 但是對于那些希望對如何從生產站點購買的所有昂貴內核中擠出更多資金的人來說，請多多包涵，我將闡明圍繞多線程 Java應用程序的奧秘。

內容針對最典型的Java EE應用程序進行了“優化”，該應用程序具有Web前端，允許最終用戶在應用程序內發起許多小交易。 每個交易的重要部分都在等待一些外部資源。 例如從數據庫或任何其他集成數據源返回的查詢。 但是大多數內容也與其他應用程序相關。 例如繁重的計算建模應用程序或處理數據的批處理過程。

但是，讓我們從基礎開始。 在我們描述的應用程序類型中，您傾向于有很多用戶與您的應用程序進行交互。 是成千上萬同時活動的用戶還是成千上萬的用戶-所有這些用戶都希望應用程序及時響應他們。 這就是您對操作系統設計人員感激的地方。 那些家伙在所有人甚至還沒有想到HTTP協議之前就已經想出了這種解決方法。

在您在軟件中創建更多線程然后基礎硬件可以同時執行的情況下，使用的解決方案很有用。 在硬件級別上，您還具有線程。 例如您CPU上的內核或具有超線程功能的虛擬化環境（如Intel）。 無論如何，我們手頭的應用程序可以輕易產生比基礎硬件直接支持更多的軟件線程。 您的OS現在啟動的功能類似于簡單的循環調度。 在此期間，每個軟件線程輪流執行，稱為時間片，以在實際硬件上運行。

時間分片允許所有線程進行。 否則，很容易想象這樣一種情況，其中一個用戶發起了一項真正昂貴的任務，而為其他用戶提供服務的所有其他線程卻挨餓了。

因此，我們正在經歷這個驚人的時間切片。 那么將線程數設置為LARGE_NUMBER并完成該操作是否可行？ 顯然沒有。 其中包括間接費用，實際上甚至包括幾種間接費用。 因此，為了在調整線程時做出明智的決定，讓我們介紹一下由LARGE_NUMBER個線程一一導致的問題。

注冊狀態保存/恢復 。 處理器寄存器確實包含很多狀態。 每次計劃程序移至下一個任務時，哪個文件都會保存到緩存中。 然后在時間到來時恢復。 幸運的是，調度程序分配的時間片相對較大。 因此，在多線程環境中，來往于注冊表的保存/還原開銷通常不會成為我們最卑鄙的敵人。

鎖 。 當時間片被鎖持有線程占用時，所有其他等待此特定鎖的線程現在都必須等待。 直到鎖持有者獲得另一片和釋放鎖的機會。 因此，如果您正在進行大量同步，則請檢查線程在高負載下的行為。 由于鎖持有線程，您的同步代碼有可能導致發生更多上下文切換。 分析線程轉儲將是開始調查此危險的好地方。

釋放虛擬內存 。 所有操作系統都利用交換到外部存儲的虛擬內存。 通過在需要時將內存中的最近最少使用（LRU）數據交換到磁盤驅動器。 哪個好 但是，如果您現在正在使用有限的內存運行應用程序，并且有許多線程在爭奪將其堆棧和私有數據放入內存的空間，那么您可能會遇到問題。

在每個時間片回合中，您可能都有線程在外部存儲中交換數據。 這將大大降低應用程序的性能。 特別是對于問題特別嚴重的Java應用程序。 每當您開始交換堆時，每次Full GC運行都將花費很長時間。 一些專家建議關閉操作系統級別的交換功能。 在Linux發行版中，您可以通過swapoff –a來實現。

但好消息是，過去幾年該問題已大大減少。 兩者均具有廣泛的64位OS部署，從而可以使用更大的RAM和SSD來代替世界各地的傳統旋轉磁盤。 但是要注意敵人，如果有疑問，請檢查進程的頁面進/出比例。

最后但并非最不重要的- 線程緩存狀態 。 在所有現代處理器中，您都在內核旁邊建立了高速緩存，從而使操作完成速度比RAM中的數據快100倍。 絕對很棒。 但是不妙的是，當線程開始為這個極其有限的空間而戰時。 然后，負責清理的LRU算法再次開始清理緩存，為新數據騰出空間。 這可能是其時間片中輸入緩存的數據最后一個線程。 因此，您的線程最終可能會從緩存中清除彼此的數據。 再次造成了嚴重的問題。

如果您在Intel體系結構上運行，那么在這種情況下可能會幫助您的解決方案是Intel的VTune Performance Analyzer

因此，也許將LARGE_NUMBER個線程放入應用程序配置中并不是最明智的選擇。 但是在配置線程數時會給出什么提示？

首先，可以將某些應用程序配置為以等于基礎硬件線程的線程數運行。 對于典型的Web應用程序可能不是這種情況，但是肯定有很好的案例支持此策略。 請注意，當您的線程在諸如關系數據庫之類的外部資源后面等待時，這些線程將從循環調度中刪除。 因此，在典型的Java EE應用程序中，擁有比基礎硬件更多的線程并且仍在無鎖爭用或其他問題的情況下運行并不罕見。

接下來，明智的做法是將線程劃分為不同用途的不同組。 典型的情況是將計算線程與I / O線程分開。 計算線程通常在大多數時間都處于繁忙狀態，因此將其數量保持在底層硬件容量以下非常重要。 另一方面，I / O線程（例如需要數據庫往返的操作）在大多數時間里都在等待。 因此，不會過于頻繁地為爭取資源做出貢獻。 因此，使I / O線程（方式）的數量大于支持您的應用程序的硬件線程的數量是安全的。

然后，您應該最小化線程的創建和銷毀。 由于這些操作往往很昂貴，因此請查看合并解決方案。 您可能正在使用已經內置了線程池的Java EE基礎結構，或者可以查看java.util.concurrent.ThreadPoolExecutor之類的解決方案。 但是，當您有時需要增加或減少線程數時，也不要太害羞–只需避免在與下一個HTTP請求或JDBC連接一樣可預測的事件上創建和刪除它們。

作為最后的建議，我們將提供最重要的建議。 測量。 調整線程池的大小，并在負載下運行應用程序。 測量吞吐量和延遲。 然后進行優化以實現您的目標。 然后再次測量。 沖洗并重復。 直到您對結果滿意為止。

不要對CPU的性能做任何假設。 如今，CPU中發生的魔力數量巨大。 還要注意，虛擬化和JIT運行時優化也會增加額外的復雜性。 但是這些將成為另一個話題。 如果您訂閱我們的Twitter feed ，將會及時收到通知。

在撰寫本文時，以下資源被用作靈感來源：

• Arch Robinson的帖子，關于多少線程會影響性能
• 不同的Stackoverflow問題和評論：
  • http://stackoverflow.com/questions/130506/how-many-threads-should-i-use-in-my-java-program

是的。 本文是有關我們在內存泄漏以外其他問題領域進行研究的第一條提示。 但是我們尚無法預測是否以及何時要為所有鎖定和緩存爭用問題提供解決方案。 但是絕對有希望。

參考： 我需要多少個線程？ 由我們的JCG合作伙伴 Nikita Salnikov Tarnovski在Plumbr Blog博客上獲得。

翻譯自: https://www.javacodegeeks.com/2013/01/how-many-threads-do-i-need.html