[DevoxxUK2025] The Hidden Art of Thread-Safe Programming: Exploring java.util.concurrent
At DevoxxUK2025, Heinz Kabutz, a renowned Java expert, delivered an engaging session on the intricacies of thread-safe programming using java.util.concurrent. Drawing from his extensive experience, Heinz explored the subtleties of concurrency bugs, using the Vector class as a cautionary tale of hidden race conditions and deadlocks. Through live coding and detailed analysis, he showcased advanced techniques like lock striping in LongAdder, lock splitting in LinkedBlockingQueue, weakly consistent iteration in ArrayBlockingQueue, and check-then-act in CopyOnWriteArrayList. His interactive approach, starting with audience questions, provided practical insights into writing robust concurrent code, emphasizing the importance of using well-tested library classes over custom synchronizers.
The Perils of Concurrency Bugs
Heinz began with the Vector class, often assumed to be thread-safe due to its synchronized methods. However, he revealed its historical flaws: in Java 1.0, unsynchronized methods like size() caused visibility issues, and Java 1.1 introduced a race condition during serialization. By Java 1.4, fixes for these issues inadvertently added a deadlock risk when two vectors referenced each other during serialization. Heinz emphasized that concurrency bugs are elusive, often requiring specific conditions to manifest, making testing challenging. He recommended studying java.util.concurrent classes to understand robust concurrency patterns and avoid such pitfalls.
Choosing Reliable Concurrent Classes
Addressing an audience question about classes to avoid, Heinz advised against writing custom synchronizers, as recommended by Brian Goetz in Java Concurrency in Practice. Instead, use well-tested classes like ConcurrentHashMap and LinkedBlockingQueue, which are widely used in the JDK and have fewer reported bugs. For example, ConcurrentHashMap evolved from using ReentrantLock in Java 5 to synchronized blocks and red-black trees in Java 8, improving performance. In contrast, less-used classes like ConcurrentSkipListMap and LinkedBlockingDeque have known issues, making them riskier choices unless thoroughly tested.
Lock Striping with LongAdder
Heinz demonstrated the power of lock striping using LongAdder, which outperforms AtomicLong in high-contention scenarios. In a live demo, incrementing a counter 100 million times took 4.5 seconds with AtomicLong but only 84 milliseconds with LongAdder. This efficiency comes from LongAdder’s Striped64 base class, which uses a volatile long base and dynamically allocates cells (128 bytes each) to distribute contention across threads. Using a thread-local random probe, it minimizes clashes, capping at 16 cells to balance memory usage, making it ideal for high-throughput counters.
Lock Splitting in LinkedBlockingQueue
Exploring LinkedBlockingQueue, Heinz highlighted its use of lock splitting, employing separate locks for putting and taking operations to enable simultaneous producer-consumer actions. This design boosts throughput in single-producer, single-consumer scenarios, using an AtomicInteger to ensure visibility across locks. In a demo, LinkedBlockingQueue processed 10 million puts and takes in about 1 second, slightly outperforming LinkedBlockingDeque, which uses a single lock. However, in multi-consumer scenarios, contention between consumers can slow LinkedBlockingQueue, as shown in a two-consumer test taking 320 milliseconds.
Weakly Consistent Iteration in ArrayBlockingQueue
Heinz explained the unique iteration behavior of ArrayBlockingQueue, which uses a circular array and supports weakly consistent iteration. Unlike linked structures, its fixed array can overwrite data, complicating iteration. A demo showed an iterator caching the next item, continuing correctly even after modifications, thanks to weak references tracking iterators to prevent memory leaks. This design avoids ConcurrentModificationException but requires careful handling, as iterating past the array’s end can yield unexpected results, highlighting the complexity of seemingly simple concurrent structures.
Check-Then-Act in CopyOnWriteArrayList
Delving into CopyOnWriteArrayList, Heinz showcased its check-then-act pattern to minimize locking. When removing an item, it checks the array snapshot without locking, only synchronizing if the item is found, reducing contention. A surprising discovery was a labeled if statement, a rare Java construct used to retry operations if the array changes, optimizing for the HotSpot compiler. Heinz noted this deliberate complexity underscores the expertise behind java.util.concurrent, encouraging developers to study these classes for better concurrency practices.
Virtual Threads and Modern Concurrency
Answering an audience question about virtual threads, Heinz noted that Java 24 improved compatibility with wait and notify, reducing concerns compared to Java 21. However, he cautioned about pinning carrier threads in older versions, particularly in ConcurrentHashMap’s computeIfAbsent, which could exhaust thread pools. With Java 24, these issues are mitigated, making java.util.concurrent classes safer for virtual threads, though developers should remain vigilant about potential contention in high-thread scenarios.