Facebook’s open-source static analysis tool, Infer, now ships with support for detecting race conditions in Java code via RacerD. RacerD identifies race conditions between methods in classes that use locks or the @ThreadSafe annotation.
Facebook has used RacerD in its own production code for the last year identifying more than 1,000 multi-threading issues, all before code ever reached production. This concurrency checking capability is now available to Java developers who use Infer to detect bugs in Java code.
A race condition is a type of concurrency error or bug that occurs when two threads operate on the same object without proper synchronization, causing their executions to overlap each other, and at least one of the accesses is a write. Concurrency issues are hard to debug and even harder to reproduce after encountered.
RacerD performs fast, useful concurrency analysis at scale. RacerD is fast because it doesn't try to check an entire code base for concurrency issues; it only examines the code that it believes can be run concurrently.
RacerD identifies code that can run concurrently by looking for classes, methods, and interfaces that have been explicitly annotated with the @ThreadSafe annotation or that create a lock via the synchronized keyword. When a class or interface is annotated with @ThreadSafe, all subclasses of the class/implementation are also evaluated. To increase code coverage with RacerD, additional optional annotations may be useful: @ThreadConfined, @Functional, @ReturnsOwnership, or @VisibleForTesting.
The RacerD analysis is started by using the plain infer command, which runs alongside other Infer analyses or the infer --racerd-only command, which runs RacerD alone. For example, the command infer --racerd-only -- javac StockPortfolio.java will run RacerD on StockPortfolio.java.
The sample code below, when inspected by RacerD, warns of one race condition.
@ThreadSafe
public class StockPortfolio {
int shares = 0;
public void buy(int count) {
if (count > 0) {
shares += count;
}
}
public int sell(int count){
if (count >= 0 && shares - count >= 0) {
shares -= count;
return shares;
} else {
return 0;
}
}
}
RacerD finds a bug:
Read/Write race. Public method int StockPortfolio.sell(int) reads from field StockPortfolio.shares. Potentially races with writes in methods void StockPortfolio.buy(int), int StockPortfolio.sell(int)
RacerD warns on data races that contain either unprotected writes or read/write races. RacerD is currently limited to checking for data races only; it doesn't check for other concurrency issues like deadlock and atomicity. RacerD also misses data races that are due to:
- aliasing
- locally declared objects escaping its scope
- accesses protected by different locks
- local objects containing non-owned objects
- weak memory and Java’s volatile keyword
These limitations stem from the design goal to reduce false positives, even if it leads to false negatives.
Co-authors Sam Blackshear and Peter O'Hearn wrote in their announcement:
Infer is used at Facebook in both a batch-mode deployment and as a bot participating in code reviews. In the deployment for code review, Infer runs as part of the Facebook continuous integration (CI) system. For each code change a developer submits, the CI runs Infer alongside other jobs for compilation and testing
RacerD is available on GitHub and more details can be found in the user guide.