Java多线程环境下如何复现synchronized方法导致的线程挂起？

Hey there! Let's break down your questions step by step—since you're dealing with thread hangs in a Java multi-threaded environment, I've got practical, actionable ways to simulate and reproduce these issues for testing.

There are several straightforward ways to mimic thread suspension, depending on the scenario you're trying to replicate:

• Use Thread.sleep(long millis): This pauses a thread for a specified time without releasing any held locks. It's great for simulating temporary pauses in execution (though it's not true "suspension" in the sense of waiting for a condition).
• Leverage Object.wait(): Put a thread into a waiting state by calling wait() inside a synchronized block/method. The thread will stay suspended until another thread calls notify() or notifyAll() on the same object. This perfectly simulates threads hanging while waiting for a signal or resource.
• Block with synchronization primitives: Use CountDownLatch or CyclicBarrier to force threads to wait at a specific checkpoint. For example, initialize a latch with a count of 1, and have threads call await()—they'll hang until you call countDown() from another thread.
• Hold a lock indefinitely: Have one thread enter a synchronized block/method and never exit it (e.g., via an infinite loop). All other threads trying to access that synchronized code will hang in a BLOCKED state, waiting for the lock.

The gap between production and development environments usually comes down to load, data volume, and execution timing. Here's how to bridge that gap and reproduce the hang:

Adjust Load & Thread Count #

• Crank up thread volume: Production environments often have far more concurrent threads than dev setups. Try spawning hundreds (or even thousands) of threads to call the synchronized method—this amplifies lock competition, making hangs more likely.
• Simulate sustained load: Use an ExecutorService to submit thousands of tasks (matching your millions of production records) instead of just a handful. This mimics the continuous pressure production systems face.

Mimic Production Execution Timing #

• Add artificial delays: Insert random short sleeps (Thread.sleep((long)(Math.random() * 500))) inside the synchronized method to simulate real-world latency (like DB calls, IO operations, or complex processing). Longer lock-holding times increase the chance of threads piling up waiting for the lock.
• Simulate resource bottlenecks: Inside the method, add logic that mimics slow external dependencies (e.g., a mock DB that takes 200ms per call). This extends how long each thread holds the synchronized lock, worsening competition.

Control Thread Scheduling #

• Adjust thread priorities: Set the thread holding the lock to a higher priority, so the OS lets it run longer before yielding. This makes other threads wait longer, increasing the chance of hangs.
• Force thread context switches: Use Thread.yield() in non-critical sections to encourage the OS to switch between threads, amplifying lock contention.

Example Unit Test to Reproduce the Hang #

Here’s a JUnit test that combines these techniques to replicate the issue:

import org.junit.Test;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;

public class SynchronizedHangReproductionTest {
    // Mock your production class with the synchronized method
    static class RecordProcessor {
        public synchronized void processRecord(long recordId) throws InterruptedException {
            // Simulate variable latency like production
            Thread.sleep((long) (Math.random() * 300));
            // Replace with your actual business logic
            System.out.printf("Processed record %d via thread %s%n", 
                              recordId, Thread.currentThread().getName());
        }
    }

    @Test
    public void testThreadHangOnSynchronizedMethod() throws InterruptedException {
        RecordProcessor processor = new RecordProcessor();
        int concurrentThreads = 400; // Match production thread pool size
        ExecutorService executor = Executors.newFixedThreadPool(concurrentThreads);

        // Submit 10,000 tasks to mimic millions of production records
        for (long i = 0; i < 10000; i++) {
            final long id = i;
            executor.submit(() -> {
                try {
                    processor.processRecord(id);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            });
        }

        executor.shutdown();
        // Wait for tasks to finish—if hangs occur, this will timeout
        boolean allCompleted = executor.awaitTermination(5, TimeUnit.MINUTES);
        
        if (!allCompleted) {
            System.out.println("Detected hanging threads!");
            // Print blocked threads' stack traces for debugging
            for (Thread thread : Thread.getAllStackTraces().keySet()) {
                if (thread.getState() == Thread.State.BLOCKED) {
                    System.out.printf("Blocked Thread: %s%n", thread.getName());
                    for (StackTraceElement elem : thread.getStackTrace()) {
                        System.out.printf("\t%s%n", elem);
                    }
                }
            }
        }
    }
}

Validate the Hang #

Once the test runs, use tools like jstack to check thread states. Look for threads in the BLOCKED state, waiting to acquire the RecordProcessor's monitor lock—this confirms you've reproduced the production issue.

内容的提问来源于stack exchange，提问作者Vijay Kumar Chauhan