1. Introduction to the use of Jstack
This command prints the stack trace of the java thread, you can know which threads are blocked or waiting, so as to find the cause of thread deadlock, such as
usage:
jstack [ option ] pid
jstack [ option ] executable core
jstack [ option ] [server-id@]remote-hostname-or-IP Common options:
-F 当’jstack [-l] pid’没有相应的时候强制打印栈信息
-l 长列表. 打印关于锁的附加信息,例如属于java.util.concurrent的ownable synchronizers列表.
-m 打印java和native c/c++框架的所有栈信息.
常用参数：
core 将被打印信息的core dump文件
remote-hostname-or-IP 远程debug服务的主机名或ip
server-id 唯一id,假如一台主机上多个远程debug服务
id 需要被打印配置信息的java进程id,可以用jps查询2. Types of tomcat thread states
1. A thread whose state is "waiting on condition"
indicates that it is waiting for another condition to occur to wake itself up, or it simply calls sleep(N).
At this time, the thread state is roughly as follows:
• java.lang.Thread.State: WAITING (parking): wait for that condition to happen;
• java.lang.Thread.State: TIMED_WAITING (parking or sleeping): timed, that If the conditions do not come, it will also wake up regularly.
If a large number of threads are in the "waiting on condition":
it may be that they run to obtain third-party resources, especially third-party network resources, and fail to obtain Response for a long time, causing a large number of threads to enter the waiting state.
So if you find that a large number of threads are in the Wait on condition, from the thread stack, they are waiting for the network to read and write, this may be a sign of a network bottleneck, because the network blockage prevents the thread from executing.
Example 1: Timed, if the condition does not come, it will wake up regularly.
"ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon prio=10 tid=0x00007f67a419a800 nid=0x4655 waiting on condition [0x00007f679a3fd000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1510)
at java.lang.Thread.run(Thread.java:745)Example 2: Waiting for that condition to happen
"http-nio-8080-exec-1" daemon prio=10 tid=0x00007f677ca95800 nid=0x46a8 waiting on condition [0x00007f679a47e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000007a0399b28> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)1) The timed_waiting in "TIMED_WAITING (parking)" refers to the waiting state, but the time is specified here, and the waiting state is automatically exited after the specified time; parking refers to the thread being suspended.
2) "waiting on condition" needs to be combined with "parking to wait for <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack)" in the stack. First, the thread must be waiting for a condition to occur to wake itself up. Secondly, SynchronousQueue is not a queue, but a mechanism for transferring information between threads. When we put an element into SynchronousQueue, another thread must be waiting for the task to be handed over, so this is the condition that this thread is waiting for
Example 3
"RMI RenewClean-[10.24.189.110:1919]" daemon prio=10 tid=0x00007f6764ee1000 nid=0x4764 in Object.wait() [0x00007f67859b9000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked <0x00000007a1bca328> (a java.lang.ref.ReferenceQueue$Lock)
at sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:535)
at java.lang.Thread.run(Thread.java:745)Example 4
"Timer-8" daemon prio=10 tid=0x00007f676c032800 nid=0x5b7d in Object.wait() [0x00007f6785833000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.util.TimerThread.mainLoop(Timer.java:552)
- locked <0x00000007b47c7630> (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:505)2. The thread state is "waiting for monitor entry":
it means it is waiting to enter a critical section, so it is waiting in the "Entry Set" queue.
At this time, the thread state is generally Blocked:
java.lang.Thread.State: BLOCKED (on object monitor)
3. If a large number of threads are "waiting for monitor entry" :
a global lock may be blocking a large number of threads.
If the thread dump file printed in a short period of time reflects that, as time goes by, more and more threads are waiting for monitor entry, and there is no decreasing trend, it may mean that some threads stay in the critical section for too long, so As for more and more new threads, it is slow to enter the critical section.
3. Example operation:
[root@tomcat01 conf]# jps
13886 Jps
21147 Application
13614 Bootstrap[root@tomcat01 conf]# jstack 13614|grep "java.lang.Thread.State"|grep parking
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: TIMED_WAITING (parking)[root@tomcat01 conf]# jstack 13614|grep "java.lang.Thread.State"|grep parking|wc -l
41
java.lang.Thread.State: The number of WAITING (parking) is equal to the minimum number of idle threads in minsparethread Numerical value
Check for deadlock
[root@VM_82_178_redhat ~]# jstack -l -F 7523
Attaching to process ID 7523, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.60-b23
Deadlock Detection:
**No deadlocks found**.