Синхронизация в Java: основы

Введение в многопоточность предупреждало о трёх режимах сбоев — гонках, ошибках видимости и взаимных блокировках. synchronized — это первый ответ Java на первые два из них. Он даёт блоку кода сразу две гарантии: взаимное исключение (только один поток может находиться внутри в любой момент) и видимость памяти (записи, выполненные одним потоком внутри блока, будут видны следующему потоку, который войдёт в него). Этих двух гарантий вместе достаточно, чтобы сделать огромное количество многопоточного кода корректным.

Эта глава посвящена концепциям — что делает synchronized, что такое встроенный монитор, какие гонки он устраняет, а какие нет. Следующая глава, synchronized-блоки, показывает синтаксические формы и правила выбора между ними.

Гонка, для устранения которой и создан этот оператор

class Counter {
  int n;
  void increment() { n++; }
}

Counter c = new Counter();
// Thread A and Thread B both call c.increment() a million times.
// After both finish, what is c.n?

n++ — это одна строка исходного кода и три операции байткода: загрузить n, прибавить 1, сохранить n. Если поток A загрузил n=42, а затем поток B загружает n=42 до того, как A сохранил результат, оба прибавят 1 и оба сохранят 43. Одно приращение потеряно. Запустите программу по миллиону раз в каждом потоке, и c.n будет стабильно меньше 2_000_000.

synchronized — это решение:

class Counter {
  int n;
  synchronized void increment() { n++; }
}

Теперь только один поток одновременно выполняет increment на данном Counter. Остальные ждут у входа. Результат: c.n == 2_000_000 при каждом запуске.

Что такое монитор

У каждого Java-объекта внутри JVM есть связанная блокировка, называемая встроенным монитором (или монитором блокировки). Это просто структура данных с двумя состояниями: поток-владелец (или null) и очередь ожидания. Поток, входящий в блок synchronized:

Пытается захватить монитор объекта, на котором стоит synchronized.
Если монитор свободен, захватывает его (теперь owner == self) и продолжает работу.
Если монитор принадлежит другому потоку, этот поток переходит в состояние BLOCKED и встаёт в очередь ожидания.
Когда владелец покидает блок, JVM освобождает монитор и один из ожидающих потоков получает его.

Монитор принадлежит конкретному объекту. Два экземпляра Counter имеют два отдельных монитора; потоки, работающие с разными Counter, не блокируют друг друга. Это важно — синхронизация привязана к объекту, а не «к методу».

synchronized (someObject) {
  // critical section: only one thread at a time
  // holds someObject's monitor inside this block
}

synchronized на экземплярном методе — это синтаксический сахар для synchronized (this). На статическом методе — сахар для synchronized (Counter.class), то есть монитор объекта Class.

Видимость, а не только исключение

Взаимное исключение — очевидная часть. Менее очевидная — и более важная — это отношение happens-before, которое JVM предоставляет бесплатно:

Всё, что один поток делает перед освобождением монитора, гарантированно будет видно любому потоку, который впоследствии захватит тот же монитор.

Именно это делает synchronized корректным, а не просто «первый пришёл — первый обслужен». Без этого два потока могут использовать блок synchronized, договориться о взаимном исключении и всё равно видеть записи друг друга в неправильном порядке — потому что иначе кэши процессора и JIT вправе изменять порядок операций. Пара release/acquire устанавливает барьер памяти, который заставляет процессор и JIT сбросить и перезагрузить данные.

Следствие: любое поле, которое многопоточная программа читает или записывает за пределами блока synchronized (и не через volatile, атомарный тип или другой примитив java.util.concurrent), не имеет гарантии видимости. Один поток может записать done = true, а другой может навсегда видеть done = false. Мы вернёмся к этому, когда будем изучать volatile и модель памяти Java.

Что `synchronized` не исправляет

Четыре вещи, которых новички часто ожидают от synchronized, но которые он не обеспечивает:

Он не блокирует данные. synchronized (list) не запрещает другому коду трогать list; он запрещает другому потоку удерживать тот же монитор. Если какой-то другой путь кода обращается к list без захвата того же монитора, защита исчезает.
Он не компонуется между объектами. synchronized (a); synchronized (b); — это два отдельных захвата; если другой поток захватывает их в обратном порядке, возникает взаимная блокировка.
Он не ускоряет ничего. Блокировки — это чистые накладные расходы. Используйте их только там, где этого требует корректность.
Он не устраняет все гонки. Составные действия типа «проверить — действовать» всё равно гонят, даже если каждая отдельная операция синхронизирована. if (map.containsKey(k)) map.put(k, v) некорректен, даже если containsKey и put по отдельности потокобезопасны — промежуток между двумя вызовами не защищён. Используйте putIfAbsent или единый синхронизированный блок, охватывающий оба вызова.

Реентрабельность

Встроенный монитор является реентрабельным: поток, уже удерживающий монитор, может войти в другой блок synchronized на том же объекте, не блокируясь на самом себе. Именно поэтому это работает:

class Account {
  synchronized void deposit(int x) { balance += x; }
  synchronized void transferTo(Account other, int x) {
    deposit(-x);                                     // re-enters same monitor — fine
    other.deposit(x);                                // acquires other's monitor too
  }
}

Если бы мониторы не были реентрабельными, внутренний вызов deposit заблокировался бы на мониторе, который уже удерживает внешний вызов — мгновенная самоблокировка. Реентрабельность позволяет безопасно вызывать другой синхронизированный метод на том же объекте.

Обратная сторона: каждый захват должен сопровождаться соответствующим освобождением. JVM ведёт счётчик; монитор освобождается, когда счётчик падает до нуля.

На чём синхронизироваться

Несколько правил, которые предотвращают большинство ошибок неправильного использования блокировок:

Синхронизируйтесь на приватном объекте блокировки, а не на this. Внешний код также может выполнить synchronized (yourInstance); это позволяет вызывающему удерживать вашу блокировку сколь угодно долго. Приватный final Object lock = new Object(); принадлежит только вам, и никто другой не может его захватить.
Не синхронизируйтесь на строковых литералах или упакованных примитивах. Они интернированы/закэшированы; два блока synchronized ("foo") в разных частях кода разделяют монитор с кем угодно, кто тоже написал "foo".
Не синхронизируйтесь на ссылке, которая может измениться. synchronized (myField), где myField может быть переприсвоено, означает два разных монитора в разное время. Компилятор этого не замечает; ошибка молчалива.
Держите критическую секцию маленькой. Чем больше вы делаете внутри блока synchronized, тем дольше ждут все остальные. Удерживайте блокировку во время изменения общего состояния, а не во время окружающего ввода-вывода.

Разобранный пример: с блокировкой и без

Программа ниже запускает одну и ту же нагрузку на общий счётчик тремя способами: без синхронизации, с методом synchronized и с блоком synchronized на выделенном объекте блокировки. Числа показывают, что первая форма теряет обновления, а две другие — нет.

java— editable, runs on the server

public class SynchronizationDemo {
  // Unsafe: plain field, no synchronisation
  static class UnsafeCounter {
    int n;
    void increment() { n++; }
    int value() { return n; }
  }

// Safe v1: synchronized method — locks on 'this'
  static class SafeCounterV1 {
    int n;
    synchronized void increment() { n++; }
    synchronized int value() { return n; }
  }

// Safe v2: synchronized block on a private lock object — preferred
  static class SafeCounterV2 {
    private final Object lock = new Object();
    int n;
    void increment() {
      synchronized (lock) { n++; }
    }
    int value() {
      synchronized (lock) { return n; }
    }
  }

static long bench(Runnable work, int threads) throws InterruptedException {
    Thread[] ts = new Thread[threads];
    long t0 = System.nanoTime();
    for (int i = 0; i < threads; i++) {
      ts[i] = new Thread(work, "w-" + i);
      ts[i].start();
    }
    for (Thread t : ts) t.join();
    return (System.nanoTime() - t0) / 1_000_000;
  }

public static void main(String[] args) throws InterruptedException {
    int threads = 4;
    int perThread = 250_000;
    int expected = threads * perThread;

// --- Unsafe ---
    UnsafeCounter u = new UnsafeCounter();
    long uMs = bench(() -> { for (int i = 0; i < perThread; i++) u.increment(); }, threads);
    System.out.printf("unsafe:    expected %d  got %d  (%d ms)  -- lost %d updates%n",
        expected, u.value(), uMs, expected - u.value());

// --- Safe v1 (synchronized method) ---
    SafeCounterV1 v1 = new SafeCounterV1();
    long v1Ms = bench(() -> { for (int i = 0; i < perThread; i++) v1.increment(); }, threads);
    System.out.printf("sync method: expected %d  got %d  (%d ms)%n",
        expected, v1.value(), v1Ms);

// --- Safe v2 (synchronized block on private lock) ---
    SafeCounterV2 v2 = new SafeCounterV2();
    long v2Ms = bench(() -> { for (int i = 0; i < perThread; i++) v2.increment(); }, threads);
    System.out.printf("sync block:  expected %d  got %d  (%d ms)%n",
        expected, v2.value(), v2Ms);

// --- Reentrancy demo ---
    System.out.println("\nreentrancy: synchronized method calls another synchronized method on this");
    new Object() {
      synchronized void outer() { inner(); }
      synchronized void inner() { System.out.println("   inner held the same monitor twice (no deadlock)"); }
    }.outer();
  }
}

Что следует вынести из запуска:

Строка unsafe стабильно теряла обновления — итоговое значение оказывалось ниже ожидаемого 1_000_000. Два потока, выполняющих n++, гонятся на операции чтение-изменение-запись; некоторые приращения исчезают. Даже если тест однажды пройдёт удачно, JIT, планировщик ОС или другой процессор в итоге это обнажат. Несинхронизированное изменение общего поля — это ошибка.
Оба безопасных варианта давали точно ожидаемое значение при каждом запуске. Взаимное исключение — очевидная часть того, что делает synchronized; менее заметная часть в том, что значение, которое читает value(), является последним записанным increment — это и есть гарантия видимости. Без пары монитора чтение вполне законно могло бы увидеть устаревшую копию из кэша.
Показания времени для sync method и sync block были заметно выше, чем для unsafe. Блокировки не бесплатны — каждый вход/выход устанавливает барьер памяти и (при конкуренции) переключение контекста потока. Синхронизируйте там, где требует корректность; не разбрасывайте её «для безопасности».
Вариант sync block on private lock — это то, что используется в производственном коде. Форма sync method блокируется на this, которую может захватить любой внешний вызывающий — он может вас вытеснить, удерживая вашу же блокировку. Приватный объект блокировки, который вы никогда не раскрываете, принадлежит только вам.
Блок с реентрабельностью выполнился без взаимной блокировки. outer() уже удерживал монитор this; inner() вошёл в него повторно, не заблокировавшись. Именно поэтому синхронизированный метод может свободно вызывать другой синхронизированный метод на том же объекте — без реентрабельности половина стандартной библиотеки зашла бы в тупик.

Что дальше

Следующая глава, Java Synchronized Blocks, подробно рассматривает синтаксические формы — метод, блок, статический — и правила выбора правильного объекта блокировки. Для координации между потоками на более высоком уровне смотрите межпоточное взаимодействие (wait/notify).

Практика

Два потока вызывают `counter.increment()` у `Counter`, поле `n` которого является несинхронизированным `int`. После того как оба завершат 1 000 000 приращений, что обычно показывает `counter.n`?

Значение меньше 2 000 000 — `n++` является операцией чтение-изменение-запись, и потоки гонятся на ней, теряя некоторые обновленияРовно 2 000 000 — арифметика `int` атомарна в JavaРовно 1 000 000 — один поток всегда выигрывает гонку`ConcurrentModificationException`, потому что поле было затронуто двумя потоками