“This is the third day of my participation in the First Challenge 2022. For details: First Challenge 2022”

Jstack can be used to view stack usage, as well as process deadlocks. How to troubleshoot process deadlocks

Or through the case analysis

package com.lxl.jvm; public class DeadLockTest { private static Object lock1 = new Object(); private static Object lock2 = new Object(); public static void main(String[] args) { new Thread(() -> { synchronized (lock1) { try { System.out.println("thread1 begin"); Thread.sleep(5000); } catch (InterruptedException e) { } synchronized (lock2) { System.out.println("thread1 end"); } } }).start(); new Thread(() -> { synchronized (lock2) { try { System.out.println("thread2 begin"); Thread.sleep(5000); } catch (InterruptedException e) { } synchronized (lock1) { System.out.println("thread2 end"); } } }).start(); }}Copy the code

There are two locks on top, calling each other.

  1. Define two member variables lock1, lock2

  2. Two threads are defined in the main method.

    • Thread 1 uses synchronous execution internally — lock, lock is lock1. After sleeping for five seconds, he acquires the second lock and executes the second code.
    • Thread 2 is similar to thread 1, with the lock reversed.

  3. Problem: At first, execute as a thread in parallel, thread 1 gets lock1, thread 2 gets lock2. Then thread 1 continues to execute, and when it sleeps for 5 seconds, the second synchronization is started. The lock is lock2, but at this time, it is likely that thread 2 has not finished executing, so it has not released lock2, so it waits. Thread 2 has just acquired the lock2 lock, and will try to acquire the lock1 lock after sleeping for 5 seconds. The two threads are waiting for each other, causing a deadlock.

Step 1: Use the Jstack command to see if the current deadlock can be detected.

jstack 51789
Copy the code

And as you can see from one of these anomalies,

  • Prio: priority of the current thread
  • CPU: indicates the CPU time
  • Os_prio: Specifies the priority of the OPERATING system
  • Tid: indicates the id of a thread
  • Nid: indicates the id of the system kernel
  • State: the current state is BLOCKED. The normal state is Running, and we see that thread0 and Thread1 are BLOCKED.

Based on the above information, we determined that both threads were BLOCKED and might have a problem, and moved on.

No java-level deadlock was Found. It means to find a deadlock. The Thread number of the deadlock is thread-0, thread-1.

Thread-0: Waiting for the lock on the 0x000000070E706EF8 object, which is now held by Thread-1.

Thread-1: waiting for the lock on the 0x000000070E705C98 object, which is now being held by Thread0.

The stack information for deadlocks is shown at the bottom. Deadlocks can occur on lines 17 and 31 of a DeadLockTest. With this hint, we can find out where the deadlock is.

Step 2: Use JVisualVM to view deadlocks

If using JStack feels inconvenient, you can also use JVisualVM, through the interface to view, more intuitive.

During the program code launch, open the JVisualVM tool.

Find the currently running class, look at the thread, and you’ll see the top line of red letters: Deadlock detected. Then click on the “Thread Dump” button to view information about believed thread deadlocks.

Here you can find the details of the thread private lock. The details are the same as the above results using the Jstack command. The utility tool is more convenient.