java-concurrency-and-virtual-thread

name	java-concurrency-and-virtual-thread
description	Use this skill when statically reviewing Java concurrency and Project Loom virtual-thread adoption for correctness and safety at scale — pooling or capping virtual threads, a virtual-thread migration that strips a bound on a limited downstream resource (connection pool, rate-limited API) without re-imposing it via a Semaphore, JDK-version-gated carrier-pinning risk from synchronized blocks (materially reduced from JDK 24 onward by JEP 491 versus JDK 21's JEP 444), ThreadLocal cost at millions-of-threads scale, StructuredTaskScope's preview status, and classic concurrency hygiene (visibility/atomicity, unbounded ExecutorService queues, ThreadLocal leaks in pooled executors). Trigger when a user provides Java source using Thread.ofVirtual/Executors.newVirtualThreadPerTaskExecutor, ExecutorService construction, synchronized blocks, or JFR pinning output and asks whether their virtual-thread usage or concurrency code is correct. Reads source and sanitized configuration only; it never runs a build, invokes a JDK, attaches a profiler, or contacts a live system.
allowed-tools	Read Grep Glob
metadata	{"author":"github: Raishin","version":"0.1.0","updated":"2026-07-17","category":"compute","lifecycle":"experimental"}

java-concurrency-and-virtual-thread

Purpose

This skill statically assesses whether a Java codebase's virtual-thread adoption is correct and safe at scale, and whether its classic concurrency code is free of visibility, atomicity, and resource-exhaustion bugs. Virtual threads change the cost model of concurrency (creation is cheap, blocking is cheap) but do not remove the need to bound access to genuinely limited resources, and they introduce a JDK-version-dependent carrier-pinning hazard that is easy to over- or under-state without evidence. The review distinguishes what virtual threads fix (thread-creation cost, thread-count ceilings) from what they do not fix (the finite capacity of a downstream connection pool or rate-limited API), and gates every pinning claim on the JDK version and JFR evidence rather than blanket JDK-21-era folklore.