PrepBro
← Назад к вопросам

Что будет при использовании AtomicInteger в счетчике с большим количеством потоков?

2.0 Middle🔥 111 комментариев
#Docker, Kubernetes и DevOps#JVM и управление памятью

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI23 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

AtomicInteger с большим количеством потоков: contention и performance

Использование AtomicInteger в условиях высокого contention может привести к серьёзному падению производительности. Рассмотрю почему и как это решать.

Что такое AtomicInteger и почему он полезен

// AtomicInteger — потокобезопасный счётчик
public class Counter {
    private AtomicInteger count = new AtomicInteger(0);
    
    public void increment() {
        count.incrementAndGet();  // Атомарная операция
    }
    
    public int getCount() {
        return count.get();  // Атомарное чтение
    }
}

// Вместо synchronized (блокировка целого метода)
public class BadCounter {
    private int count = 0;
    
    public synchronized void increment() {
        count++;  // Медленнее при contention
    }
}

AtomicInteger использует CAS (Compare-And-Swap) операции, а не блокировки. Но при высоком contention это не помогает.

Проблема 1: False Sharing (неправильное разделение кэша)

// ❌ ПЛОХО: Множество потоков пишут в один AtomicInteger
public class HighContentionCounter {
    private static final int NUM_THREADS = 16;
    
    private AtomicInteger sharedCounter = new AtomicInteger(0);
    
    public void benchmark() throws Exception {
        Thread[] threads = new Thread[NUM_THREADS];
        
        long start = System.nanoTime();
        
        for (int i = 0; i < NUM_THREADS; i++) {
            threads[i] = new Thread(() -> {
                for (int j = 0; j < 1_000_000; j++) {
                    sharedCounter.incrementAndGet();  // Все потоки дерутся за один объект
                }
            });
            threads[i].start();
        }
        
        for (Thread t : threads) {
            t.join();
        }
        
        long duration = System.nanoTime() - start;
        System.out.println("Время: " + duration / 1_000_000 + "ms");
        System.out.println("Счётчик: " + sharedCounter.get());
    }
}

// Результат: ~2000ms (ОЧЕНЬ МЕДЛЕННО)
// Каждый incrementAndGet() вызывает CAS, который конфликтует между потоками

Что происходит на уровне процессора

atomicCounter находится в одной L1 кэш-линии (64 байта).

Поток 1 пишет:  atomicCounter.incrementAndGet()
↓
CPU 1: загружает кэш-линию в L1 cache
CPU 1: изменяет atomicCounter
CPU 1: инвалидирует кэш-линию на других CPUs (cache coherency)

Поток 2 хочет писать:  atomicCounter.incrementAndGet()
↓
CPU 2: видит инвалидированную линию
CPU 2: загружает кэш-линию из памяти (ДОРОГО!)
CPU 2: пытается CAS — но CPU 1 уже изменил значение
CPU 2: RETRY CAS операцию

↑ FALSE SHARING: потоки деруться за одну кэш-линию

Проблема 2: Spin lock и CPU waste

// При высоком contention, CAS в atomicInteger работает как spin lock
public class AtomicInteger {
    public final int incrementAndGet() {
        for (;;) {  // БЕСКОНЕЧНЫЙ ЦИКЛ!
            int current = get();
            int next = current + 1;
            if (compareAndSet(current, next))  // Попробовать CAS
                return next;
            // Если неудачно — СНОВА в цикл (busy-wait)
        }
    }
}

// При 16 потоках пишущих в один atomicCounter:
// - Очень высокий retry rate
// - CPU крутится впустую (busy waiting)
// - Контекстные переключения
// - Системный нагрев

Решение 1: LongAdder (оптимально для счётчиков)

// ✅ ХОРОШО: LongAdder для счётчиков
public class LongAdderCounter {
    private static final int NUM_THREADS = 16;
    
    private LongAdder counter = new LongAdder();
    
    public void benchmark() throws Exception {
        Thread[] threads = new Thread[NUM_THREADS];
        
        long start = System.nanoTime();
        
        for (int i = 0; i < NUM_THREADS; i++) {
            threads[i] = new Thread(() -> {
                for (int j = 0; j < 1_000_000; j++) {
                    counter.increment();  // Гораздо быстрее!
                }
            });
            threads[i].start();
        }
        
        for (Thread t : threads) {
            t.join();
        }
        
        long duration = System.nanoTime() - start;
        System.out.println("Время: " + duration / 1_000_000 + "ms");
        System.out.println("Счётчик: " + counter.sum());
    }
}

// Результат: ~200ms (В 10 РАЗ БЫСТРЕЕ!)

Как работает LongAdder

// LongAdder использует stripe pattern
public class LongAdder {
    private transient volatile Cell[] cells;  // Массив ячеек
    private transient volatile long base;  // Base counter
    
    public void increment() {
        // Каждый поток может писать в СВОЮ ячейку
        Cell[] cs;
        long b;
        
        if ((cs = cells) != null) {
            // Несколько потоков пишут в разные ячейки
            // Нет contention!
            Cell c = cells[getProbeIndex()];
            if (c != null) {
                c.value++;
            }
        } else {
            // Небольшое количество потоков — пишем в base
            b = base;
            // ...
        }
    }
    
    public long sum() {
        // При чтении — суммируем все ячейки
        long sum = base;
        if (cells != null) {
            for (Cell c : cells) {
                sum += c.value;
            }
        }
        return sum;
    }
}

// Идея: распределить запись по многим ячейкам
// → каждый поток имеет свою ячейку
// → нет false sharing
// → нет contention

Сравнение производительности

16 потоков, каждый считает до 1 млн:

Атомик Integer:  2000ms  ❌ МЕДЛЕННО
LongAdder:        200ms  ✅ БЫСТРО
synchronized:    3000ms  ❌ ОЧЕНЬ МЕДЛЕННО

Производительность LongAdder в 10x лучше!

Решение 2: Stripe pattern (свой counter на поток)

// Если нужен точный счётчик (не LongAdder)
// Можно использовать stripe pattern
public class StripedCounter {
    private static final int STRIPES = Runtime.getRuntime().availableProcessors() * 2;
    private final AtomicInteger[] counters;
    
    public StripedCounter() {
        counters = new AtomicInteger[STRIPES];
        for (int i = 0; i < STRIPES; i++) {
            counters[i] = new AtomicInteger(0);
        }
    }
    
    public void increment() {
        // Каждый поток пишет в разный stripe
        int threadIndex = getThreadStripe();
        counters[threadIndex].incrementAndGet();
    }
    
    public int getTotal() {
        int total = 0;
        for (AtomicInteger counter : counters) {
            total += counter.get();
        }
        return total;
    }
    
    private int getThreadStripe() {
        // Простой способ: hash thread ID
        return (System.identityHashCode(Thread.currentThread()) % STRIPES);
    }
}

// Результат: ~250ms (близко к LongAdder)

Решение 3: ThreadLocal (для thread-safe без atomic)

// Если каждому потоку свой счётчик
public class ThreadLocalCounter {
    private static final ThreadLocal<Integer> counter = 
        ThreadLocal.withInitial(() -> 0);
    
    public void increment() {
        counter.set(counter.get() + 1);
    }
    
    public int getCount() {
        return counter.get();
    }
}

// ОЧЕНЬ БЫСТРО: нет синхронизации вообще
// Но: каждый поток имеет свой счётчик

Практический пример: метрики в production

// ❌ ПЛОХО: будет bottleneck
@Service
public class RequestMetrics {
    private AtomicInteger requestCount = new AtomicInteger(0);
    
    @Aspect
    @Around("@annotation(Timed)")
    public Object track(ProceedingJoinPoint pjp) throws Throwable {
        requestCount.incrementAndGet();  // Высокий contention при 1000 RPS!
        try {
            return pjp.proceed();
        } finally {
            // ...
        }
    }
}

// ✅ ХОРОШО: использовать LongAdder
@Service
public class RequestMetrics {
    private LongAdder requestCount = new LongAdder();
    
    @Aspect
    @Around("@annotation(Timed)")
    public Object track(ProceedingJoinPoint pjp) throws Throwable {
        requestCount.increment();  // Масштабируется
        try {
            return pjp.proceed();
        } finally {
            // ...
        }
    }
}

Рекомендации по выбору

| Сценарий | Инструмент | Причина |
|----------|-----------|----------|
| Счётчик с низким contention | AtomicInteger | Просто и достаточно |
| Счётчик с высоким contention | LongAdder | Масштабируется до 1000+ потоков |
| Нужна точная текущая стоимость | AtomicInteger | LongAdder требует sum() |
| Очень высокий contention | Stripe pattern | Максимум контроля |
| Не нужна точность | ThreadLocal | Самый быстро |
| Несколько полей | ConcurrentHashMap | Несколько counter в одной map |

Что видит profiler

// При AtomicInteger с contention:
// - Высокий CPU usage от busy-waiting
// - Много context switches
// - Cache misses
// - Contention points в flame graph

// При LongAdder:
// - Низкий CPU usage
// - Минимум context switches
// - Нет cache misses

Заключение

Что будет при AtomicInteger с большим количеством потоков:

  1. False sharing — потоки деруться за одну кэш-линию
  2. High retry rate в CAS операциях
  3. CPU busy-wait — циклы впустую
  4. Серьёзное падение производительности — может быть в 10x медленнее

Решение:

  • Для счётчиков → LongAdder (рекомендуется)
  • Для других случаев → Stripe pattern
  • Если не нужна точность → ThreadLocal

Это важный момент для production систем с высокой нагрузкой. LongAdder специально разработана для масштабирования при большом количестве потоков.

Что будет при использовании AtomicInteger в счетчике с большим количеством потоков? | PrepBro