Java Performance Analysis thread stack details (bottom)

Java Performance Analysis thread stack details (bottom)

Reprinted from: Public number "test that thing."

Combining Jstack results with a detailed explanation of thread status

The previous article details the role, status, and any viewing comprehension of line stacks, this article combined with the Jstack tool to view the thread status and list the key focus targets. Jstack is a common troubleshooting tool that can output the state of all threads in a Java process at a certain time, and many of these state information can lead to useful clues to our troubleshooting efforts. In the Jstack output, the Java thread state is mainly the following:

1. BLOCKED thread waiting for monitor lock (synchronized keyword)

2. Timed_waiting thread waiting to wake up, but set a time limit

3. Waiting thread waits for an infinite wake-up

4. RUNNABLE thread running or I/O waiting

These states are explained by detailed examples below.

BLOCKED

As shown, after you use the Jstack tool for the dump thread, the thread you see is in the blocked state. After the dump thread, the first thing to look at is the state of the thread. This thread is in the blocked state and we need to focus on the analysis.

First, let's analyze the thread information that the Jstack tool fetches:

The thread information fetched by the Jstack tool is analyzed from the bottom up, and by visible, the thread begins to run and then runs some methods of the business until the Org.apache.log4j.Category.forcedLog is called, and waiting to lock is started.

The status of the thread is: BLOCKED (on object monitor)

Indicates that the thread is in a blocked state and is waiting for a monitor lock. The reason for blocking is that because this thread has a lock shared with other threads, another thread is already using the lock to enter a synchronized synchronization method block or method. This lock is also required when this thread wants to enter this synchronization code block, but the lock is already in use, causing the thread to be in a blocked state.

The first line contains information such as the thread name and ID, such as "druid-consumer-pool-3" in, nid (each thread is wired PID, the PID is converted to a 16-binary value, that is, the jstack results in Nid, you can only confirm a thread through NID. ）

In the first line, the thread is currently waiting for monitor entry, or it indicates that the threads are waiting to enter monitor.

Monitor is the primary means of using Java to achieve mutual exclusion and collaboration between threads, which can be seen as an object or class lock. Every object has, and only one monitor. Each monitor can be owned by only one thread at a time, and the thread is "Active thread", while the other threads are "waiting thread", waiting in the two queue "Entry set" and "Wait set" respectively. The state of the thread waiting in "Entry set" is "Waiting for monitor Entry", while the thread state waiting in "wait set" is "in Object.wait ()". The current thread status is: Waiting for monitor entry, which indicates that it is a thread inside the "entry Set". We call the code snippet protected by synchronized as a critical section. When a thread requests to enter a critical section, it enters the "Entry Set" queue.

There are two possibilities:

1, the monitor is not owned by other threads, there is no other waiting thread in Entry set. This thread becomes the Owner of the corresponding class or object's monitor, and the code that executes the critical section

2, the monitor is owned by other threads, this thread waits in the Entry set queue.

In the first case, the thread will be in the "Runnable" state

In the second case, the thread dump will appear in "Waiting for monitor entry"

Based on the above analysis, we can see that the thread wants to call log4j, the purpose is to print the log, but because the call log4j write log has a locking mechanism, so the thread is blocked. Re-troubleshoot the log4j version of the project and learn that there is a performance bug in this release, optimized to upgrade the log4j version or adjust the log level, optimize the content of the log printing, or add a cache.

Waiting to lock < address >

Indicates that the thread used the synchronized Request object Lock was unsuccessful and began to wait for another thread to release the lock. The thread waits in the monitor's entry area. This usually appears at the top of the call stack, and the thread state generally corresponds to blocked.

Timed_waiting

As shown, after you use the Jstack tool for the dump thread, the thread you see is in the timed_waiting state.

The status of the thread is: timed_waiting

At this point the thread is in a sleep state, which indicates that the thread waits for a specific operation of another thread in a time-limited time, typically waking up with a timeout. In general, the appearance of timed_waiting is normal, waiting for network IO and so on will appear this state, but a large number of threads in timed_waiting, we need to focus on analysis.

In the first line, the display thread is waiting on condition, which indicates that the thread is waiting for a condition to occur, wakes itself up, or calls Sleep (n).

When the thread is waiting on condition, the thread state may be:

1, Java.lang.Thread.State:WAITING (parking): Has been waiting for a certain condition to occur;

2, Java.lang.Thread.State:TIMED_WAITING (parking or sleeping): Timed to wait for a condition to occur, even if this condition does not come, will also wake themselves regularly.

In our example, the thread is in the timed_waiting state.

Parking to wait for < address > destination

Here is the first line "waiting on condition" waiting for the condition, waiting is Java.util.concurrent.countdownlatch$sync, which is a kind of latching implementation, is a kind of synchronization tool class, You can delay the progress of a thread until the lockout reaches the terminating state, which contains a counter that is initialized to an integer that indicates the number of events to wait for. As can be known from the above analysis, the thread is to write data to Druid, because there is a synchronization mechanism, and enter the Timed_waiting state.

And the last example thread is different in parking-wait for this example, the thread is also in the timed_waiting state, but the first line shows that the thread is in object.wait (), the fourth line shows the thread waiting on < address > Goal.

The thread is in object.wait (), stating that the thread has called the Java.lang.Object.wait () method after it has obtained the monitor.

The thread in the previous thread (a) said that the threads waiting for monitor are divided into two

The status of the thread waiting in "Entry Set" is "Waiting for monitor Entry"

The thread status waiting in "Wait Set" is "in Object.wait ()"

This example is a thread waiting in "Wait Set" whose state is in object.wait (), which means that the thread obtains Monitor, but the condition that the thread continues to run is not satisfied, then the wait () method of the calling object (typically the object being synchronized) is called. Dropped the Monitor and entered the Wait Set queue.

At this point the thread state is roughly the following:

1, Java.lang.Thread.State:TIMED_WAITING (on object monitor);

2, Java.lang.Thread.State:WAITING (on object monitor);

In this case, the thread is in the timed_waiting state.

Waiting

As shown, after you use the Jstack tool for the dump thread, the thread you see is in the waiting state.

(1) The status of the thread is: waiting

This means that the thread is waiting for another thread to release its waiting state. A typical example is the producer consumer model, when the producer is too slow, the consumer waits for the producer to be able to consume, this time the consumer thread is in the waiting state. You can also use the lock.wait () method to bring a thread into the waiting state, wait for no timeout, wait for lock.notify () or Lock.notifyall (), or receive a interrupt signal to exit the wait state.

(2) Parking to wait for < address > destination

In the first line, the display thread is waiting on condition, which indicates that the thread is waiting for a condition to occur and wakes itself up.

When the thread is waiting on condition, the thread state may be

Java.lang.Thread.State:WAITING (parking): Has been waiting for a certain condition to occur;

Java.lang.Thread.State:TIMED_WAITING (parking or sleeping): Timed to wait for a condition to occur, even if the condition does not come, it will wake itself regularly.

In this example, the thread is in the waiting state, and parking to wait for the Java.util.concurrent.locks.AbstractQueuedSynchronizer, which is the Java implementation Synchronization mechanism.

RUNNABLE

As shown, after you use the Jstack tool for the dump thread, the thread you see is in the runnable state.

In this example, you can see clearly the process of running the entire thread. In the course of the thread running, there are many times to acquire the lock, that is, the locked < address > target, that is, this thread uses synchronized to request the object lock succeeds, is the monitor owner, can operate in the critical section. The lock content has the input and output stream of Java Io, and so on.

"02 '

During a single test, there was an unexpected gain from thread printing

As the following information, "http-bio-18272-exec-258", indicates that Tomcat's startup mode is Bio mode, the bio mode is changed to NiO mode, in which other conditions are unchanged, only the bio mode is changed to NIO mode, the TPS is boosted by one

There are 3 modes of operation for Tomcat. Modify their run mode. 3 modes of operation is successful, you can see his startup console, or start the log. or log in to their default page http://localhost:8080/to see the server status.

1) Bio: The default mode, the performance is very low, without any optimization processing and support.

2) NiO: Using Java's asynchronous IO Care technology, no blocking IO technology.

Want to run in this mode, directly modify the connector node in the Server.xml, modify the protocol to

<connector port= "protocol=" Org.apache.coyote.http11.Http11NioProtocol "connectiontimeout=" 20000 " uriencoding= "UTF-8" usebodyencodingforuri= "true" enablelookups= "false" redirectport= "8443"/>

Once started, it can take effect.

3) Apr

Installation is the most difficult, but from the operating system level to solve the asynchronous IO problem, greatly improve performance.

Apr and native must be installed and the APR will be supported directly on the launch.

to get more test skills, welcome to join the BestTest5000 People Exchange Group : 435092293

Java Performance Analysis thread stack details (bottom)