線程轉儲分析是用于分析基于Java的應用程序中的性能瓶頸的傳統方法。在現代，我們有APM工具，可以提供各種指標和屏幕來深入研究和識別性能問題，甚至在代碼級別也是如此。但對于某些性能問題或場合，線程轉儲分析仍然是識別瓶頸的最佳方法。

何時使用線程轉儲

要分析任何性能問題，最好在1到2秒的時間間隔內進行一系列線程轉儲。每隔1-2秒進行10-15次線程轉儲，有助于分析陷入困境的線程或跨線程轉儲執行相同的代碼。

l 線程轉儲可以在以下情況下進行：

l 應用程序掛起且沒有響應

l 應用程序需要時間才能響應

l 運行應用程序的服務器上CPU使用率高

l 活動線程數或線程總數的增加

線程轉儲有時也由應用程序服務器自動生成。例如，WebSphere應用程序服務器在OutOfMemoryError情況下生成線程轉儲，這有助于分析線程在該時刻的各種狀態。

對于場景#1和場景2，應該將重點放在處于阻塞、停放/等待和可運行狀態的線程上。對于場景#3，重點應該放在處于可運行狀態的線程上。無限循環執行中的一些線程可能會導致高CPU使用率，查看可運行狀態可能有助于發現這一點。對于場景#4，應該將重點放在處于可運行狀態和駐留/等待線程狀態的線程上。在所有場景中，忽略處于暫?；蚨〞r等待狀態的線程，這些線程正在等待執行任務/請求。

分析工具使用

使用工具分析線程轉儲將提供有關線程及其狀態的許多統計信息。然而，有時它可能無法揭示系統中的真正瓶頸。手動處理線程轉儲并通過Notepad++等工具進行分析總是更好的。如果要分析許多線程轉儲，則可以使用IBM線程轉儲分析器等工具。在有組織的視圖中查看線程轉儲有助于加快分析過程。雖然它不會像在線分析工具那樣提供許多復雜的統計數據，但它可以幫助更好地可視化線程轉儲，提供一個視圖來查看由于另一個線程而被阻塞的線程，還可以幫助比較線程轉儲。

在分析線程轉儲時，了解線程轉儲是針對哪個應用程序服務器進行的非常重要，因為這將有助于集中精力分析正確的線程。例如，如果在WebSphere應用程序服務器上進行了線程轉儲，那么“Web容器”線程池應該是第一個開始分析的地方，因為它是WebSphere應用程序的入口點，它將開始為到達它的請求提供服務。

線程轉儲類型

通常，在線程轉儲中會有兩種類型的線程。一類線程與應用程序相關，有助于執行應用程序代碼。另一類是將執行操作的線程，如從網絡讀取/寫入、心跳檢查和各種其他操作，包括JVM內部（如GC）等。根據問題的不同，應將重點放在這兩類線程上。大多數時候，應用程序代碼可能是造成性能瓶頸的罪魁禍首；因此，應該更多地關注應用程序線程。

線程池

線程轉儲顯示應用程序中可用的各種線程池。在WebSphere應用程序服務器中，名為“WebContainer:<id>”的線程屬于WebSphere線程池。計算此類線程的數量應等于定義的線程池大小。如果超過，則表示線程池中存在線程泄漏。需要驗證線程轉儲中不同線程池的大小。

ForkJoinPool是Java CompletableFuture用來異步運行任務的另一個線程池。如果此池中有太多異步任務，則需要增加池的大小，或者需要創建另一個更大的池。否則，此ForkJoinPool將成為異步任務執行的瓶頸。

如果應用程序正在使用Java 執行框架創建線程池，那么將為這些線程提供默認名稱“pool-<id1>-thread-<id2>”。這里“id1”表示線程池編號，“id2”表示線程庫中的線程數。有時，如果開發人員每次都創建新的線程池，而沒有通過執行框架關閉它們，那么它每次都會創建不同的池，線程數量也會增加。如果線程沒有主動執行某件事，這可能不會造成問題，但會導致OutOfMemoryError，即無法通過達到線程創建的最大數量來創建新線程。在分析任何線程轉儲時，查看不同的線程池并確保所有線程池都在定義/預期的限制內總是很好的。

應用方法

關注線程轉儲的堆棧跟蹤中的應用程序方法有助于分析應用程序代碼中的問題。如果應用程序中有同步的代碼或塊，那么應用程序線程將等待獲取對象上的鎖，以進入特定的代碼/塊執行。這將是昂貴的，因為通過讓其他線程等待，只允許一個線程進入代碼執行。這種情況可以在線程轉儲中看到，在線程轉儲中，線程等待獲取對象的鎖。如果不需要，可以修改代碼以避免這種同步。

結論

線程轉儲包含關于虛擬機、JVM參數、內存、GC相關信息、運行它的硬件等等。始終建議查看這些可能有助于分析的詳細信息。