How can I effectively test (unit/integration) concurrent code in Java?

Question

I saw this post on SO already but it still begs the question, at least for Java. It seems that this should be a pressing issue for any app (i'm testing a web app for this use case) that's multi-threaded. How have you guys dealt with it in a way that allows your threads to interleave -- inherently meaning testing random thread behavior.

Answer 1

I think it's inherently difficult, since you're looking to prove the absence of something in a (possibly) non-determinant system. Having said that, it's always worth writing repeatable tests to stress your multi-threaded components. If a problem occurs, you may not be able to repeat it, but you can perhaps find the bug by inspection. So make sure your tests log the relevant exceptions in great detail (and possibly input parameters etc.)

It's also worth running a static code analyser. These will pick up (amongst other things) inconsistent synchronisation of variables, and immediately highlight areas for concern. FindBugs is one such tool.

Answer 2

I've typically spawned a huge number (like 100) threads in a unit test and sent them off against it in hopes of hitting a race condition :). Sadly, that's not very definitive. You can improve your odds though by having debug lines in your thread sensitive areas that cause the active thread to sleep for X millis. This strategy allows you to leaving gaping windows where other threads can interleave. These lines would only be active during unit testing (use aspects or hard code lines that only activate when a debug flag is set).

Proving a negative is hard to impossible. You can't really prove you don't have a concurrency issue. All you can do is set up your tests to exercise it as thoroughly as possible.