concurrency-diagnosticslisted

# Concurrency Diagnostics ## Purpose Classify loss of progress before changing concurrency policy. Deadlock, starvation, saturation, livelock, a slow dependency and leaked work can all produce high latency with little useful CPU, but their confirming evidence and remediation differ. This skill owns evidence collection and classification. It routes proven causes to the skills that own JMM correctness, lock internals, executor lifecycle, virtual-thread mechanics or capacity. ## Evidence workflow The reference baseline is HotSpot Java 25. Inspect the project's toolchain, runtime image, actual vendor/update and diagnostic tool version before using the matrix. Scheduler MXBean access requires Java 24+; virtual-thread dumps require a supporting runtime. Keep the target version unchanged and use available evidence when a tool is unsupported or attach is denied. Record that limitation instead of interpreting missing output as no threads or no contention. 1. Freeze the incident interval: timestamps, deployment/JDK build, traffic, CPU quota, changes and affected operation/tenant. 2. Define progress numerically: completions, queue age, successful state transitions or durable offsets—not “threads look stuck.” 3. Capture application state: accepted/started/completed/failed/cancelled/rejected counts, queue age and depth, in-flight work, resource permits/connections and downstream latency. 4. Capture multiple thread views several seconds apart. Use traditional dumps for platf