Why Are Your Java Threads Stuck? Decoding WAITING and TIMED_WAITING States

1. Thread Run States

1.1 total

1.2 timed_waiting

From the above image we can see that the top N threads in TIMED_WAITING are querying national subsidy qualifications.

1.3 waiting

From the image we can see that the top N threads in WAITING are querying national subsidy activities.

1.4 Thread Analysis

Below we analyze the two states:

1. WAITING state

Definition: When a thread is in WAITING state, it waits for a specific operation from another thread (such as notification or interruption) and does not continue execution.

Trigger conditions: Common ways a thread enters WAITING include calling Object.wait(), Thread.join(), or LockSupport.park().

Resumption: The thread remains in WAITING until another thread calls notify() or notifyAll() (for Object.wait()) or it is interrupted.

2. TIMED_WAITING state

Definition: When a thread is in TIMED_WAITING state, it waits for a condition but will automatically return after a specified time.

Trigger conditions: Typical causes are Thread.sleep(milliseconds), Object.wait(milliseconds), Thread.join(milliseconds), LockSupport.parkNanos() or LockSupport.parkUntil().

Resumption: The thread resumes automatically after the timeout or when another thread calls notify() or notifyAll().

Next we combine with actual code analysis:

In the code, queryActTp runs getActivityInfo with two sub‑tasks, while queryQualityTp runs getQualityInfo with five sub‑tasks; both are executed in parallel within queryActAndQualityTp.

Second‑level monitoring screenshots for getActivityInfo and getQualityInfo are shown above.

Although the call patterns are the same, the threads appear in different states; theoretically both should be TIMED_WAITING. For queryActTp the stack shows LockSupport.park instead of LockSupport.parkNanos, requiring further investigation.

Another issue: thread pool A invokes pools B and C in parallel, causing CPU pressure under high load. The logic is refactored to use a single pool for activity and qualification queries; the change is postponed for now.

2. Flame Graph Analysis

2.1 wait thread

2.2 lock performance

2.3 CPU sampling

2.3.1 getFatherActivity analysis

Q1: Called in a loop; Q2: Large JSON (≈50 000 characters) deserialization; Q3: New ArrayList creation; Q4: Only the first element of grouped objects used – using toMap would be better.

Optimization 1:

We observed multiple stream calls inside the loop; moving the toMap logic outside the loop reduces overhead.

Other methods also consume high CPU; left unchanged for now.

Further optimization: a utility class to collect concurrent thread results.

1. After allOf exception, cancel all threads to prevent wasted CPU from timeouts.

2. Reduce excessive exception logs by filtering based on exception type.

All waiting in concurrent threads now uses the unified method; the previous WAITING state of queryActTp may be due to missing cancellation. After redeployment, further observation is needed. The TIMED_WAITING state of queryQualityTp likely relates to longer sub‑task execution time, as shown in monitoring data.