Почему нельзя использовать синхронизацию для счетчика при большом количестве потоков?

Synchronized счетчик при высокой конкурентности

Это отличное дополнение к вопросу о synchronized. Проблема реальная и воспроизводимая на практике.

Проблема: Contention

Когда много потоков пытаются одновременно обновить один synchronized счетчик, возникает contention (争夺):

// ПЛОХО - горячее место контенции
public class BadCounter {
    private int count = 0;
    
    public synchronized void increment() {
        count++;  // Все потоки борются за один lock
    }
}

// Визуализация:
Thread 1: --------LOCK-------unlock-
Thread 2: -----WAIT------LOCK--UNLOCK--
Thread 3: ---WAIT-------LOCK--UNLOCK---
Thread 4: WAIT-----LOCK--UNLOCK--------

// Только ОДИН поток выполняет в момент времени
// Остальные ждут - впустую потраченное CPU время

Почему это плохо

1. Context Switching Overhead

ОС переключает контекст потоков, это дорого:

Benchmark:          Operations/sec
─────────────────────────────────
Single-threaded:    500,000,000  (500M)
Synchronized (4 потока):   25,000,000  (25M)  - в 20 раз медленнее!
Synchronized (8 потоков):    8,000,000  (8M)   - в 62 раза медленнее!
Synchronized (16 потоков):   2,000,000  (2M)   - в 250 раз медленнее!

2. Lock Contention Graph

Throughput
   |
 100M|  ___________
     | |           \
  50M|_|     ___    \___
     |     |   |         \
   0 |_____|___|___________|______
       1   2   4   8   16   32   64  threads
       
Синхронизированный счетчик - линия падает резко!
Атомарный счетчик - держится лучше
LongAdder - почти плоская линия

3. False Sharing (bonus проблема)

Даже если несколько потоков работают с разными переменными, они могут быть в одной CPU cache line (64 байта):

public class FalseSharingExample {
    public long value1 = 0;      // CPU Line 0-63
    public long value2 = 0;      // CPU Line 0-63 (SAME LINE!)
    
    // Thread 1 пишет value1, Thread 2 пишет value2
    // Но они в одной cache line - конфликт!
    // Обновления одного инвалидируют кэш другого
}

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

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.LongAdder;

public class CounterBenchmark {
    
    // 1. Synchronized счетчик
    static class SyncCounter {
        private int count = 0;
        public synchronized void increment() { count++; }
        public synchronized int getValue() { return count; }
    }
    
    // 2. AtomicInteger счетчик
    static class AtomicCounter {
        private final AtomicInteger count = new AtomicInteger(0);
        public void increment() { count.incrementAndGet(); }
        public int getValue() { return count.get(); }
    }
    
    // 3. LongAdder счетчик (лучший выбор)
    static class AdderCounter {
        private final LongAdder count = new LongAdder();
        public void increment() { count.increment(); }
        public long getValue() { return count.longValue(); }
    }
    
    static void benchmark(String name, Runnable counterOp, int threads, int iterations) 
            throws InterruptedException {
        long start = System.nanoTime();
        
        CountDownLatch latch = new CountDownLatch(threads);
        for (int t = 0; t < threads; t++) {
            new Thread(() -> {
                for (int i = 0; i < iterations; i++) {
                    counterOp.run();
                }
                latch.countDown();
            }).start();
        }
        
        latch.await();
        long elapsed = System.nanoTime() - start;
        
        long opsPerSec = (long) (threads * iterations * 1_000_000_000.0 / elapsed);
        System.out.printf("%s: %.0f ops/sec\n", name, opsPerSec);
    }
    
    public static void main(String[] args) throws InterruptedException {
        int threads = 8;
        int iterations = 10_000_000;
        
        SyncCounter syncCounter = new SyncCounter();
        AtomicInteger atomicCounter = new AtomicInteger(0);
        LongAdder adderCounter = new LongAdder();
        
        System.out.println("Benchmark with " + threads + " threads:\n");
        
        benchmark("Synchronized", syncCounter::increment, threads, iterations);
        benchmark("AtomicInteger", atomicCounter::incrementAndGet, threads, iterations);
        benchmark("LongAdder", adderCounter::increment, threads, iterations);
    }
}

// Типичный вывод:
// Benchmark with 8 threads:
// Synchronized:  42,000,000 ops/sec
// AtomicInteger: 280,000,000 ops/sec  (в 6.6x быстрее!)
// LongAdder:     850,000,000 ops/sec  (в 20x быстрее!)

Решение 1: AtomicInteger

Использует Compare-And-Swap (CAS) инструкцию процессора - lock-free:

public class AtomicCounter {
    private final AtomicInteger count = new AtomicInteger(0);
    
    public void increment() {
        count.incrementAndGet();  // CAS в hardware, не мютекс
    }
    
    public int getValue() {
        return count.get();
    }
}

Как работает CAS:

CAS(memory, expected, new):
  if (memory == expected) {
    memory = new;
    return true;
  } else {
    return false;
  }

Это ATOMIC инструкция на процессоре.
Нет OS-уровневой синхронизации.

Решение 2: LongAdder (ЛУЧШИЙ для счетчиков)

Использует striped counters - несколько счетчиков вместо одного:

public class BetterCounter {
    private final LongAdder count = new LongAdder();
    
    public void increment() {
        count.increment();  // Распределяет нагрузку
    }
    
    public long getValue() {
        return count.longValue();
    }
}

// LongAdder внутренне работает так:
private final Striped64 base;
private Cell[] cells;  // По одной Cell на каждый поток приблизительно

// increment():
if (U.getAndAddLong(this, BASE, 1L) < 0L) {
    // Если base занята, используем свою ячейку в массиве
    cells[threadIndex].increment();
}

// getValue():
return base + sum(cells);

Визуализация распределения:

Synchronized:           LongAdder:
ONE LOCK               MULTIPLE CELLS
   |                    |  |  |  |
  ALL              Thread1-+-+-+-+-
 THREADS           Thread2---+-+-+-
  WAIT             Thread3-----+-+-
                   Thread4-------+-

Thread 1, 2, 3, 4 редко борются за один lock!

Решение 3: Striped Pattern (DIY)

Для конкретного случая:

public class StripedCounter {
    private static final int STRIPES = 16;
    private final AtomicInteger[] counters = new AtomicInteger[STRIPES];
    
    public StripedCounter() {
        for (int i = 0; i < STRIPES; i++) {
            counters[i] = new AtomicInteger(0);
        }
    }
    
    public void increment() {
        // Каждый поток обновляет свою ячейку
        int index = (int) (Thread.currentThread().getId() % STRIPES);
        counters[index].incrementAndGet();
    }
    
    public long getValue() {
        long sum = 0;
        for (AtomicInteger counter : counters) {
            sum += counter.get();
        }
        return sum;
    }
}

Когда synchronized счетчик ПРИЕМЛЕМ

Если:
├─ Очень низкая конкурентность (1-2 потока)
├─ Счетчик редко обновляется
├─ Нет требований к производительности
└─ Legacy код, модернизация дорогая

Тогда:
  synchronized может быть OK

Правило выбора

Сценарий                  → Выбор
────────────────────────────────
Просто сумма              → LongAdder
Атомарные операции        → AtomicInteger/AtomicLong
Множество потоков (>4)    → LongAdder
Mutter-reader pattern     → AtomicReference + CAS
Сложная синхронизация     → ReentrantLock с меньшей гранулярностью
Много потоков + READ      → ReadWriteLock

Вывод

Synchronized счетчик - это худший выбор при высокой конкурентности потому что:

1. Contention - все потоки борются за один lock
2. Context switching - потраченное впустую CPU время
3. Scalability - производительность падает с увеличением потоков
4. False sharing - даже если защищаем разные переменные

LongAdder - это золотой стандарт для счетчиков в многопоточных системах. Он обеспечивает:

• Масштабируемость до десятков потоков
• Lock-free операции
• Минимальный overhead
• Отличную производительность

Для высоконагруженных систем это не опциональное знание - это требование к production качеству кода.