Search the library

Capture repeated thread dumps and identify many threads blocked on the same owner or monitor. Use a profiler or JFR lock events to quantify contention and critical-section time. Reduce lock scope, shard independent state, batch updates, or use concurrent primitives only when they preserve the invariant; verify throughput and correctness under representative load.

Capture repeated thread dumps with jcmd or jstack while the incident is active. A deadlock cycle shows threads waiting for locks held by each other; distinguish it from starvation or a slow dependency by checking whether owners can progress. Fix consistent lock order, shorten critical sections, or redesign ownership so both locks are not required together.

Thread pools reuse worker threads. A ThreadLocal value can remain attached after a request ends, retaining large objects or exposing one request’s context to a later task if it is not overwritten. Clear it in a finally block or use a scoped context mechanism with well-defined propagation and cleanup.

If every worker submits a task to the same bounded executor and synchronously waits for that task, no worker remains to run queued children. This is thread-pool starvation, not necessarily a monitor deadlock. Avoid blocking composition on the same pool, separate workloads, or use asynchronous completion and bounded concurrency.

An async route can yield during nonblocking I/O, allowing the event loop to serve other work. A normal def route is typically run in a thread pool. Calling blocking I/O inside async def blocks the event loop; using async syntax alone does not improve CPU-bound work. Choose an execution model based on the library and bottleneck.

High allocation can cause frequent collections while post-GC occupancy remains broadly stable. A leak tends to retain objects that should have become unreachable, so compare heap dumps and dominator paths across time. Check allocation rate, live set, GC logs, and process/container memory together before changing heap settings.