Java Concurrency Interview

Testing concurrent code question 165 of 180 mid

What makes a concurrency test flaky, and how do you deal with flakiness?

The usual causes are all fixable: sleeps standing in for conditions, assertions on how long something took, shared static state or singletons leaking across tests, ports and temp files that collide, and pools not shut down so threads from one test run during another.

The cultural part is the real answer. An intermittent failure in a concurrency test is evidence of a race somewhere, in the test or in the code, and adding a retry annotation discards that evidence. Quarantine it if it blocks the build, but keep it running and keep the failure output, including a thread dump.

Useful hygiene: make each test create and shut down its own executor, give threads names that identify the test, and run the suite occasionally with more threads than cores to change the interleavings.

testing ci

Quiz yourself on Testing concurrent code Suggest a correction