ThreadSafe: Fast way to discover concurrency problems

When I first heard about ThreadSafe I first thought “damn, one more static code analysis tool on the market“. After using tools like PMD or FindBugs in our in-house development and after spending considerable amount of time to achieve the zero-warning policy, I was pretty sure there is no reason to use yet another tool. Well, I was terribly wrong.

The ThreadSafe is in many ways similar to other static analysis tools, except it’s strongly focused to one very important aspect of Java programming – concurrency. The guys from Contemplate did a great job in recognizing the need for a tool that can quickly point to possible problems in the code related to concurrency and multi-threading.

The tool can be used in two ways – as Eclipse plug-in or as Sonar plug-in. I tested the Eclipse plug-in and tried to analyze the source code of inspectIT, the free performance diagnose tool we develop in-house. I needed less than 3 minutes to install the plug-in, run the analysis on the complete source code and get valuable results.

The first impression I had when I was looking to the results was “hey, these warnings really have sense“. I hate the tools that report dozen of warnings, but only few of them are reasonable. The ThreadSafe defines total of 18 rules at the moment and all of the rules are defined carefully and smartly. In addition every single rule is very well documented and everybody can easily understand what a concrete warning means.

In our project the ThreadSafe found 44 potential problems divided into 9 problem types. The highest number of warnings were related to Inconsistent synchronization (15) and Non atomic use of Get/Check/Put (10). We did not need to much time to fix the problems, cause once you know where exactly they are and what can be the solution you can do it fast.

To demonstrate one example of using the ThreadSafe, I took a screen shot of the problem description in one of our classes and pasted the related source code:

As you can see, we easily found a class that instantiates a thread-safe list for one field, but also defines a public setter for that field that accepts list interface as parameter. Meaning that our thread-safe list could easily be substituted by any kind of list implementation, which would lead to synchronization issues due to the fact that class expects to work on thread-safe one. Thanks to the ThreadSafe we were able to fix this problem and many more.

I think that correct usage of concurrency is fundamental for high-performance applications and I believe that using ThreadSafe can considerably decrease the risk of wrong implementations of concurrency. Thus, each project should consider having a tool like ThreadSafe to prevent problems occurring even in an early development phase.