Локи и примитивы синхронизации

ReentrantLock: тот же замок, но с ручками

ReentrantLock даёт то же взаимное исключение, что и synchronized, но с управлением. Метод tryLock пробует взять замок и уходит, если не вышло. tryLock с таймаутом позволяет обойти взаимную блокировку отступлением: не дождался - отпусти своё и повтори позже. Метод lockInterruptibly делает ожидание отзывчивым к отмене. Плюс честный режим против голодания и несколько условий ожидания на один замок.

Плата за ручное управление - дисциплина: unlock строго в finally. Иначе первое же исключение оставит замок захваченным навсегда, и все остальные потоки встанут. Поэтому дефолт - synchronized, он отпускает монитор сам, а ReentrantLock берут ради конкретной возможности.

// Есть и специализированные варианты. ReadWriteLock пускает много читателей ИЛИ одного писателя - выигрывает там, где чтений сильно больше. StampedLock быстрее и умеет оптимистичное чтение, но не поддерживает повторный вход, поэтому применяется точечно.

lock.lock();
try { balance += x; }
finally { lock.unlock(); }   // всегда finally

tryLock с таймаутом

не дождался - отпусти своё и попробуй снова

повторный вход

поток может взять свой же замок ещё раз

Сравнение с обменом и атомарные типы

Сравнение с обменом - это одна инструкция процессора: «замени значение на новое, если оно всё ещё равно ожидаемому». Подход оптимистичный: не запирать заранее, а попробовать; не вышло, потому что кто-то успел раньше - прочитать заново и повторить. На этом стоит вся конструкция без блокировок.

Атомарные типы оборачивают эту инструкцию в удобные методы: incrementAndGet, compareAndSet, updateAndGet. Потоки при этом не засыпают - нет ни очереди за монитором, ни риска взаимной блокировки на этом участке. В моём замере AtomicInteger давал точные 400 000 при двух потоках по 200 000 инкрементов.

// Грабли ровно одни: get и set по отдельности - это уже НЕ атомарная пара, между ними влезет другой поток. Составное изменение делают через compareAndSet в цикле или через updateAndGet. А под жёсткой конкуренцией за один счётчик повторы начинают жечь процессор, и тогда берут LongAdder: он расщепляет значение по ячейкам и складывает их при чтении.

сравнение с обменом

«замени, если ожидаемое» - основа работы без блокировок

LongAdder

счётчик по ячейкам против борьбы за одну переменную

Координация: защёлка, барьер, семафор, очередь

CountDownLatch - одноразовый счётчик «дождись N событий». Главный поток стоит на await, рабочие отмечаются вызовом countDown. Типичные случаи: старт после инициализации всех подсистем, тест ждёт завершения потоков. Перезарядить её нельзя.

CyclicBarrier - многоразовая точка встречи: N потоков доходят до барьера и продолжают вместе. Подходит для пошаговых алгоритмов, где все обязаны закончить шаг, прежде чем начнётся следующий. Мнемоника короткая: защёлку ждут снаружи, на барьере встречаются сами.

Semaphore - счётчик разрешений: не больше N потоков одновременно внутри участка. Так ограничивают число соединений или защищают внешний сервис от перегруза.

// Блокирующая очередь закрывает схему «производитель и потребитель» целиком: put и take сами блокируются, когда надо. И критично, чтобы ёмкость была ОГРАНИЧЕННОЙ - именно она создаёт обратное давление, притормаживая производителя. Безлимитная очередь вместо давления копит задачи, пока не кончится память.

защёлка и барьер

одноразовое ожидание N событий / многоразовый сбор N потоков

обратное давление

ограниченная очередь тормозит производителя

Как отвечать: «Когда возьмёшь ReentrantLock вместо synchronized?»

Дефолт у меня synchronized: он короче, монитор отпускается сам, и компилятор его хорошо оптимизирует. ReentrantLock беру, когда нужна конкретная возможность. Первая - tryLock с таймаутом, чтобы не зависнуть навсегда и обойти взаимную блокировку отступлением. Вторая - lockInterruptibly, чтобы ожидание реагировало на отмену. Третья - несколько условий на один замок, например «очередь не пуста» и «очередь не полна» по отдельности. Четвёртая - честный режим против голодания. Плата за это - unlock строго в finally, иначе первое исключение оставит замок захваченным и все встанут. И отдельный современный случай: на горячих путях с виртуальными потоками ReentrantLock предпочтительнее, потому что synchronized до Java 24 прибивает виртуальный поток к несущему. Я это мерил: сто виртуальных потоков, каждый со своим замком, спят по 50 миллисекунд - под synchronized прогон занял 2,51 секунды, под ReentrantLock 0,05.

Сильный ответ: назван дефолт и четыре осознанные причины отступить от него, каждая с задачей. Актуальная деталь про виртуальные потоки, да ещё с числами, показывает, что знание не из старых конспектов.

На чём валят

• −Пишут lock без unlock в finally. Первое же исключение оставляет замок навсегда, остальные ждут вечно.
• −Ставят замок вокруг одного счётчика. Атомарный тип проще, быстрее и не даёт взаимной блокировки.
• −Считают get и set атомарной парой. Между ними гонка, нужен compareAndSet или updateAndGet.
• −Путают защёлку и барьер: одноразовое ожидание событий против многоразовой встречи потоков.
• −Берут безлимитную очередь «для надёжности». Вместо обратного давления получают рост очереди до нехватки памяти.