3r33965. In the program of the course 3r3-3966. Java
developer. There are quite a few topics dedicated to the insides of the JVM. We understand the mechanisms of collections, bytecode, garbage collection, etc. 3r33962.  3r33975. Today we offer your heed a translation of a rather interesting article on thread dump. What it is, how to get it and how to use it. [/i] 3r33939. 3r33962.  3r33975.
Want to know how to analyze a thread dump? Come under the cat to learn more about how to get thread dump in Java and what to do with it. 3r33939. Amdahl's Law ), You can achieve a significant increase in application performance. However, it should be remembered about ensuring synchronous access of several threads to a shared resource. In most cases, frameworks such as Spring encapsulate work with threads and hide many technical details from users. However, in the case of the use of modern complex frameworks, something can go wrong, and we, as users, will encounter difficult solvable multi-threading bugs. 3r33939. 3r33962.  3r33975.
Fortunately, Java is equipped with a special mechanism for obtaining information about the current state of all threads at any given time - this is a thread dump (a kind of snapshot). In this article, we will learn how to get a thread dump for an application of realistic dimensions and how to analyze this dump. It is assumed that the reader has basic information about multi-threaded programming and is aware of the problems of thread synchronization and the use of shared resources. Nevertheless, it will not be superfluous to brush up on some basic terms and concepts. 3r33939. 3r33962.  3r33975. 3r-33199. Basic terminology 3-333200. 3r33962.  3r33975.
At first glance, Java thread dumps may seem like a “Chinese letter”, the key to which I understand is the following concepts. In general, let's repeat the main terms of multithreading, which we will use for the analysis of dumps. 3r33939. 3r33921.  3r33975. 3r33938. 3r33838. Thread
or a stream is a discrete multithreading unit, driven by a Java Virtual Machine (JVM). JVM threads correspond to threads in the operating system (OS) —native threads (“natural flows”), which implement the code execution mechanism. 3r33962.  3r33975. Each thread has a unique identifier and name. Threads can be “demons” and “non-demons.” The program ends when all threads are not “non-demons” or the method 3r36565 is called. Runtime.exit [/i] . Working "demons" do not affect the completion of the program. Those. JVMs are waiting for all the “non-demons” to be finalized and shutting down; they are not paying attention to the “non-demons”. 3r33962.  3r33975. For more information, see the documentation. Thread class 3r3679. . 3r33962.  3r33975. The stream can be in one of the following states: 3r33921.  3r33975. 3r33938. 3r33838. Alive thread
or “live” is a thread that does some work (normal state). 3r33941.  3r33975. 3r33938. 3r33838. Blocked thread
or “blocked” - the stream that tried to enter the synchronized section (synchronized), however, another stream has already managed to enter this block first, and all the following streams that try to enter the same block are blocked. 3r33941.  3r33975. 3r33938. 3r33838. Waiting thread
or “pending” is the thread that caused the 3r36565 method. wait [/i] (possibly with an indication of a timeout) and is now waiting for another method to execute 3r-3965. notify [/i] or nonifyAll at the same facility. 3r33962.  3r33975. Note that the thread is not considered “waiting” if it has called a wait with a timeout and this timeout has expired. 3r33941.  3r33975. 3r33938. 3r33838. Sleeping thread
or “sleeping” is a thread that is not currently being executed, since performed the Thread.sleep method (indicating the duration of the "sleep"). 3r33941.  3r33975. 3r33943. 3r33941.  3r33975. 3r33938. 3r33838. Monitor
Is the mechanism used by the JVM to provide multi-threaded access to a single object. The mechanism is triggered by the special keyword 3r-33965. synchronized [/i] Each object in Java has a monitor with which the stream can synchronize, i.e. set a lock, which guarantees that no other thread will gain access to this object until the lock is released, i.e. flow - the lock owner will not exit block synchronized . 3r33962.  3r33975. For more information, see
Synchronization section (17.1) of the Java Langauge Specification (JLS) . 3r33941.  3r33975. 3r33938. 3r33838. Deadlock
- this is a situation in which the flow, say A, blocks the resource, it needs another resource that is blocked by another flow, say B. Flow B does not release this resource, because to complete a certain operation, it needs a resource that is blocked by stream A. It turns out that stream A is waiting for the resource to be unlocked by thread B, which is waiting for the unlock of another resource by stream A. And, thus, the threads are waiting for each other. As a result, the whole program is “hanging” and waiting for the threads to somehow unlock and continue working. There can be many threads in a deadlock. This problem is well known as "The Problem of Dining Philosophers" . 3r33962.  3r33975. 3r3108. 3r33941.  3r33975. 3r33938. 3r33838. Livelock
- this is a situation where the flow A causes the flow B to perform some action, which in turn leads to the execution of the flow A of the original action, which once again causes the action of the flow B. A cyclical dependence is obtained. This can be imagined as a dog running after its tail. Similarly, 3r33965. Deadlock [/i] In a Livelock situation, the program does not make progress, i.e. does not perform a useful action, however, in this situation, threads are not blocked. 3r33941.  3r33975. 3r33943. 3r33962.  3r33975.
The terminology presented is not exhaustive for describing the world of multithreading, but this is enough to begin analyzing thread dumps. 3r33962.  3r33975. More detailed information can be found in these sources: Section 17 of the JLS and 3r3r126. Java Concurrency in Practice
3r33939. 3r33962.  3r33975.
By applying these simple notions about flow in Java, we can create a test application. For this application we will collect thread dump. The resulting dump will analyze and extract useful information about the current flows of the application. 3r33939. 3r33962.  3r33975. 3r-33199. Creating an example program 3r33200. 3r33962.  3r33975.
Before creating a thread dump, we need to develop a Java application. The traditional “hello, world!” Is too simple for our purpose, and a medium sized application dump may be too difficult to demonstrate. Based on this, we will create a fairly simple application in which two streams are created. And the threads fall into deadlock:
3r33962.  3r33975.
3r33855. public class DeadlockProgram {
public static void main (String[]args) throws Exception {3r3393975. Object resourceA = new Object (); 3r33975. Object resourceB = new Object (); 3r33975. Thread threadLockingResourceAFirst = new Thread (new DeadlockRunnable (resourceA, resourceB)); 3r33975. Thread threadLockingResourceBFirst = new Thread (new DeadlockRunnable (resourceB, resourceA)); 3r33975. threadLockingResourceAFirst.start (); 3r33975. Thread.sleep (500); 3r33975. threadLockingResourceBFirst.start (); 3r33975.}
private static class DeadlockRunnable implements Runnable {
private final Object firstResource; 3r33975. private final Object secondResource; 3r33975. public DeadlockRunnable (Object firstResource, Object secondResource) {
this.firstResource = firstResource; 3r33975. this.secondResource = secondResource; 3r33975.}
@Override
public void run () {
try {3r3759. synchronized (firstResource) {
printLockedResource (firstResource); 3r33975. Thread.sleep (1000); 3r33975. synchronized (secondResource) {
printLockedResource (secondResource); 3r33975.}
}
} catch (InterruptedException e) {
System.out.println ("Exception occurred:" + e); 3r33975.}
}
private static void printLockedResource (Object resource) {
System.out.println (Thread.currentThread (). GetName () + ": locked resource ->" + resource); 3r33975.}
}
}
3r33892. 3r3904. 3r33962.  3r33975.
This program creates two resources: resourceA and resourceB, and starts two threads: threadLockingResourceAFirst and threadLockingResourceBFirst, which block each other’s resources. The cause of the deadlock is a “cross” blocking of resources by the threads. . thread threadLockingResourceAFirst captures resource resourceA, thread threadLockingResourceBFirst captures resource resourceB. After that, the thread threadLockingResourceAFirst, without releasing its resource, attempts to capture resourceB, and the thread threadLockingResourceBFirst, without releasing its resource, attempts to capture resource ResourceA. As a result, threads are blocked. A 1c delay is added to ensure blocking occurs. The streams are waiting for the release of the necessary resources, but this will never happen. 3r33939. 3r33962.  3r33975.
The output of the program will be as follows (the numbers after java.lang.Object @ will be different for each launch): 3r3393969.
Thread-0: locked resource -> [email protected]: locked resource -> java.lang.[email protected]
3r33962.  3r33975.
After the output of these messages, the program will look like working (the process that executes this program is not completed), while the program does not perform any work. This is how deadlock looks like in practice. To solve the problem, we need to manually create a tread dump and analyze the state of the threads. 3r33939. 3r33962.  3r33975. 3r-33199. Generate Thread Dump
3r33962.  3r33975.
In practice, a Java program can crash and create a thread dump. However, in some cases (for example, in the case of deadlocks), the program does not terminate and the thread dump does not create, it just hangs. To create a dump of such hung programs, first of all you need to find out the program process ID, i.e. Process ID (PID). To do this, you can use the JVM Process Status (JPS) utility, which, since version ? is part of the Java Development Kit (JDK). To find the PID process of our hung program, we simply run jps in the terminal (Windows or Linux): 3r36262.  3r33975. 3r33939.
$ jps11568 DeadlockProgram15584 Jps15636
3r33962.  3r33975.
The first column is the local virtual machine identifier (Local VM ID, i.e. lvmid) for the running Java process. In the context of the local JVM, lvmid points to the PID of the Java process. It should be noted that this value is likely to differ from the value above. The second column is the name of the application, which may indicate the name of the main class, jar-file or be equal to "Unknown". It all depends on how the application was launched. 3r33939. 3r33962.  3r33975.
In our case, the application name DeadlockProgram is the name of the main classes that was launched when the program started. In the example above, the PID of the program is 1156? this information is enough to generate a thread dump. To generate a dump, we will use the utility 3r3-3309. jstack
, which is part of the JDK, starting with version 7. To get the dump we will transfer to 3r33030. jstack
as the PID parameter of our program and specify the -l flag (create a long listing). The utility output is redirected to a text file, i.e. thread_dump.txt:
jstack -l 11568> thread_dump.txt
3r33962.  3r33975.
The resulting thread_dump.txt file contains a thread dump of our hung program and contains important information for diagnosing the causes of the deadlock. 3r33962.  3r33975. If you are using JDK up to version ? then you can use the Linux utility, 3r-3333? to generate the dump. kill
with a flag of -3. Calling kill -3 will send a SIGQUIT signal to the program. 3r33962.  3r33975. In our case, the call will be like this:
kill -???r3r3398. 3r33962.  3r33975.

Analysis of simple thread dump

3r33962.  3r33975.
Opening the file thread_dump.txt, we will see something like the following:
 3r33975. 3r33939.
3r33975. 3r33975. 2018-06-???:44:44
Full thread dump Java HotSpot (TM) 64-Bit Server VM (??? + 10 mixed mode):
Threads class SMR info:
_java_thread_list = 0x00000250e5488a0? length = 1? elements = {
0x00000250e497900? 0x00000250e498280? 0x00000250e52f280? 0x00000250e499280?
0x00000250e499580? 0x00000250e49a580? 0x00000250e49ae80? 0x00000250e532400?
0x00000250e54cd80? 0x00000250e54cf00? 0x00000250e54d180? 0x00000250e54d200?
0x00000250e54d0800
}
"Reference Handler" # 2 daemon prio = 10 os_prio = 2 tid = 0x00000250e4979000 nid = 0x3c28 waiting on condition[0x000000b82a9ff000]3r33975. java.lang.Thread.State: RUNNABLE
at java.lang.ref.Reference.waitForReferencePendingList ([email protected]???/Native Method)
at java.lang.ref.Reference.processPendingReferences ([email protected]???/Reference.java: 174)
at java.lang.ref.Reference.access $ 000 ([email protected]???/Reference.java: 44)
at java.lang.ref.Reference $ ReferenceHandler.run ([email protected]???/Reference.java: 138)
Locked ownable synchronizers:
- None
"Finalizer" # 3 daemon prio = 8 os_prio = 1 tid = 0x00000250e4982800 nid = 0x2a54 in Object.wait ()[0x000000b82aaff000]3r33975. java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait ([email protected]???/Native Method)
- waiting on <0x0000000089509410> (a java.lang.ref.ReferenceQueue $ Lock)
at java.lang.ref.ReferenceQueue.remove ([email protected]???/ReferenceQueue.java: 151)
- waiting for re-lock in wait () <0x0000000089509410> (a java.lang.ref.ReferenceQueue $ Lock)
at java.lang.ref.ReferenceQueue.remove ([email protected]???/ReferenceQueue.java: 172)
at java.lang.ref.Finalizer $ FinalizerThread.run ([email protected]???/Finalizer.java: 216)
Locked ownable synchronizers:
- None
"Signal Dispatcher" # 4 daemon prio = 9 os_prio = 2 tid = 0x00000250e52f2800 nid = 0x2184 runnable[0x0000000000000000]3r33975. java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"Attach Listener" # 5 daemon prio = 5 os_prio = 2 tid = 0x00000250e4992800 nid = 0x1624 waiting on condition[0x0000000000000000]3r33975. java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"C2 CompilerThread0" # 6 daemon prio = 9 os_prio = 2 tid = 0x00000250e4995800 nid = 0x4198 waiting on condition[0x0000000000000000]3r33975. java.lang.Thread.State: RUNNABLE
No compile task
Locked ownable synchronizers:
- None
"C2 CompilerThread1" # 7 daemon prio = 9 os_prio = 2 tid = 0x00000250e49a5800 nid = 0x3b98 waiting on condition[0x0000000000000000]3r33975. java.lang.Thread.State: RUNNABLE
No compile task
Locked ownable synchronizers:
- None
"C1 CompilerThread2" # 8 daemon prio = 9 os_prio = 2 tid = 0x00000250e49ae800 nid = 0x1a84 waiting on condition[0x0000000000000000]3r33975. java.lang.Thread.State: RUNNABLE
No compile task
Locked ownable synchronizers:
- None
"Sweeper thread" # 9 daemon prio = 9 os_prio = 2 tid = 0x00000250e5324000 nid = 0x5f0 runnable[0x0000000000000000]3r33975. java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"Service Thread" # 10 daemon prio = 9 os_prio = 0 tid = 0x00000250e54cd800 nid = 0x169c runnable[0x0000000000000000]3r33975. java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
Common-Cleaner # 11 daemon prio = 8 os_prio = 1 tid = 0x00000250e54cf000 nid = 0x1610 in Object.wait ()[0x000000b82b2fe000]3r33975. java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait ([email protected]???/Native Method)
- waiting on <0x000000008943e600> (a java.lang.ref.ReferenceQueue $ Lock)
at java.lang.ref.ReferenceQueue.remove ([email protected]???/ReferenceQueue.java: 151)
- waiting for re-lock in wait () <0x000000008943e600> (a java.lang.ref.ReferenceQueue $ Lock)
at jdk.internal.ref.CleanerImpl.run ([email protected]???/CleanerImpl.java: 148)
at java.lang.Thread.run ([email protected]???/Thread.java: 844)
at jdk.internal.misc.InnocuousThread.run ([email protected]???/InnocuousThread.java: 134)
Locked ownable synchronizers:
- None
"Thread-0" # 12 prio = 5 os_prio = 0 tid = 0x00000250e54d1800 nid = 0xdec waiting for monitor entry[0x000000b82b4ff000]3r33975. java.lang.Thread.State: BLOCKED (on object monitor)
at DeadlockProgram $ DeadlockRunnable.run (DeadlockProgram.java:34)
- waiting to lock <0x00000000894465b0> (a java.lang.Object)
- locked 3r31616. (a java.lang.Object)
at java.lang.Thread.run ([email protected]???/Thread.java: 844)
Locked ownable synchronizers:
- None
"Thread-1" # 13 prio = 5 os_prio = 0 tid = 0x00000250e54d2000 nid = 0x415c waiting for monitor entry[0x000000b82b5ff000]3r33975. java.lang.Thread.State: BLOCKED (on object monitor)
at DeadlockProgram $ DeadlockRunnable.run (DeadlockProgram.java:34)
- waiting to lock <0x00000000894465a0> (a java.lang.Object)
- locked 3r33838. (a java.lang.Object)
at java.lang.Thread.run ([email protected]???/Thread.java: 844)
Locked ownable synchronizers:
- None
"DestroyJavaVM" # 14 prio = 5 os_prio = 0 tid = 0x00000250e54d0800 nid = 0x2b8c waiting on condition[0x0000000000000000]3r33975. java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"VM Thread" os_prio = 2 tid = 0x00000250e496d800 nid = 0x1920 runnable
"GC Thread # 0" os_prio = 2 tid = 0x00000250c35b5800 nid = 0x310c runnable
"GC Thread # 1" os_prio = 2 tid = 0x00000250c35b8000 nid = 0x12b4 runnable
"GC Thread # 2" os_prio = 2 tid = 0x00000250c35ba800 nid = 0x43f8 runnable
"GC Thread # 3" os_prio = 2 tid = 0x00000250c35c0800 nid = 0x20c0 runnable
"G1 Main Marker" os_prio = 2 tid = 0x00000250c3633000 nid = 0x4068 runnable
"G1 Conc # 0" os_prio = 2 tid = 0x00000250c3636000 nid = 0x3e28 runnable
"G1 Refine # 0" os_prio = 2 tid = 0x00000250c367e000 nid = 0x3c0c runnable
"G1 Refine # 1" os_prio = 2 tid = 0x00000250e47fb800 nid = 0x3890 runnable
"G1 Refine # 2" os_prio = 2 tid = 0x00000250e47fc000 nid = 0x32a8 runnable
"G1 Refine # 3" os_prio = 2 tid = 0x00000250e47fd800 nid = 0x3d00 runnable
"G1 Young RemSet Sampling" os_prio = 2 tid = 0x00000250e4800800 nid = 0xef4 runnable
"VM Periodic Task Thread" os_prio = 2 tid = 0x00000250e54d6800 nid = 0x3468 waiting on condition
JNI global references: 2
Found one java-level deadlock:
=============================
"Thread-0":
waiting to lock monitor 0x00000250e4982480 (object 0x00000000894465b? a java.lang.Object),
which is held by "Thread-1"
"Thread-1":
waiting to lock monitor 0x00000250e4982380 (object 0x00000000894465a? a java.lang.Object),
which is held by "Thread-0"
Java stack information listed above:
================================================= = R3r3975. "Thread-0":
at DeadlockProgram $ DeadlockRunnable.run (DeadlockProgram.java:34)
- waiting to lock <0x00000000894465b0> (a java.lang.Object)
- locked 3r31616. (a java.lang.Object)
at java.lang.Thread.run ([email protected]???/Thread.java: 844)
"Thread-1":
at DeadlockProgram $ DeadlockRunnable.run (DeadlockProgram.java:34)
- waiting to lock <0x00000000894465a0> (a java.lang.Object)
- locked 3r33838. (a java.lang.Object)
at java.lang.Thread.run ([email protected]???/Thread.java: 844)
Found 1 deadlock. 3r33975. 3r3904. 3r33962.  3r33975.

Introductory Information

3r33962.  3r33975.
Although at first glance this file may seem too complicated and confusing, in reality it is very simple, if you take it apart in parts, step by step. 3r33962.  3r33975. The first line indicates the time when the dump was generated, the second - the diagnostic information about the JVM, at which the dump was received:
 3r33975. 3r33939.
2018-06-???: 44: 44 Full thread dump Java HotSpot (TM) 64-Bit Server VM (??? + 10 mixed mode): 3r33398. 3r33962.  3r33975. There is no stream information in this section. Here the general context of the system in which the dump was collected is set. 3r33962.  3r33975.

General information about streams

3r33962.  3r33975.
The next section provides information about the threads that were running in the system at the time of the dump:
 3r33975. 3r33939.
3r33975. Threads class SMR info:
_java_thread_list = 0x00000250e5488a0? length = 1? elements = {
0x00000250e497900? 0x00000250e498280? 0x00000250e52f280? 0x00000250e499280?
0x00000250e499580? 0x00000250e49a580? 0x00000250e49ae80? 0x00000250e532400?
0x00000250e54cd80? 0x00000250e54cf00? 0x00000250e54d180? 0x00000250e54d200?
0x00000250e54d0800
}
3r3904. 3r33962.  3r33975. The next section lists Safe Memory Reclamation (SMR) information It contains information about threads outside the JVM, i.e. these are not virtual machine threads or garbage collector threads. If you look at the addresses of these streams, you can see that they correspond to the value 3r-3965. tid [/i] - “natural, iron” (native) address in the operating system, not Thread ID. Triplets are used to hide unnecessary information:
 3r33975.
3r33975. "Reference Handler" # 2 tid = 0x00000250e4979000 3r3393975. "Finalizer" # 3 tid = 0x00000250e4982800 3r3393975. "Signal Dispatcher" # 4 tid = 0x00000250e52f2800
"Attach Listener" # 5 tid = 0x00000250e4992800 3r3393975. "C2 CompilerThread0" # 6 tid = 0x00000250e4995800
"C2 CompilerThread1" # 7 tid = 0x00000250e49a5800
"C1 CompilerThread2" # 8 tid = 0x00000250e49ae800
"Sweeper thread" # 9 tid = 0x00000250e5324000
"Service Thread" # 10 tid = 0x00000250e54cd800 3r3393975. Common Cleaner # 11 tid = 0x00000250e54cf000 3r3393975. "Thread-0" # 12 tid = 0x00000250e54d1800 3r3393975. "Thread-1" # 13 tid = 0x00000250e54d2000 3r3393975. "DestroyJavaVM" # 14 tid = 0x00000250e54d0800
3r3904. 3r33962.  3r33975.

Streams

3r33962.  3r33975.
Immediately after the SMR block follows a list of threads. The first thread on our list is the Reference Handler:
 3r33975. 3r33939.
3r33975. "Reference Handler" # 2 daemon prio = 10 os_prio = 2 tid = 0x00000250e4979000 nid = 0x3c28 waiting on condition[0x000000b82a9ff000]3r33975. java.lang.Thread.State: RUNNABLE
at java.lang.ref.Reference.waitForReferencePendingList ([email protected]???/Native Method)
at java.lang.ref.Reference.processPendingReferences ([email protected]???/Reference.java: 174)
at java.lang.ref.Reference.access $ 000 ([email protected]???/Reference.java: 44)
at java.lang.ref.Reference $ ReferenceHandler.run (java.base @ ??? /Reference.java: 138)
Locked ownable synchronizers:
- None
3r3904. 3r33962.  3r33975.

Brief stream description

3r33962.  3r33975.
The first line for each stream provides a general description. The description contains the following items:
 3r33975. 3r33939. 3r33476.  3r33975. 3r3653.  3r33975. 3r38080. Section
 3r33975.
Example 3r3r7487  3r33975.
Description
 3r33975. 3r3777.  3r33975. 3r3653.  3r33975. 3r3661. Name
 3r33975. 3r3661. "Reference Handler"
 3r33975. 3r3661. The human-readable name of the thread. The name can be set by calling setName object Thread . And get through the challenge getName 3r3675.  3r33975. 3r3777.  3r33975. 3r3653.  3r33975. 3r3661. ID
 3r33975. 3r3661. # 2
 3r33975. 3r3661. A unique ID assigned to each object of the class. Thread . An ID is generated for threads in the system. The initial value is 1. Each newly created thread is assigned its own ID, previously increased by 1. This property of the “read only” stream can be obtained using the 3r36565 function. getId [/i] object class 3r365965. Thread [/i] . 3r3675.  3r33975. 3r3777.  3r33975. 3r3653.  3r33975. 3r3661. Daemon status
 3r33975. 3r3661. daemon
 3r33975. 3r3661. The flag is a sign that the thread is a daemon. If it is a demon, then the flag will be set. For example, stream 3r33965. Thread-0 [/i] not a demon
 3r33975. 3r3777.  3r33975. 3r3653.  3r33975. 3r3661. Priority
 3r33975. 3r3661. prio = 10 r3r3962.  3r33975. 3r3675.  3r33975. 3r3661. The numeric priority of the java stream. Note that this priority does not necessarily correspond to the priority of the associated thread in the operating system. To set the priority, you can use the method setPriority object class 3r365965. Thread [/i] , and to obtain the method getPriority . 3r3675.  3r33975. 3r3777.  3r33975. 3r3653.  3r33975. 3r3661. OS Thread Priority
 3r33975. 3r3661. os_prio = 2
 3r33975. 3r3661. The priority of the thread in the operating system. This priority may differ from the one assigned to the coherent java stream. 3r3675.  3r33975. 3r3777.  3r33975. 3r3653.  3r33975. 3r3661. Address 3r33675.  3r33975. 3r3661. tid = 0x00000250e4979000
 3r33975. 3r3661. Java stream address This address is a pointer to 3r33587. Java Native Interface (JNI)
native object class Thread (object C ++ Thread which is associated with a Java stream via JNI). This value is obtained by casting a pointer to this (a C ++ object that is associated with this Java stream) to an integer. See 3r33593. line 879 in hotspot /share /runtime /thread.cpp
:
 3r33975.
3r33975. st-> print ("tid =" INTPTR_FORMAT "", p2i (this)); 3r33975. 3r3904. 3r33962.  3r33975. Although the key for this object ( Tid ) May be similar to the stream ID, in fact, this is the address of the connected object 3r3393965. JNI C ++ Thread [/i] , and this is not the value that the method returns. getId Java object 3r3393965. Thread [/i] . 3r3675.  3r33975. 3r3777.  3r33975. 3r3653.  3r33975. 3r3661. OS Thread ID
 3r33975. 3r3661. nid = 0x3c28
 3r33975. 3r3661. The unique identifier for the operating system thread to which the Java thread is bound. 3r33962.  3r33975. This value is output by the following code:
 3r33975. 3r3628. line 42 in hotspot /share /runtime /osThread.cpp
:
 3r33975.
3r33975. st-> print ("nid = 0x% x", thread_id ()); 3r33975. 3r3904. 3r3675.  3r33975. 3r3777.  3r33975. 3r3653.  3r33975. 3r3661. Status
 3r33975. 3r3661. waiting on condition
 3r33975. 3r3661. The human-readable status of the current thread. This line prints additional information to the simple status of the thread (see below), which can be used to understand what the thread was going to do (i.e., whether it tried to get the lock or waited for the unblocking condition). 3r3675.  3r33975. 3r3777.  3r33975. 3r3653.  3r33975. 3r3661. Last Known Java Stack Pointer
 3r33975. 3r3661.[0x000000b82a9ff000]3r3675.  3r33975. 3r3661. The last known pointer to the stack (SP) associated with this thread. This value is obtained using native C ++ code mixed with Java code using JNI. The value returned by function last_Java_sp () , 3r36464. line 2886 in hotspot /share /runtime /thread.cpp
:
 3r33975.
3r33975. st-> print_cr ("[" INTPTR_FORMAT "]",
(intptr_t) last_Java_sp () & ~ right_n_bits (12)); 3r33975. 3r3904. 3r33962.  3r33975. For simple thread dumps, this information is almost useless. However, in difficult cases, SP can be used to track locks. 3r3675.  3r33975. 3r3777.  3r33975.
3r33962.  3r33975.

Flow status

3r33962.  3r33975.
The second line is the current state of the stream. Possible flow conditions are given in enum: Thread.State : NEW RUNNABLE BLOCKED WAITING TIMED_WAITING TERMINATED For more information, see 3r36767 documentation. . 3r33939. 3r33962.  3r33975.

Thread Stack Trace

3r33962.  3r33975.
The next section contains the stack trace trace at the time of the dump. This stack trace is very similar to the trace that is generated by an uncaught exception. It contains the names of classes and strings that were executed at the time of the dump. In the case of the Reference Handler stream, we see nothing interesting. However, there is something in the Thread-02 stream trace. what is interesting, different from the standard trays:
 3r33975. 3r33939.
3r33975. "Thread-0" # 12 prio = 5 os_prio = 0 tid = 0x00000250e54d1800 nid = 0xdec waiting for monitor entry[0x000000b82b4ff000]3r33975. java.lang.Thread.State: BLOCKED (on object monitor)
at DeadlockProgram $ DeadlockRunnable.run (DeadlockProgram.java:34)
- waiting to lock <0x00000000894465b0> (a java.lang.Object)
- locked 3r31616. (a java.lang.Object)
at java.lang.Thread.run ([email protected]???/Thread.java: 844)
Locked ownable synchronizers:
- None
3r3904. 3r33962.  3r33975. In the trace, we see that information about the blocking has been added. This thread waits for a lock on the object with the address 0x00000000894465b0 (the object type is java.lang.Object). Moreover, the thread itself holds the lock with the address 0x00000000894465a0 (also a java.lang.Object object). This information is useful to us further for the diagnosis of deadlock. 3r33962.  3r33975.

Captured synchronization primitives (Ownable Synchronizer)

3r33962.  3r33975.
The last section lists the synchronization primitives captured by the stream. These are objects that can be used to synchronize threads, for example, latches (locks). According to the official Java documentation, 3r330. Ownable Synchronizer
- This is the heir to AbstractOwnableSynchronizer (or its subclass) that can be exclusively captured by a stream for synchronization purposes. 3r33965. ReentrantLock [/i] and 3r33965. write-lock [/i] but not read-lock class ReentrantReadWriteLock - Two good examples of such “ownable synchronizers” offered by the platform. 3r33962.  3r33975. For more information on this issue, please refer to this 3r3738. post . 3r33939. 3r33962.  3r33975.

JVM streams

3r33962.  3r33975.
The next section of the dump contains information about JVM technical threads that are not part of the application and are associated with operating system threads. Since these threads work outside the application, they do not have thread identifiers. Most often these are garbage collector streams and other JVM technical streams:
 3r33975. 3r33939.
3r33975. "VM Thread" os_prio = 2 tid = 0x00000250e496d800 nid = 0x1920 runnable
"GC Thread # 0" os_prio = 2 tid = 0x00000250c35b5800 nid = 0x310c runnable
"GC Thread # 1" os_prio = 2 tid = 0x00000250c35b8000 nid = 0x12b4 runnable
"GC Thread # 2" os_prio = 2 tid = 0x00000250c35ba800 nid = 0x43f8 runnable
"GC Thread # 3" os_prio = 2 tid = 0x00000250c35c0800 nid = 0x20c0 runnable
"G1 Main Marker" os_prio = 2 tid = 0x00000250c3633000 nid = 0x4068 runnable
"G1 Conc # 0" os_prio = 2 tid = 0x00000250c3636000 nid = 0x3e28 runnable
"G1 Refine # 0" os_prio = 2 tid = 0x00000250c367e000 nid = 0x3c0c runnable
"G1 Refine # 1" os_prio = 2 tid = 0x00000250e47fb800 nid = 0x3890 runnable
"G1 Refine # 2" os_prio = 2 tid = 0x00000250e47fc000 nid = 0x32a8 runnable
"G1 Refine # 3" os_prio = 2 tid = 0x00000250e47fd800 nid = 0x3d00 runnable
"G1 Young RemSet Sampling" os_prio = 2 tid = 0x00000250e4800800 nid = 0xef4 runnable
"VM Periodic Task Thread" os_prio = 2 tid = 0x00000250e54d6800 nid = 0x3468 waiting on condition
3r3904. 3r33962.  3r33975.

Global JNI links

3r33962.  3r33975.
This section indicates the number of global links used by the JVM through the JNI. These links are not maintained by the garbage collector and in certain circumstances can cause memory leaks. 3r33962.  3r33975. 3r33939.
3r33975. JNI global references: 2
3r3904. 3r33962.  3r33975. In most simple cases, this information is not used. However, the importance of global links has to be understood. For more information, see in this post. post 3r33967. . 3r33962.  3r33975.

Mutually blocked (Deadlocked) streams 3r3393949. 3r33962.  3r33975.
The last section contains information about the deadlocks found. If these do not show up, then the section will be empty. Since we specifically developed the application with interlocks, in our case this section is there. A lock was detected during dump generation and is represented by the following message:
 3r33975. 3r33939.
3r33975. Found one java-level deadlock:
=============================
"Thread-0":
waiting to lock monitor 0x00000250e4982480 (object 0x00000000894465b? a java.lang.Object),
which is held by "Thread-1"
"Thread-1":
waiting to lock monitor 0x00000250e4982380 (object 0x00000000894465a? a java.lang.Object),
which is held by "Thread-0"
Java stack information listed above:
================================================= = R3r3975. "Thread-0":
at DeadlockProgram $ DeadlockRunnable.run (DeadlockProgram.java:34)
- waiting to lock <0x00000000894465b0> (a java.lang.Object)
- locked 3r31616. (a java.lang.Object)
at java.lang.Thread.run ([email protected]???/Thread.java: 844)
"Thread-1":
at DeadlockProgram $ DeadlockRunnable.run (DeadlockProgram.java:34)
- waiting to lock <0x00000000894465a0> (a java.lang.Object)
- locked 3r33838. (a java.lang.Object)
at java.lang.Thread.run ([email protected]???/Thread.java: 844)
Found 1 deadlock. 3r33975. 3r3904. 3r33962.  3r33975.
The first subsection describes the deadlock scenario: Thread-0 expects the ability to capture the monitor (this is a call to the block. Synchronized (secondResource) In our application), at the same time this thread holds the monitor that tries to capture the Thread -1 (this is the address to the same code fragment: Synchronized (secondResource) In our application). This cyclic lock is otherwise called 3r3-3830. deadlock
. The figure below shows the situation graphically: 3r33962.  3r33975. at DeadlockProgram $ DeadlockRunnable.run (DeadlockProgram.java:34) [/i] , then we will see the problem area of ​​the code:
 3r33975. 3r33939.
3r33975. printLockedResource (secondResource); 3r33975. 3r3904. 3r33962.  3r33975. This line is the first line of the synchronized block, which is the cause of the lock, and tells us that synchronization on the secondResource is the cause of the deadlock. 3r33962.  3r33975.
To remedy the situation, we must ensure the same synchronization order on resourceA and resourceB in both flows. If we do this, then we come to the following application:
 3r33975. 3r33939.
3r33855. public class DeadlockProgram {
public static void main (String[]args) throws Exception {3r3393975. Object resourceA = new Object (); 3r33975. Object resourceB = new Object (); 3r33975. Thread threadLockingResourceAFirst = new Thread (new DeadlockRunnable (resourceA, resourceB)); 3r33975. Thread threadLockingResourceBFirst = new Thread (new DeadlockRunnable (resourceA, resourceB)); 3r33975. threadLockingResourceAFirst.start (); 3r33975. Thread.sleep (500); 3r33975. threadLockingResourceBFirst.start (); 3r33975.}
private static class DeadlockRunnable implements Runnable {
private final Object firstResource; 3r33975. private final Object secondResource; 3r33975. public DeadlockRunnable (Object firstResource, Object secondResource) {
this.firstResource = firstResource; 3r33975. this.secondResource = secondResource; 3r33975.}
@Override
public void run () {
try {3r3759. synchronized (firstResource) {
printLockedResource (firstResource); 3r33975. Thread.sleep (1000); 3r33975. synchronized (secondResource) {
printLockedResource (secondResource); 3r33975.}
}
} catch (InterruptedException e) {
System.out.println ("Exception occurred:" + e); 3r33975.}
}
private static void printLockedResource (Object resource) {
System.out.println (Thread.currentThread (). GetName () + ": locked resource ->" + resource); 3r33975.}
}
}
3r33892. 3r3904. 3r33962.  3r33975. This application will end without interlocking, and as a result we will get the following output (note that the addresses of instances of the Object class have changed): 3r33962.  3r33975.
3r33975. Thread-0: locked resource -> [email protected]
Thread-0: locked resource -> [email protected]
Thread-1: locked resource -> [email protected]
Thread-1: locked resource -> [email protected]
3r3904. 3r33962.  3r33975. As a result, using only the information obtained from the thread dump, we were able to find the cause and fix the deadlock in our application. The proposed technique is sufficient for most simple applications (or applications with a small number of deadlocks). To deal with more complex situations, other methods will be required. 3r33962.  3r33975.
Analysis of more complex Thread Dumps

3r33962.  3r33975.
Dumps of real applications can be very large and complex. In one JVM, hundreds of thousands of threads can run simultaneously. And more than two streams may be blocked (or there may be several multithreading problems caused by one problem). Analyzing such a vast amount of information can be a real problem. 3r33939. 3r33962.  3r33975.
For analyzing large dumps, special analyzer utilities are used - Thread Dump Analyzers (TDAs). These utilities parse Java thread dumps and display information in a human-readable form, often using graphical tools. Moreover, some of them can perform static analysis and find the cause of the problem. Of course, the choice of a particular utility depends on a number of circumstances. Nevertheless, we will list the most popular TDA:
 3r33975. 3r33939. 3r33921.  3r33975. 3r33938. 3r33924. fastThread 3r33941.  3r33975. 3r33938. 3r33939. Spotify TDA
3r33941.  3r33975. 3r33938. IBM Thread and Monitor Dump Analyze for Java 3r33941.  3r33975. 3r33938. 3r3393939. irockel tda
3r33941.  3r33975. 3r33943. 3r33962.  3r33975. This is not a complete list of utilities of this kind. Each utility from this list performs a sufficiently qualitative analysis and simplifies the manual labor of analyzing dumps. 3r33962.  3r33975.
Conclusion 3r33949. 3r33962.  3r33975.
Thread dumps are an excellent tool for analyzing the state of a Java application, especially in cases of unexpected behavior of multi-threaded applications. However, without the proper baggage of knowledge, the dump can add additional complexity to an already difficult situation. 3r33962.  3r33975. In this article, we developed a deadlock application, formed a dump of the hung application. We analyzed the dump and found the cause of the blocking and fixed it. It is not always so easy, for the analysis of most real-world applications it is very useful to use special utilities - analyzers. 3r33939. 3r33962.  3r33975.
However, every professional Java developer needs to understand the basics of thread dump analysis. Must be guided in their structure, know what information can be extracted and how to use it to solve problems of multithreading. 3r33962.  3r33975. Although thread dump is not a “silver bullet” in the multithreaded world, it is nevertheless an important tool for diagnosing the complex, but quite common problems of multithreaded Java applications. 3r33939. 3r33962.  3r33975.
3r33965. In the program of the course 3r3-3966. Java
developer. Multithreading questions occupy the replace part. We consider in detail how to develop programs so that we don’t have to deal with deadlock production at night. [/i] 3r33939.
3r33975. 3r33975. 3r33973. ! function (e) {function t (t, n) {if (! (n in e)) {for (var r, a = e.document, i = a.scripts, o = i.length; o-- ;) if (-1! == i[o].src.indexOf (t)) {r = i[o]; break} if (! r) {r = a.createElement ("script"), r.type = "text /jаvascript", r.async =! ? r.defer =! ? r.src = t, r.charset = "UTF-8"; var d = function () {var e = a.getElementsByTagName ("script")[0]; e.parentNode.insertBefore (r, e)}; "[object Opera]" == e.opera? a.addEventListener? a.addEventListener ("DOMContentLoaded", d,! 1): e.attachEvent ("onload", d ): d ()}}} t ("//mediator.mail.ru/script/2820404/"""_mediator") () ();
3r33975.