Prefacio

Recientemente, estaba estudiando el código fuente de ConcurrentHashMap y descubrí que utiliza una forma más única de contar la cantidad de elementos en el mapa. Naturalmente, es necesario estudiar sus principios e ideas y, al mismo tiempo, comprender mejor el propio ConcurrentHashMap.

La idea principal de este artículo se divide en las siguientes 4 partes

1. El efecto de contar

2. Ilustración intuitiva del principio

3. Análisis detallado del código fuente

4. Comparación con AtomicInteger

5. La abstracción del pensamiento

La entrada al aprendizaje es, naturalmente, el método put de map

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

Ver método putVal

Aquí no hay mucha discusión sobre el principio de ConcurrentHashMap en sí, por lo que saltamos directamente a la parte de conteo

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

Siempre que un elemento se agregue con éxito, se llamará al método addCount para realizar la operación de acumular el número por 1, que es el objetivo de nuestra investigación.

Debido a que la intención original de ConcurrentHashMap es resolver la operación del mapa en escenarios concurrentes de subprocesos múltiples, es natural considerar la seguridad de los subprocesos al agregar valores.

Por supuesto, la acumulación de valor de subprocesos múltiples es generalmente la primera lección en el aprendizaje de la programación concurrente. No es muy complicado. Puede usar AtomicInteger o bloqueos para resolver este problema.

Sin embargo, si miramos este método, encontraremos que la lógica de un método de acumulación que debería ser más simple parece bastante complicada.

Aquí solo publiqué la parte central del algoritmo de acumulación

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();
    }
    ...
}

Estudiemos la idea de implementar esta lógica. Esta idea realmente copió la lógica de la clase LongAdder, por lo que miramos directamente la clase original del algoritmo

1. Uso de la clase LongAdder

Veamos primero el efecto de uso de 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);
}

Resultado de salida

adder:100000
num:40982

Se puede ver que el sumador puede garantizar la seguridad acumulativa del hilo en términos del efecto de uso.

2. Comprensión intuitiva del principio LongAdder

Para analizar mejor el código fuente, debemos comprender su principio de manera intuitiva; de lo contrario, si observa el código directamente, se confundirá.

El recuento de LongAdder se divide principalmente en 2 objetos

Un campo de tipo largo: base

Una matriz de objetos Cell, el objeto Cell mantiene un valor de campo largo para contar

/**
 * 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;