A JUnit 5 suite runs concurrently, but wall-clock time barely improved: many classes declare exclusive resource locks and several are marked to run in isolation. How do you reason about the tradeoff between locking shared resources and redesigning the tests?

## Recognising the situation A suite that is nominally parallel but effectively sequential is a common end state. It happens because locking is the cheap local fix: a test flakes, someone adds an exclusive lock or an isolation annotation, the build goes green, and nobody measures the aggregate. After a year the suite has the complexity of concurrency and the throughput of sequential execution — the worst of both. The principal-level skill here is not knowing the annotations; it is knowing how to decide where to spend effort, and when to stop. ## Step 1 — quantify before touching anything Without data you will optimise the wrong lock. The things worth counting: - **Per key: number of declaring tests × total time held.** A key declared by 200 fast tests can cost less than one declared by 4 slow ones. Time held includes setup and teardown, since the lock spans the whole node. - **Exclusive versus shared declarations per key.** A key where every declaration is exclusive is a pure queue; if most of those tests only observe the resource, the mode is simply wrong and the fix is one-line. - **Isolated classes: count and duration.** Each is a barrier that drains and refills the pool, so its real cost is roughly its duration multiplied by the parallelism, plus the ramp on either side. - **Achievable floor.** The critical path is the longest chain of work that cannot overlap. If that floor is close to your current wall-clock, no amount of lock tuning helps and the answer is elsewhere. ## Step 2 — the escalation ladder **1. Delete the sharing.** The best lock is the one that does not exist. Most shared state in test suites is incidental: a fixed port becomes an ephemeral one, a shared temp file becomes a per-test directory, a mutated JVM default becomes an injected parameter, a shared database becomes a schema or a rolled-back transaction per test. This costs the most engineering time and returns the most, because it removes the constraint permanently instead of scheduling around it. **2. Narrow the key.** One coarse key that every integration test declares is a global bottleneck wearing a scoped disguise. If the underlying resource is partitionable — per table, per tenant, per port, per property — give each partition its own key so unrelated tests stop queueing. The cost is a convention only your codebase knows, which is a real downside for JVM-wide resources where interoperability with other people's tests matters more than throughput. **3. Narrow the scope.** A class-level lock is held for every test in the class, including the many that never touch the resource, and it also forces the class's methods onto one thread. Moving the annotation to the two methods that need it often recovers most of a class's parallelism for the cost of a two-line diff. Likewise, move slow setup that does not need the resource outside the locked node. **4. Downgrade the mode.** Tests that only observe should declare shared read access so they overlap each other, pausing only around genuine writers. This is frequently the highest ratio of benefit to effort, because the exclusive default gets copy-pasted onto read-only tests without thought. **5. Question the isolation.** Audit each isolated class and ask what exactly it interferes with. Most answers name a specific resource, which means it can be downgraded to a scoped lock. The ones that survive are usually measurements — throughput, latency, memory — where the interference is CPU and memory contention with no key to name. Those may not belong in the parallel unit suite at all; a separate, sequential performance suite gives a better signal and stops penalising everyone else. ## Step 3 — know when locking is the right answer Not every lock is debt to repay. Some shared state is imposed and irreducible: the JVM has one default locale and one set of system properties; a licensed external system may allow one session; a hardware device or an emulator may be genuinely single. Locking these is correct engineering, and the review question is only whether the key is right, the scope is minimal and the mode is honest. The judgement call is economic. Making a test independent might take an hour or a week. Compare that against the wall-clock minutes it returns, multiplied by how often the suite runs and how many engineers wait on it. A ten-minute suite run 200 times a day justifies far more investment than a two-minute suite run twice. ## Step 4 — consider the levers outside the suite Intra-JVM parallelism is only one dial. Sharding the suite across several CI machines sidesteps in-process contention entirely and often costs less engineering time than isolating tests, at the price of CI spend. Splitting fast unit tests from slow integration tests lets the fast tier stay clean and highly parallel while the contended tier runs on its own schedule. And deleting redundant tests is the underrated option: suites accumulate coverage that no longer earns its runtime. ## Step 5 — keep it from regressing Whatever you fix will come back unless the ratchet holds: track the number of exclusive locks and isolated classes as a visible metric, require a reason string on every isolation, and make new occurrences a review conversation rather than a silent commit. The failure mode is cultural, not technical — locking is the path of least resistance for an engineer under deadline, so the guardrail has to sit in review, not in the framework.