🧵 StampedLock: когда ReentrantReadWriteLock уже не справляется

Если знаком с ReentrantReadWriteLock, то знаешь идею: много читателей одновременно, но запись эксклюзивна. Звучит разумно, но у этой модели есть фундаментальная проблема: читатели блокируют писателей.

Поток, который хочет писать, ждёт пока все читатели закончат. При высокой read-нагрузке писатель может ждать очень долго. StampedLock решает именно это.

🔵 Три режима, не два

ReentrantReadWriteLock даёт два режима — read и write. StampedLock добавляет третий — optimistic read.

StampedLock lock = new StampedLock();

// обычный read lock
long stamp = lock.readLock();
try {
    // читаем
} finally {
    lock.unlockRead(stamp);
}

// write lock
long stamp = lock.writeLock();
try {
    // пишем
} finally {
    lock.unlockWrite(stamp);
}

Это знакомо. Но вот где начинается интересное:

long stamp = lock.tryOptimisticRead();
// читаем данные без блокировки вообще
int value = this.value;

if (!lock.validate(stamp)) {
    // кто-то писал пока мы читали — перечитываем под реальным локом
    stamp = lock.readLock();
    try {
        value = this.value;
    } finally {
        lock.unlockRead(stamp);
    }
}

tryOptimisticRead() не захватывает никакого лока, а просто возвращает штамп. validate() проверяет — была ли запись с момента получения штампа. Если нет, то данные консистентны, идём дальше, если да, то фолбэк на обычный read lock.

🔵 Что такое stamp

Это long, который кодирует состояние лока. Каждая успешная запись инвалидирует все оптимистичные штампы. Поэтому validate() — это просто битовая проверка, без CAS, без синхронизации, так что она очень дешёвая.

🔵 Где это реально даёт профит

Сценарий: данные читаются в 95% случаев, пишутся редко. Классический пример — кеш, конфигурация, счётчики с инкрементом.
С ReentrantReadWriteLock все читатели всё равно захватывают shared lock — это операция на AQS, есть накладные расходы. С StampedLock + optimistic read при отсутствии конкурентных записей блокировки нет вообще.

🔵 Подводные камни

— StampedLock не реентерабельный. Если поток захватил write lock и попытается захватить его снова — дедлок. Это принципиальное отличие от ReentrantReadWriteLock.

— Нет поддержки Condition. Если тебе нужен await/signal — StampedLock не подойдёт.

— Нет поддержки прерывания в обычных методах readLock()/writeLock(). Есть отдельные readLockInterruptibly() — но это уже осознанный выбор.

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

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#CoreJava