Analysis and positioning of Java multithreading-thread Stack

A Java thread stack is a snapshot of all threads of a running Java application. It displays information such as the current stack trace, status, and thread name. The thread list contains the threads created by the JVM itself (responsible for garbage collection, signal processing, and other management work) and the threads created by the application.

By sending a sigquit signal to the JVM, you can get a thread heap. In a UNIX operating system (Solaris, Linux, HP-Unix, etc.), run the kill-3 <pid> command to obtain the thread heap, (It is a good habit to redirect the output to a file in the startup script, start. sh> trace. log 2> & 1 ). In Windows, you can type ctrl-break in the Command window to get the thread heap. The thread heap outputs stdout or stderr to the JVM. After the thread heap is output, the application continues to run normally. When you send sigquit signals to the JVM, the JVM signal processor will respond to this signal through the output thread heap. When the program runs, you can get the thread heap at any point.

An example of thread heap

The following shows an example of a thread heap in a single-threaded application using Sun JVM 1.4.1. The main thread is the main application thread. All other threads are created by JVM and are responsible for some management work. When analyzing application-level problems, we usually only care about application threads. Next, we will analyze the stack trace of the main thread in Listing 1.

"Main" PRIO = 5 tid = 0x002358b8 nid = 0x7f8 runnable [6f000 .. 6fc40]
At test. Method1 (test. Java: 10)
At test. Main (test. Java: 5)

From this code snippet, you can see that a thread stack trace has a name, thread priority (PRIO = 5), status (runnable), source code line number, and method call. The following conclusions can be drawn from this stack trace: the main thread executes some code in the Method1 method of the test class. The call to the Method1 method is completed by the main method of the same class. You can also see the exact source code line numbers in those methods.

Before analyzing the thread heap from some more complex situations, let's first discuss the different states of the threads that can be seen in the thread heap and their meanings.

·Runnable:You can run the CPU or prepare the running status when you obtain the CPU usage right.

"Thread-5" daemon PRIO = 6 tid = 0x00aa4b88 nid = 0x3f0 runnable [0x02def000... 0x02def9e8]
At java. Io. winntfilesystem. getbooleanattributes (native method)
At java. Io. file. exists (unknown source)
At com. xmliu. threadheap. threadpool $ taskqueue. gettask (threadpool. Java: 66)
-Locked <0x230c39c8> (a com. xmliu. threadheap. threadpool $ taskqueue)
At com. xmliu. threadheap. threadpool $ worker. Run (threadpool. Java: 41)

Thread-5 "is executing the threadpool $ worker. Run () method and obtaining the lock <0x230c39c8>.

·Waiting for monitor entry:Wait for the lock to be obtained.

"Thread-4" daemon PRIO = 6 tid = 0x00aae3d0 nid = 0x9c0 waiting for monitor entry [0x02daf000 .. 0x02dafa68]
At com. xmliu. threadheap. threadpool $ taskqueue. gettask (threadpool. Java: 59)
-Waiting to lock <0x230c39c8> (a com. xmliu. threadheap. threadpool $ taskqueue)
At com. xmliu. threadheap. threadpool $ worker. Run (threadpool. Java: 41)

"Thread-4" requires the lock <0x230c39c8> (waiting to lock <0x230c39c8>) when running threadpool $ worker. Run () and is waiting for other threads to release.

·Waiting on condition:This situation occurs when any sleep () method is called on the thread object.

"Thread-2" daemon PRIO = 6 tid = 0x00a952b8 nid = 0xea4 waiting on condition [0x02d2f000 .. 0x02d2fd68]
At java. Lang. thread. Sleep (native method)
At com. xmliu. threadheap. threadpool $ taskqueue. gettask (threadpool. Java: 61)
-Locked <0x22c01288> (a com. xmliu. threadheap. threadpool $ taskqueue)
At com. xmliu. threadheap. threadpool $ worker. Run (threadpool. Java: 40)

"Thread-2" calls the sleep () method.

·Object. Wait ():This occurs when any wait () method is called on the thread object,Release the acquired lock and wait for the awakening of other threads or wait for the timeout to re-compete for the lock.

"Thread-1" daemon PRIO = 6 tid = 0x00a94cc8 nid = 0xf0c in object. Wait () [0x02cef000 .. 0x02cef9e8]
At java. Lang. Object. Wait (native method)
-Waiting on <0x22c01288> (a com. xmliu. threadheap. threadpool $ taskqueue)
At com. xmliu. threadheap. threadpool $ taskqueue. gettask (threadpool. Java: 61)
-Locked <0x22c01288> (a com. xmliu. threadheap. threadpool $ taskqueue)
At com. xmliu. threadheap. threadpool $ worker. Run (threadpool. Java: 40)

"Thread-1" after obtaining the lock <0x22c01288>, the wait () method is called to release the lock and wait for other threads to wake up.

From the thread stack, we can locate deadlocks, thread hangs, and JVM crashes. It can also help us locate performance bottlenecks, what our threads are doing, and which resources are competing for use. For example, our task distribution thread has done a lot of things, and most of the worker threads are waiting for the task of the distribution thread, so we know that we need to optimize the code of the following distribution thread, the processing work is handed over to the worker thread, and only the distribution work consumes a small amount of resources.