Preface

Recently, I was studying the source code of ConcurrentHashMap and found that it uses a more unique way to count the number of elements in the map. Naturally, it is necessary to study its principles and ideas, and at the same time to better understand ConcurrentHashMap itself.

The main idea of this article is divided into the following 4 parts

1. The effect of counting

2. An intuitive illustration of the principle

3. Detailed analysis of the source code

4. Comparison with AtomicInteger

5. The abstraction of thought

The entrance to learning is naturally the put method of map

public V put(K key, V value) {
    return putVal(key, value, false);
}

View putVal method

There is not much discussion about the principle of ConcurrentHashMap itself, so we jump directly to the counting part

final V putVal(K key, V value, boolean onlyIfAbsent) {
    ...
    addCount(1L, binCount);
    return null;
}

Whenever an element is successfully added, the addCount method will be called to accumulate the number by 1, which is the goal of our research

Because the original intention of ConcurrentHashMap is to solve the map operation in multi-threaded concurrent scenarios, it is natural to consider thread safety when adding values.

Of course, multi-threaded value accumulation is generally the first lesson in learning concurrent programming. It is not very complicated. You can use AtomicInteger or locks to solve this problem.

However, if we look at the method, we will find that an accumulation method that should be relatively simple, but its logic looks quite complicated

Here I only posted the core part of the accumulation algorithm

private final void addCount(long x, int check) {
    CounterCell[] as; long b, s;
    if ((as = counterCells) != null ||
            !U.compareAndSwapLong(this, BASECOUNT, b = baseCount, s = b + x)) {
        CounterCell a; long v; int m;
        boolean uncontended = true;
        if (as == null || (m = as.length - 1) < 0 ||
                (a = as[ThreadLocalRandom.getProbe() & m]) == null ||
                !(uncontended =
                        U.compareAndSwapLong(a, CELLVALUE, v = a.value, v + x))) {
            fullAddCount(x, uncontended);
            return;
        }
        if (check <= 1)
            return;
        s = sumCount();
    }
    ...
}

Let's study the idea of implementing this logic. This idea actually copied the logic of the LongAdder class, so we directly look at the original class of the algorithm

1. Use of LongAdder class

Let's first look at the effect of LongAdder

LongAdder adder = new LongAdder();
int num = 0;

@Test
public void test5() throws InterruptedException {
    Thread[] threads = new Thread[10];
    for (int i = 0; i < 10; i++) {
        threads[i] = new Thread(() -> {
            for (int j = 0; j < 10000; j++) {
                adder.add(1);
                num += 1;
            }
        });
        threads[i].start();
    }
    for (int i = 0; i < 10; i++) {
        threads[i].join();
    }
    System.out.println("adder:" + adder);
    System.out.println("num:" + num);
}

Output result

adder:100000
num:40982

It can be seen that the adder can ensure the cumulative thread safety in terms of the effect of use.

2. Intuitive understanding of LongAdder principle

In order to better analyze the source code, we need to understand its principle intuitively, otherwise, if you look at the code directly, you will be confused.

The count of LongAdder is mainly divided into 2 objects

A field of type long: base

An array of Cell objects, the Cell object maintains a long field value for counting

/**
 * Table of cells. When non-null, size is a power of 2.
 */
transient volatile Cell[] cells;

/**
 * Base value, used mainly when there is no contention, but also as
 * a fallback during table initialization races. Updated via CAS.
 */
transient volatile long base;