Java線程堆棧分析

jerry 發布于2019-08-16 10:58 / 1539人閱讀

摘要：線程堆棧最擅長與分析如下類型問題系統無緣無故過高。性能瓶頸如無法充分利用等線程死鎖死循環，餓死等。由于線程數量太多導致系統失敗如無法創建線程等。注意死鎖的兩個或多個線程是不消耗的，有的人認為的使用率是線程死鎖導致的，這個說法是完全錯誤的。

不知覺間工作已有一年了，閑下來的時候總會思考下，作為一名Java程序員，不能一直停留在開發業務使用框架上面。老話說得好，機會是留給有準備的人的，因此，開始計劃看一些Java底層一點的東西，嘗試開始在學習的過程中寫博客，希望和大家一起交流學習。

寫在前面：線程堆棧應該是多線程類應用程序非功能問題定位的最有效手段，可以說是殺手锏。線程堆棧最擅長與分析如下類型問題：

系統無緣無故CPU過高。

系統掛起，無響應。

系統運行越來越慢。

性能瓶頸（如無法充分利用CPU等）

線程死鎖、死循環，餓死等。

由于線程數量太多導致系統失敗（如無法創建線程等）。

如何解讀線程堆棧

如下面一段Java源代碼程序：

package org.ccgogoing.study.stacktrace;
/** 
 * @Author: LuoChong400
 * @Description: 測試線程
 * @Date: Create in 07:27 PM 2017/12/08
 */
public class MyTest {

        Object obj1 = new Object();
        Object obj2 = new Object();

        public void fun1() {
            synchronized (obj1) {
                fun2();
            }
        }
        public void fun2() {
            synchronized (obj2) {
                while (true) { //為了打印堆棧，該函數堆棧分析不退出
                    System.out.print("");
                }
            }
        }
        public static void main(String[] args) {
            MyTest aa = new MyTest();
            aa.fun1();
        }
    }

在Idea 中運行該程序，然后按下CTRL+BREAK鍵，打印出線程堆棧信息如下：

Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode):

"Service Thread" daemon prio=6 tid=0x000000000c53b000 nid=0xca58 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" daemon prio=10 tid=0x000000000c516000 nid=0xd390 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" daemon prio=10 tid=0x000000000c515000 nid=0xcbac waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Monitor Ctrl-Break" daemon prio=6 tid=0x000000000c514000 nid=0xd148 runnable [0x000000000caee000]
   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:152)
    at java.net.SocketInputStream.read(SocketInputStream.java:122)
    at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283)
    at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325)
    at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177)
    - locked <0x00000000d7858b50> (a java.io.InputStreamReader)
    at java.io.InputStreamReader.read(InputStreamReader.java:184)
    at java.io.BufferedReader.fill(BufferedReader.java:154)
    at java.io.BufferedReader.readLine(BufferedReader.java:317)
    - locked <0x00000000d7858b50> (a java.io.InputStreamReader)
    at java.io.BufferedReader.readLine(BufferedReader.java:382)
    at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64)

"Attach Listener" daemon prio=10 tid=0x000000000ad4a000 nid=0xd24c runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x000000000c1a8800 nid=0xd200 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=8 tid=0x000000000ace6000 nid=0xcd74 in Object.wait() [0x000000000c13f000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000000d7284858> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
    - locked <0x00000000d7284858> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" daemon prio=10 tid=0x000000000ace4800 nid=0xce34 in Object.wait() [0x000000000bf4f000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000000d7284470> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Object.java:503)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
    - locked <0x00000000d7284470> (a java.lang.ref.Reference$Lock)

"main" prio=6 tid=0x000000000238e800 nid=0xc940 runnable [0x00000000027af000]
   java.lang.Thread.State: RUNNABLE
    at org.ccgogoing.study.stacktrace.MyTest.fun2(MyTest.java:22)
    - locked <0x00000000d77d50c8> (a java.lang.Object)
    at org.ccgogoing.study.stacktrace.MyTest.fun1(MyTest.java:15)
    - locked <0x00000000d77d50b8> (a java.lang.Object)
    at org.ccgogoing.study.stacktrace.MyTest.main(MyTest.java:29)

"VM Thread" prio=10 tid=0x000000000ace1000 nid=0xd0a8 runnable 

"GC task thread#0 (ParallelGC)" prio=6 tid=0x00000000023a4000 nid=0xd398 runnable 

"GC task thread#1 (ParallelGC)" prio=6 tid=0x00000000023a5800 nid=0xcc20 runnable 

"GC task thread#2 (ParallelGC)" prio=6 tid=0x00000000023a7000 nid=0xb914 runnable 

"GC task thread#3 (ParallelGC)" prio=6 tid=0x00000000023a9000 nid=0xd088 runnable 

"VM Periodic Task Thread" prio=10 tid=0x000000000c53f000 nid=0xc1b4 waiting on condition 

JNI global references: 138

Heap
 PSYoungGen      total 36864K, used 6376K [0x00000000d7280000, 0x00000000d9b80000, 0x0000000100000000)
  eden space 31744K, 20% used [0x00000000d7280000,0x00000000d78ba0d0,0x00000000d9180000)
  from space 5120K, 0% used [0x00000000d9680000,0x00000000d9680000,0x00000000d9b80000)
  to   space 5120K, 0% used [0x00000000d9180000,0x00000000d9180000,0x00000000d9680000)
 ParOldGen       total 83456K, used 0K [0x0000000085800000, 0x000000008a980000, 0x00000000d7280000)
  object space 83456K, 0% used [0x0000000085800000,0x0000000085800000,0x000000008a980000)
 PSPermGen       total 21504K, used 3300K [0x0000000080600000, 0x0000000081b00000, 0x0000000085800000)
  object space 21504K, 15% used [0x0000000080600000,0x0000000080939290,0x0000000081b00000)

在上面這段堆棧輸出中，可以看到有很多后臺線程和main線程，其中只有main線程屬于Java用戶線程，其他幾個都是虛擬機自動創建的，我們分析的過程中，只關心用戶線程即可。

從上面的main線程中可以很直觀的看到當前線程的調用上下文，其中一個線程的某一層調用含義如下：

at MyTest.fun1(MyTest.java:15)
    |     |     |              |
    |     |     |              +-----當前正在調用的函數所在的源代碼文件的行號
    |     |     +------------當前正在調用的函數所在的源代碼文件
    |     +---------------------當前正在調用的方法名
    +---------------------------當前正在調用的類名

另外，堆棧中有：- locked <0x00000000d77d50b8> (a java.lang.Object)語句，表示該線程已經占有柯鎖<0x00000000d77d50b8>,尖括號中表示鎖ID，這個事系統自動產生的，我們只需要知道每次打印的堆棧，同一個ID表示是同一個鎖即可。每一個線程堆棧的第一行含義如下：

"main" prio=1 tid=0x000000000238e800 nid=0xc940 runnable [0x00000000027af000]
    |       |   |                       |           |           |
    |       |   |                       |           |           +--線程占用內存地址
    |       |   |                       |           +-----------線程的狀態
    |       |   |                       +----線程對應的本地線程id號
    |       |   +-------------------線程id
    |       +--------------------------線程優先級
    +-------------------------------線程名稱
    
其中需要說明的是，線程對應的本地線程id號，是指Java線程所對應的虛擬機中的本地線程。由于Java是解析型語言，執行的實體是Java虛擬機，因此Java語言中的線程是依附于虛擬機中的本地線程來運行的，實際上是本地線程在執行Java線程代碼。

鎖的解讀

從上面的線程堆棧看，線程堆棧中包含的直接信息為：線程的個數，每個線程調用的方法堆棧，當前鎖的狀態。線程的個數可以直接數出來；線程調用的方法堆棧，從下向上看，即表示當前的線程調用了哪個類上的哪個方法。而鎖得狀態看起來稍微有一點技巧。與鎖相關的信息如下：

當一個線程占有一個鎖的時候，線程的堆棧中會打印--locked<0x00000000d77d50c8>

當一個線程正在等待其它線程釋放該鎖，線程堆棧中會打印--waiting to lock<0x00000000d77d50c8>

當一個線程占有一個鎖，但又執行到該鎖的wait()方法上，線程堆棧中首先打印locked，然后又會打印--waiting on <0x00000000d77d50c8>

線程狀態的解讀

借助線程堆棧，可以分析很多類型的問題，CPU的消耗分析即是線程堆棧分析的一個重要內容；

處于TIMED_WAITING、WAITING狀態的線程一定不消耗CPU。處于RUNNABLE的線程，要結合當前代碼的性質判斷，是否消耗CPU。

如果是純Java運算代碼，則消耗CPU。

如果是網絡IO，很少消耗CPU。

如果是本地代碼，要結合本地代碼的性質判斷（可以通過pstack、gstack獲取本地線程堆棧），如果是純運算代碼，則消耗CPU，如果被掛起，則不消耗CPU，如果是IO，則不怎么消耗CPU。

如何借助線程堆棧分析問題

線程堆棧在定位如下類型的問題上非常有幫助：

線程死鎖的分析

Java代碼導致的CPU過高分析

死循環分析

資源不足分析

性能瓶頸分析

線程死鎖分析

死鎖的概念就不做過多解釋了，不明白的可以去網上查查；

兩個或超過兩個線程因為環路的鎖依賴關系而形成的鎖環，就形成了真正的死鎖，如下為死鎖喉打印的堆棧：

Found one Java-level deadlock:
=============================
"org.ccgogoing.study.stacktrace.deadlock.TestThread2":
  waiting to lock monitor 0x000000000a9ad118 (object 0x00000000d77363d0, a java.lang.Object),
  which is held by "org.ccgogoing.study.stacktrace.deadlock.TestThread1"
"org.ccgogoing.study.stacktrace.deadlock.TestThread1":
  waiting to lock monitor 0x000000000a9abc78 (object 0x00000000d77363e0, a java.lang.Object),
  which is held by "org.ccgogoing.study.stacktrace.deadlock.TestThread2"

Java stack information for the threads listed above:
===================================================
"org.ccgogoing.study.stacktrace.deadlock.TestThread2":
    at org.ccgogoing.study.stacktrace.deadlock.TestThread2.fun(TestThread2.java:35)
    - waiting to lock <0x00000000d77363d0> (a java.lang.Object)
    - locked <0x00000000d77363e0> (a java.lang.Object)
    at org.ccgogoing.study.stacktrace.deadlock.TestThread2.run(TestThread2.java:22)
"org.ccgogoing.study.stacktrace.deadlock.TestThread1":
    at org.ccgogoing.study.stacktrace.deadlock.TestThread1.fun(TestThread1.java:33)
    - waiting to lock <0x00000000d77363e0> (a java.lang.Object)
    - locked <0x00000000d77363d0> (a java.lang.Object)
    at org.ccgogoing.study.stacktrace.deadlock.TestThread1.run(TestThread1.java:20)

Found 1 deadlock.

從打印的堆棧中我們能看到"Found one Java-level deadlock:",即如果存在死鎖情況,堆棧中會直接給出死鎖的分析結果.

當一組Java線程發生死鎖的時候,那么意味著Game Over,這些線程永遠得被掛在那里了,永遠不可能繼續運行下去。當發生死鎖的線程在執行系統的關鍵功能時，那么這個死鎖可能會導致整個系統癱瘓，要想恢復系統，臨時也是唯一的規避方法是將系統重啟。然后趕快去修改導致這個死鎖的Bug。

注意：死鎖的兩個或多個線程是不消耗CPU的，有的人認為CPU100%的使用率是線程死鎖導致的，這個說法是完全錯誤的。死循環，并且在循環中代碼都是CPU密集型，才有可能導致CPU的100%使用率，像socket或者數據庫等IO操作是不怎么消耗CPU的。

GPU云服務器云服務器 java死鎖線程分析 java堆棧 java創建整型堆棧 Java線程嵌套線程

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/70826.html

Java Trouble Shooting - 使用線程棧

摘要：線程的優先級代表線程的優先級為線程代表線程為，而代表該線程對應的操作系統級別的線程。若是有運行圖形界面的環境，也可以使用一些圖形化的工具，例如來生成線程棧文件。使用線程棧定位問題發現死鎖當兩個或多個線程正在等待被對方占有的鎖，死鎖就會發生。什么是線程棧(thread dump) 線程棧是某個時間點，JVM所有線程的活動狀態的一個匯總；通過線程棧，可以查看某個時間點，各個線程正在做什么...

DataPipeline 2019-08-16 10:30 評論0 收藏0
JVM詳解3.JDK監控和故障處理工具

摘要：點擊進入我的博客命令行工具這些工具大多數是類庫的一層薄的包裝，它們的主要功能代碼是在類庫中實現的。可視化工具是到目前為止隨發布的功能最強大的運行監視和故障處理程序，并且可以預見在未來一段時間內都是官方主力發展的虛擬機故障處理工具。點擊進入我的博客 3.1 JDK命令行工具 showImg(https://segmentfault.com/img/remote/14600000174...

Keven 2019-08-16 14:02 評論0 收藏0
Java進程CPU占用率100%問題排查

摘要：指的是占用了一個核心，兩個核心是，以此類推。占用率及對應進程可以通過命令確定，在界面按顯示完整的命令行參數，按顯示每個核心的統計數據。查看線程堆棧，找到對應的類及行號，然后閱讀代碼查找可能的問題原因。 100%指的是占用了CPU一個核心，兩個核心是200%，以此類推。CPU占用率及對應進程ID（pid）可以通過top命令確定，在top界面按 c （顯示完整的命令行參數），按 1 （顯示...

cyrils 2019-08-16 15:53 評論0 收藏0
一次線上問題排查所引發的思考

摘要：直到有一天你會碰到線上奇奇怪怪的問題，如線程執行一個任務遲遲沒有返回，應用假死。正好這次借助之前的一次生產問題來聊聊如何排查和解決問題。本地模擬上文介紹的是線程相關問題，現在來分析下內存的問題。盡可能的減少多線程競爭鎖。 showImg(https://segmentfault.com/img/remote/1460000015568421?w=2048&h=1150); 前言之前或...

levy9527 2019-08-16 12:41 評論0 收藏0
Treiber Stack簡單分析

摘要：在添加新項目時使用堆棧，將堆棧的頂部放在新項目之后。當從堆棧中彈出一個項目時，在返回項目之前，您必須檢查另一個線程自操作開始以來沒有添加其他項目。比較和交換將堆棧的頭部設置為堆棧中舊的第二個元素，混合完整的數據結構。 Abstract Treiber Stack Algorithm是一個可擴展的無鎖棧，利用細粒度的并發原語CAS來實現的，Treiber Stack在 R. Kent T...

junfeng777 2019-08-16 10:58 評論0 收藏0