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.

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

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.