How do you test concurrent code reliably, given that concurrency bugs are often non-deterministic?

Because race conditions and other concurrency bugs depend on unpredictable thread interleaving, they frequently don't show up in a simple, single-run unit test even when the underlying bug is real. Several strategies help surface them more reliably. The jcstress harness, the Java Concurrency Stress test suite, is purpose-built for testing memory-model and concurrency correctness at a very fine-grained level. A CountDownLatch-based synchronized start pattern, where many threads are all made to wait on one latch and then released simultaneously, maximizes the chance of real contention and problematic interleavings during a test. Simply running a test tens of thousands of times in a loop is a blunt but effective way to let rare race conditions eventually manifest. Tools like Google's Thread Weaver can deliberately interleave thread execution at specific points in the bytecode to force particular orderings that would otherwise be rare. Property-based testing frameworks such as jqwik can run many concurrent workers against a shared object and continuously verify an invariant holds, for example that a total account balance remains constant across many concurrent transfers. Mutation testing tools like PItest can also be configured with concurrency-specific mutations to check whether your tests would actually catch subtle concurrency bugs if introduced.