Testing thread-safety in Java

Question

Possible Duplicate:
How should I unit test threaded code?
Guidelines for testing multithreaded code or ensuring that code is thread-safe

Is it possible to "unit test" whether a simple class is thread safe or not?

My specific case is a simple class, that subsets vectors: given a "white list" of vector positions to keep and an input vector, it produces an output vector with only the values at the positions in the white list. I'd like to write a unit test (if it is possible) to make sure that if we refactor this class in the future, we keep it thread safe. The unit test would fail if the class is no longer thread safe. I realize this is somewhat vague and under defined.

Only way to be sure would be to actually run it through some intensive threaded tests designed to catch things like race conditions and dropped values. — Wug, Aug 20 '12 at 15:43
But would it work reliably, and would the tests fail only sometimes? — Frank, Aug 20 '12 at 15:44
You can't prove that a class is thread safe with testing. You can merely try to stress test it, hoping that if you have concurrency bugs, they will show up, but without any guarantee that they will. — assylias, Aug 20 '12 at 15:44
possible duplicate of [How should I unit test threaded code?](http://stackoverflow.com/questions/12159/how-should-i-unit-test-threaded-code) and [Guidelines for testing multithreaded code or ensuring that code is thread-safe](http://stackoverflow.com/questions/4444452) — Tomasz Nurkiewicz, Aug 20 '12 at 15:45
If your class is complicated, it's hard to prove they can't exist logically either. Unit tests arent really designed for this sort of thing. — Wug, Aug 20 '12 at 15:46
Related: http://stackoverflow.com/questions/4418373/designing-a-test-class-for-a-custom-barrier/4427499#4427499 — assylias, Aug 20 '12 at 15:48
Are there basic things I could check on the class, maybe via introspection: either that it is immutable, or that setters at least have @synchronized. Of course, I realize that's not enough to make the class thread safe, but it could be a beginning. — Frank, Aug 20 '12 at 15:53
The problem with unit testing for thread problems is that your test harness virtually always has different timing behavior (and CPU and memory behavior too) than your real application, and thread problems are usually sensitive to such things. This is because things like deadlock-freedom and liveness are _global_ properties, and not (usually) component-level properties. — Donal Fellows, Aug 21 '12 at 08:01

score 5 · Answer 1 · answered Aug 20 '12 at 16:30

Thread-safe is a property that a class has or doesn't have. Thread-safety can mean, depending on the context, absence of race conditions, the execution of code in a particular order or whatever else.

Testing cannot prove the absence of bugs, it can only reveal them. In my (not-so-vast) experience with ensuring that multithreaded code is correct probably the best tip is to keep the code as simple and clear as possible and try to discover bugs by inspection. Repeatedly running tests won't help too much.

score 5 · Answer 2 · answered Aug 20 '12 at 16:42

This is exactly what Java Pathfinder is for. It has a bit of a steep learning curve, but it's actually possible to build exhaustive proofs with this tool. You build a scenario and run it with JPF, then JPF explores all possible thread orderings to find possible errors. You need to build assertions into your program for JPF to check. JPF assumes sequential consistency during execution, but you can use the Java Racefinder plugin to prove that too.

Admittedly, it's hard to build a proper proof—but it is possible. If nothing else JPF can be used to help you root out some concurrency errors that you might otherwise miss.

Testing thread-safety in Java

2 Answers2