JDK9 CountedCompleter中VarHandle PENDING的作用及使用逻辑问询

Great question! This design is all about balancing performance, memory efficiency, and correctness in the high-concurrency context of the ForkJoin framework. Let's break it down:

1. Why not just use AtomicInteger? #

• Reduced memory overhead: AtomicInteger is a separate object, which adds extra heap allocation and indirection. Since CountedCompleter instances are often created in large numbers (especially in parallel tasks), avoiding this extra object cuts down on memory usage and GC pressure significantly.
• Lower-level control: VarHandle provides direct access to the field with customizable memory semantics (like different memory barriers), which is more flexible than AtomicInteger's fixed operations. This allows the JDK team to fine-tune concurrency behavior without wrapping the field in another object.
• Alignment with ForkJoin's performance goals: The ForkJoin framework is optimized for extreme parallelism. Every small overhead reduction (like avoiding an extra object) adds up when thousands of tasks are running concurrently.

2. Why different access patterns in each method? #

Let's look at each method's use case:

• setPendingCount(int count): This method is almost always called during task initialization, before the task is forked into multiple threads. At this point, there's no concurrent modification of the pending field, so a direct volatile write is safe and faster than an atomic operation. Volatile ensures the value is visible to subsequent threads, but we don't need atomicity here.
• addToPendingCount(int delta): This is called when adding new subtasks, which happens in concurrent contexts. We need an atomic increment to avoid race conditions where two threads try to update the count at the same time. VarHandle.getAndAdd() provides this atomicity efficiently without the overhead of an AtomicInteger.
• decrementPendingCountUnlessZero(): This method uses a two-step optimization:
  1. First, it reads the pending field directly. If the value is already 0, we can immediately return without any atomic operations—this avoids unnecessary CAS overhead in the common case where the count is already zero.
  2. If the count is non-zero, it uses VarHandle.weakCompareAndSet() to atomically decrement the value. The weak CAS is chosen because it's cheaper than a full CAS, and the loop handles any spurious failures.

By mixing direct volatile access and VarHandle atomic operations, the implementation gets the best of both worlds: speed in single-threaded initialization, and thread safety in concurrent modification scenarios.

内容的提问来源于stack exchange，提问作者ffcactus