thread dump

When the application runs slowly or fails, it is possible to analyze them by analyzing java's Thread Dumps to get blocked and bottlenecked threads.

The thread stack is a snapshot of the state of threads (including locks) in a momentary state in the virtual machine, that is, the running state of all threads in the system at a certain moment, including the call stack of each thread and the holding of locks. The main information included includes

  1. Thread name, id, number of threads, etc.

   2. The running state of the thread, the state of the lock (which thread is the lock held by, which thread is waiting for the lock, etc.)

   3. The call stack contains the full class name, the method executed, the number of lines of source code, etc.

   Thread stack is an instantaneous snapshot containing thread state and call relationship, which can help analyze many performance problems with the help of stack information. The thread stack is an instantaneous record, so there is no backtracking of historical messages. It is often necessary to print several times for comparative analysis, and in general, it is necessary to combine the application log to determine the problem.

1. The system cpu is too high
2. Performance bottleneck: if the response time is long but the CPU resources are not high
3. The system is running slower and slower, the response time is long
4. The system hangs, no response for a long time or the response time is
long Deadlock, infinite loop, etc.
6. Memory overflow caused by too many threads (such as inability to create threads, etc.)

Java thread principle

    thread synchronization

     Multiple threads can execute at the same time. In order to ensure the versatility of multiple threads in using shared resources, thread synchronization is used to ensure that only one thread can access shared resources at the same time.

     Thread synchronization is available in Java using monitors. Every Java object has a monitor, which can only be owned by one thread. When a thread wants to acquire a monitor owned by another thread, it needs to enter a waiting queue until the thread releases the monitor.

    the state of the thread

    In order to analyze the Thread Dump, it is necessary to first understand the state of the thread. The state of a thread is in java.lang.Thread.State.

 

 

 

1. New state (New) A new thread object is created.

2. Ready state (Runnable) After the thread object is created, other threads call the start() method of the object. Threads in this state are in the runnable thread pool and become runnable, waiting to acquire the right to use the CPU.

3. Running state (Running) The thread in the ready state acquires the CPU and executes the program code.

4. Blocked state (Blocked) Blocked state is that the thread gives up the right to use the CPU for some reason and temporarily stops running. Until the thread enters the ready state, there is no chance to go to the running state. There are three types of blocking:

  • Waiting for blocking: The running thread executes the wait() method, and the JVM puts the thread into the waiting pool.
  • Synchronization blocking: When the running thread acquires the synchronization lock of the object, if the synchronization lock is occupied by another thread, the JVM will put the thread into the lock pool.
  • Other blocking: When a running thread executes the sleep() or join() method, or issues an I/O request, the JVM will place the thread in a blocking state. When the sleep() state times out, join() waits for the thread to terminate or times out, or when the I/O processing is complete, the thread re-enters the ready state.

5. Dead state (Dead): The thread finishes execution or exits the run() method due to an exception, and the thread ends its life cycle.

The thread state described by the keywords used by Jstack is not the same as the thread above, so there may be confusion in understanding. Although threads in Java also have the five states described above, in practice, the new state and the death state of the thread last for a very short time, and we don't care too much. Most of the time we focus on the running state/blocking state,

 

 

 

For detailed process, please refer to:

  • When new Thread(Runnabler) is executed, the newly created thread is in the new state, and it is impossible for this thread to execute
  • When thread.start() is executed, the thread is in the runnable state. In this case, as long as the CPU is obtained, the execution can be started. A thread in the runnable state will accept the scheduling of the JVM and enter the running state, but when it will enter this state is random and unknown
  • Threads in the running state are the most complex and may enter the runnable, waiting, timed_waiting, blocked, and dead states:
    • If the CPU is scheduled to another thread, or the Thread.yield() method is executed, it will enter the runnable state, but it may also enter the running state immediately
    • If you execute Thread.sleep(long), or thread.join(long), or call the object.wait(long) method on the lock object, you will enter the timed_waiting state
    • If thread.join() is executed, or the object.wait() method is called on the lock object, it will enter the waiting state
    • If you enter a synchronized method or synchronized code block and the lock object is not acquired, it will enter the blocked state
    • A thread in the waiting state, if it is waiting because the thread.join() method enters the waiting state, will return to the runnable state after the target thread is executed; if it is because the object.wait() method enters the waiting state, it will be executed on the lock object. object.notify() or object.notifyAll() will return to runnable state
    • The thread in the timed_waiting state is similar to the waiting state, except that when the set time is up, it will return to the runnable state
    • A thread in the blocked state will only get out of the blocked state after acquiring the lock
    • When the thread finishes executing, or throws an uncaught exception, it will enter the dead state and the thread ends.

 

 

We need to focus on the four states of RUNNABLE, BLOCKED, WAITING and TIME_WAITING, which will also appear in the thread stack printed by jstack from time to time.

1) BLOCKED: The thread is waiting to acquire the lock to enter the synchronized block or synchronized method. Two deadlocked threads are Blocked.

2) WAITING: It is more advanced than the BLOCKED state, which means that the lock has been obtained, but because some conditions are not satisfied, you have to wait for a while and call the object.wait() method. When the conditions are met, other threads call notify and then call me. In addition, you can also call the Thread.join() method. As the name suggests, it is to call the join method of other threads, and let others join in and execute first, then I can only wait. But because wait() and notify() and notifyAll() are used to coordinate access to shared resources, they must be used in synchronized blocks. So even if the thread in the wait state is woken up by notfiy, it needs to acquire the lock again, so it enters the Blocked state after waking up.

3) TIMED_WAITING: Analogy to WAITING, the difference is that the notify() or notifyAll() method is not required to wake up, and it is time to wake up. In addition, sleep is easier to understand, that is, let the current thread sleep for a while, and the difference from wait is that it does not release the lock .

4) RUNNABLE Needless to say, it is already running in the JAVA virtual machine, but waiting for operating system resources, such as CPU time slices.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325375328&siteId=291194637