本文主要是介绍jstack的用途(简),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
jstack作用:用于显示指定进程内线程的信息
语法:jstack [option] <pid>
-F 当’jstack [-l] pid’没有响应的时候强制打印栈信息,(如果直接jstack无响应时,用于强制jstack),一般情况不需要使用
-l 长列表. 打印关于锁的附加信息,例如属于java.util.concurrent的ownable synchronizers列表,会使得JVM停顿得长久得多(可能会差很多倍,比如普通的jstack可能几毫秒和一次GC没区别,加了-l 就是近一秒的时间),-l 建议不要用。一般情况不需要使用
-m 打印java和native c/c++框架的所有栈信息.可以打印JVM的堆栈,显示上Native的栈帧,一般应用排查不需要使用
pid:进程id
下面给出执行命令后的结果:
C:\Users\THG>jstack -F 15884
Attaching to process ID 15884, please wait...
Debugger attached successfully.
Client compiler detected.
JVM version is 25.131-b11
Deadlock Detection:No deadlocks found.Thread 10: (state = BLOCKED)Thread 9: (state = BLOCKED)Thread 8: (state = BLOCKED)- java.lang.Object.wait(long) @bci=0 (Interpreted frame)- java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Interpreted frame)- java.lang.ref.ReferenceQueue.remove() @bci=2, line=164 (Interpreted frame)- java.lang.ref.Finalizer$FinalizerThread.run() @bci=36, line=209 (Interpreted frame)Thread 7: (state = BLOCKED)- java.lang.Object.wait(long) @bci=0 (Interpreted frame)- java.lang.Object.wait() @bci=2, line=502 (Interpreted frame)- java.lang.ref.Reference.tryHandlePending(boolean) @bci=54, line=191 (Interpreted frame)- java.lang.ref.Reference$ReferenceHandler.run() @bci=1, line=153 (Interpreted frame)Thread 5: (state = IN_JAVA)- neicunjiankong.One.main(java.lang.String[]) @bci=0, line=17 (Interpreted frame)
C:\Users\THG>jstack -l 15884
2019-07-21 16:19:46
Full thread dump Java HotSpot(TM) Client VM (25.131-b11 mixed mode, sharing):"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x02ef9400 nid=0x5164 runnable [0x00000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"C1 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x02ef2400 nid=0x38f4 waiting on condition [0x00000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x02ef1400 nid=0x2adc waiting on condition [0x00000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x02edc800 nid=0x521c runnable [0x00000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x02ed4000 nid=0x535c in Object.wait() [0x155cf000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on <0x05008978> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)- locked <0x05008978> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)Locked ownable synchronizers:- None"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x02e77000 nid=0x309c in Object.wait() [0x1553f000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on <0x05006a90> (a java.lang.ref.Reference$Lock)at java.lang.Object.wait(Object.java:502)at java.lang.ref.Reference.tryHandlePending(Reference.java:191)- locked <0x05006a90> (a java.lang.ref.Reference$Lock)at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)Locked ownable synchronizers:- None"main" #1 prio=5 os_prio=0 tid=0x02a8c800 nid=0x5348 runnable [0x0295f000]java.lang.Thread.State: RUNNABLEat neicunjiankong.One.main(One.java:17)Locked ownable synchronizers:- None"VM Thread" os_prio=2 tid=0x02e73400 nid=0x529c runnable"VM Periodic Task Thread" os_prio=2 tid=0x15ee0800 nid=0x380 waiting on conditionJNI global references: 6
上面代码解读:“Service Thread”中的 daemon表示线程是否是守护线程;
“C1 Compiler Thread()”中的prio指线程的优先级
"Attach Listener"中
os_prio指该线程对应的操作系统线程的优先级;
tid:java中线程编号;
nid:即native id,该线程对应的操作系统中本地线程编号,每一个java线程都有一个对应的操作系统线程。
"Finalizer"指线程名;下一行中的java.lang.Thread.State:指线程状态;WAITING (on object monitor):表示该线程处于等待状态,括号中的内容说明了导致等待的原因。
C:\Users\THG>jstack -m 15884
Attaching to process ID 15884, please wait...
Debugger attached successfully.
Client compiler detected.
JVM version is 25.131-b11
Deadlock Detection:No deadlocks found.----------------- 0 -----------------
0x7797a8fc ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2 KERNELBASE!WaitForSingleObject + 0x12
0x010f5055 javaw + 0x5055
0x010f33aa javaw + 0x33aa
0x010f4497 javaw + 0x4497
0x010f3638 javaw + 0x3638
0x00000003 ????????
0x08009f99 ????????
----------------- 1 -----------------
0x7797c58c ntdll!ZwWaitForWorkViaWorkerFactory + 0xc
0x767c8494 KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8 ntdll!RtlAreBitsSet + 0x88
0x77974198 ntdll!RtlAreBitsSet + 0x58
----------------- 2 -----------------
0x02f620e4 * neicunjiankong.One.main(java.lang.String[]) bci:0 line:17 (Interpreted frame)
0x02f50697 <StubRoutines>
0x65eaaf45 jvm!JVM_GetThreadStateNames + 0x4d395
0x65f713ae jvm!_JVM_FindSignal@4 + 0x6402e
0x65eaafde jvm!JVM_GetThreadStateNames + 0x4d42e
0x65e2cb97 jvm!JNI_GetCreatedJavaVMs + 0x6f27
0x65e3512f jvm!JNI_GetCreatedJavaVMs + 0xf4bf
0x010f22ab javaw + 0x22ab
0x010faebf javaw + 0xaebf
0x010faf49 javaw + 0xaf49
0x767c8494 KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8 ntdll!RtlAreBitsSet + 0x88
0x77974198 ntdll!RtlAreBitsSet + 0x58
----------------- 3 -----------------
0x7797a8fc ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2 KERNELBASE!WaitForSingleObject + 0x12
0x65f0fbcd jvm!_JVM_FindSignal@4 + 0x284d
0x65eacbdc jvm!JVM_GetThreadStateNames + 0x4f02c
0x65eacf0c jvm!JVM_GetThreadStateNames + 0x4f35c
0x65ed2b41 jvm!JVM_GetThreadStateNames + 0x74f91
0x65ed2f02 jvm!JVM_GetThreadStateNames + 0x75352
0x65f12ec6 jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556 msvcr100!_endthreadex + 0x3a
0x6d4bc600 msvcr100!_endthreadex + 0xe4
0x767c8494 KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8 ntdll!RtlAreBitsSet + 0x88
0x77974198 ntdll!RtlAreBitsSet + 0x58
----------------- 4 -----------------
0x7797a8fc ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2 KERNELBASE!WaitForSingleObject + 0x12
0x65f0fcd9 jvm!_JVM_FindSignal@4 + 0x2959
0x65eb1c11 jvm!JVM_GetThreadStateNames + 0x54061
0x65ec7744 jvm!JVM_GetThreadStateNames + 0x69b94
0x65e52155 jvm!_JVM_MonitorWait@16 + 0x95
0x02f5d3d3 * java.lang.Object.wait(long) bci:0 (Interpreted frame)
0x02f54854 * java.lang.Object.wait() bci:2 line:502 (Interpreted frame)
0x02f54854 * java.lang.ref.Reference.tryHandlePending(boolean) bci:54 line:191 (Interpreted frame)
0x02f54300 * java.lang.ref.Reference$ReferenceHandler.run() bci:1 line:153 (Interpreted frame)
0x02f50697 <StubRoutines>
0x65eaaf45 jvm!JVM_GetThreadStateNames + 0x4d395
0x65f713ae jvm!_JVM_FindSignal@4 + 0x6402e
0x65eaafde jvm!JVM_GetThreadStateNames + 0x4d42e
0x65eab166 jvm!JVM_GetThreadStateNames + 0x4d5b6
0x65eab1d7 jvm!JVM_GetThreadStateNames + 0x4d627
0x65e4f36f jvm!jio_printf + 0x9f
0x65ecdc30 jvm!JVM_GetThreadStateNames + 0x70080
0x65ece4aa jvm!JVM_GetThreadStateNames + 0x708fa
0x65f12ec6 jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556 msvcr100!_endthreadex + 0x3a
0x6d4bc600 msvcr100!_endthreadex + 0xe4
0x767c8494 KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8 ntdll!RtlAreBitsSet + 0x88
0x77974198 ntdll!RtlAreBitsSet + 0x58
----------------- 5 -----------------
0x7797a8fc ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2 KERNELBASE!WaitForSingleObject + 0x12
0x65f0fcd9 jvm!_JVM_FindSignal@4 + 0x2959
0x65eb1c11 jvm!JVM_GetThreadStateNames + 0x54061
0x65ec7744 jvm!JVM_GetThreadStateNames + 0x69b94
0x65e52155 jvm!_JVM_MonitorWait@16 + 0x95
0x02f5d3d3 * java.lang.Object.wait(long) bci:0 (Interpreted frame)
0x02f54854 * java.lang.ref.ReferenceQueue.remove(long) bci:59 line:143 (Interpreted frame)
0x02f547b4 * java.lang.ref.ReferenceQueue.remove() bci:2 line:164 (Interpreted frame)
0x02f547b4 * java.lang.ref.Finalizer$FinalizerThread.run() bci:36 line:209 (Interpreted frame)
0x02f50697 <StubRoutines>
0x65eaaf45 jvm!JVM_GetThreadStateNames + 0x4d395
0x65f713ae jvm!_JVM_FindSignal@4 + 0x6402e
0x65eaafde jvm!JVM_GetThreadStateNames + 0x4d42e
0x65eab166 jvm!JVM_GetThreadStateNames + 0x4d5b6
0x65eab1d7 jvm!JVM_GetThreadStateNames + 0x4d627
0x65e4f36f jvm!jio_printf + 0x9f
0x65ecdc30 jvm!JVM_GetThreadStateNames + 0x70080
0x65ece4aa jvm!JVM_GetThreadStateNames + 0x708fa
0x65f12ec6 jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556 msvcr100!_endthreadex + 0x3a
0x6d4bc600 msvcr100!_endthreadex + 0xe4
0x767c8494 KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8 ntdll!RtlAreBitsSet + 0x88
0x77974198 ntdll!RtlAreBitsSet + 0x58
----------------- 6 -----------------
0x7797a8fc ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2 KERNELBASE!WaitForSingleObject + 0x12
0x65f13519 jvm!_JVM_FindSignal@4 + 0x6199
0x65f135e7 jvm!_JVM_FindSignal@4 + 0x6267
0x65ecdc30 jvm!JVM_GetThreadStateNames + 0x70080
0x65ece4aa jvm!JVM_GetThreadStateNames + 0x708fa
0x65f12ec6 jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556 msvcr100!_endthreadex + 0x3a
0x6d4bc600 msvcr100!_endthreadex + 0xe4
0x767c8494 KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8 ntdll!RtlAreBitsSet + 0x88
0x77974198 ntdll!RtlAreBitsSet + 0x58
----------------- 7 -----------------
0x7797a8fc ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2 KERNELBASE!WaitForSingleObject + 0x12
0x65f0c5d2 jvm!JVM_GetThreadStateNames + 0xaea22
0x65ecdc30 jvm!JVM_GetThreadStateNames + 0x70080
0x65ece4aa jvm!JVM_GetThreadStateNames + 0x708fa
0x65f12ec6 jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556 msvcr100!_endthreadex + 0x3a
0x6d4bc600 msvcr100!_endthreadex + 0xe4
0x767c8494 KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8 ntdll!RtlAreBitsSet + 0x88
0x77974198 ntdll!RtlAreBitsSet + 0x58
----------------- 8 -----------------
0x7797a8fc ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2 KERNELBASE!WaitForSingleObject + 0x12
0x65f0fbcd jvm!_JVM_FindSignal@4 + 0x284d
0x65eacbdc jvm!JVM_GetThreadStateNames + 0x4f02c
0x65eacf5a jvm!JVM_GetThreadStateNames + 0x4f3aa
0x65dc0b5b jvm!_JVM_GetManagementExt@4 + 0x5565b
0x65ecdc30 jvm!JVM_GetThreadStateNames + 0x70080
0x65ece4aa jvm!JVM_GetThreadStateNames + 0x708fa
0x65f12ec6 jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556 msvcr100!_endthreadex + 0x3a
0x6d4bc600 msvcr100!_endthreadex + 0xe4
0x767c8494 KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8 ntdll!RtlAreBitsSet + 0x88
0x77974198 ntdll!RtlAreBitsSet + 0x58
----------------- 9 -----------------
0x7797a8fc ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2 KERNELBASE!WaitForSingleObject + 0x12
0x65f0fcd9 jvm!_JVM_FindSignal@4 + 0x2959
0x65eacbd1 jvm!JVM_GetThreadStateNames + 0x4f021
0x65eacf0c jvm!JVM_GetThreadStateNames + 0x4f35c
0x65ebb9b1 jvm!JVM_GetThreadStateNames + 0x5de01
0x65ecdc30 jvm!JVM_GetThreadStateNames + 0x70080
0x65ece4aa jvm!JVM_GetThreadStateNames + 0x708fa
0x65f12ec6 jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556 msvcr100!_endthreadex + 0x3a
0x6d4bc600 msvcr100!_endthreadex + 0xe4
0x767c8494 KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8 ntdll!RtlAreBitsSet + 0x88
0x77974198 ntdll!RtlAreBitsSet + 0x58
----------------- 10 -----------------
0x7797a8fc ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2 KERNELBASE!WaitForSingleObject + 0x12
0x65f0fbcd jvm!_JVM_FindSignal@4 + 0x284d
0x65eacbdc jvm!JVM_GetThreadStateNames + 0x4f02c
0x65eacf0c jvm!JVM_GetThreadStateNames + 0x4f35c
0x65ec8c94 jvm!JVM_GetThreadStateNames + 0x6b0e4
0x65ec8d37 jvm!JVM_GetThreadStateNames + 0x6b187
0x65f12ec6 jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556 msvcr100!_endthreadex + 0x3a
0x6d4bc600 msvcr100!_endthreadex + 0xe4
0x767c8494 KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8 ntdll!RtlAreBitsSet + 0x88
0x77974198 ntdll!RtlAreBitsSet + 0x58
----------------- 11 -----------------
0x7797c58c ntdll!ZwWaitForWorkViaWorkerFactory + 0xc
0x767c8494 KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8 ntdll!RtlAreBitsSet + 0x88
0x77974198 ntdll!RtlAreBitsSet + 0x58
执行jstack pid命令:查看pid进程内线程信息:结果就是以上三个命令的结果加在一块。
线程与Monitor:
进入区(Entrt Set):表示线程通过synchronized要求获取对象的锁。如果对象未被锁住,则迚入拥有者;否则则在进入区等待。一旦对象锁被其他线程释放,立即参与竞争。
拥有者(The Owner):表示某一线程成功竞争到对象锁。
等待区(Wait Set) :表示线程通过对象的wait方法,释放对象的锁,并在等待区等待被唤醒。
说明:
一个 Monitor在某个时刻,只能被一个线程拥有,该线程就是 “Active Thread”,而其它线程为“Waiting Thread”,分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitor entry”,而在“Wait Set”中等待的线程状态是 “in Object.wait()”。 被 synchronized保护起来的代码段称为临界区,当一个线程申请进入临界区时,它就进入了 “Entry Set”队列。
线程状态:
1、NEW:线程刚刚被创建,也就是已经new过了,但是还没有调用start()方法,jstack命令不会列出处于此状态的线程信息。
2、RUNNABLE:RUNNABLE这个名字很具有欺骗性,很容易让人误以为处于这个状态的线程正在运行;事实上,这个状态只是表示,线程是可运行的。一个单核CPU在同一时刻,只能运行一个线程。
3、BLOCKED:线程处于阻塞状态,正在等待一个监视器锁(monitor lock)。通常情况下,是因为本线程与其他线程公用了一个锁。其他在线程正在使用这个锁进入某个synchronized同步方法块或者方法,而本线程进入这个同步代码块也需要这个锁,最终导致本线程处于阻塞状态,
4、WAITING:等待状态,等待某个condition或monitor发生,调用以下方法可能会导致一个线程处于等待状态:(以下方法,可用线程调用,再用jstack -l <pid>查看相关信息)
wait() 不指定超时时间,
join() 不指定超时时间,
park()
5、TIMED_WAITING:线程等待指定的时间,对于以下方法的调用,可能会导致线程处于这个状态:(以下方法,可用线程调用,再用jstack -l <pid>查看相关信息)
wait(long timeout) 指定超时时间,
join(long millis) 指定超时时间,
sleep(long millis) 指定超时时间,
parkNanos(long nanos)
parkUntil(long deadline)
6、TERMINATED:线程终止。
一个例子:
执行java代码:public static void main(String[] args) {Object lock = new Object();synchronized (lock) {try {lock.wait();} catch (InterruptedException e) {e.printStackTrace();}}}执行jstack命令
C:\Users\THG>jstack 14456
2019-07-21 18:11:46
Full thread dump Java HotSpot(TM) Client VM (25.131-b11 mixed mode, sharing):"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00cf7800 nid=0x3520 runnable [0x00000000]java.lang.Thread.State: RUNNABLE"C1 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x00cf0c00 nid=0x28ac waiting on condition [0x00000000]java.lang.Thread.State: RUNNABLE"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x00cef800 nid=0x1f64 waiting on condition [0x00000000]java.lang.Thread.State: RUNNABLE"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x00cdc800 nid=0x4fa4 runnable [0x00000000]java.lang.Thread.State: RUNNABLE"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x00cd4000 nid=0xfa4 in Object.wait() [0x14c7f000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on <0x04608978> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)- locked <0x04608978> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x00c77000 nid=0x544c in Object.wait() [0x14bef000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on <0x04606a90> (a java.lang.ref.Reference$Lock)at java.lang.Object.wait(Object.java:502)at java.lang.ref.Reference.tryHandlePending(Reference.java:191)- locked <0x04606a90> (a java.lang.ref.Reference$Lock)at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)"main" #1 prio=5 os_prio=0 tid=0x0082c800 nid=0x5650 in Object.wait() [0x0087f000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)//下面是重点- waiting on <0x046bc4a8> (a java.lang.Object)at java.lang.Object.wait(Object.java:502)at neicunjiankong.One.main(One.java:9)- locked <0x046bc4a8> (a java.lang.Object)"VM Thread" os_prio=2 tid=0x00c73400 nid=0x407c runnable"VM Periodic Task Thread" os_prio=2 tid=0x14f50800 nid=0x1ad8 waiting on conditionJNI global references: 6
1、main线程先locked <0x048ba168>
,再waiting on <0x048ba168>
,之所以先锁再等同一个对象,是因为wait方法需要先通过synchronized获得该地址对象的monitor;
2
、waiting on <0x048ba168>
说明线程执行了wait方法之后,释放了monitor,进入到"Wait Set"队列,等待其它线程执行地址为0x048ba168
对象的notify方法,并唤醒自己,
这篇关于jstack的用途(简)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!