Lock: що це, типи блокувань та використання в синхронізації

Що таке Lock?

Lock — це інтерфейс із пакета java.util.concurrent.locks, що надає явні операції захоплення та звільнення для синхронізації доступу до даних. На відміну від synchronized, Lock дає розробнику повний контроль над механізмом блокування.

Визначення та роль у синхронізації

Інтерфейс Lock з'явився в Java 5 як альтернатива вбудованому механізму synchronized. Основні методи — lock, unlock, tryLock та lockInterruptibly. Блокування дозволяють організувати безпечний доступ до даних у багатопотоковому середовищі, запобігаючи станам гонки та пошкодженню даних.

Головна перевага Lock перед synchronized — гнучкість. Розробник може спробувати захопити блокування з таймаутом, перевірити його зайнятість без блокування або організувати кілька черг очікування з різними пріоритетами.

Історія розвитку

До появи інтерфейсу Lock у Java 5 єдиним способом синхронізації був synchronized, який страждав від обмежень: відсутність таймаутів, неможливість перервати очікування та єдина черга. Doug Lea спроєктував пакет java.util.concurrent, включивши в нього Lock як фундаментальний будівельний блок.

Як працює блокування?

Блокування керує доступом через внутрішній прапорець стану та чергу очікування. Коли потік викликає lock(), механізм перевіряє, чи вільне блокування, і або захоплює його, або поміщає потік у чергу до звільнення.

Атомарне захоплення та звільнення

В основі будь-якого блокування лежить атомарна операція порівняння та встановлення (CAS). При виклику lock() потік намагається атомарно встановити прапорець зайнятості. Якщо прапорець уже встановлено, потік блокується. При unlock() прапорець скидається, і пробуджується один із потоків, що очікують.

import java.util.concurrent.locks.ReentrantLock

val lock = ReentrantLock()

fun performTask() {
    lock.lock()
    try {
        // критична секція
        println("Працює потік ${Thread.currentThread().name}")
    } finally {
        lock.unlock()
    }
}

Черга очікування та пробудження

ReentrantLock використовує всередині двобічну чергу (CLH lock queue), де кожен потік, що очікує, представлений вузлом. Коли блокування звільняється, головний вузол черги пробуджується. Режим fair (чесний) гарантує порядок FIFO, а unfair — допускає захоплення новим потоком перед тими, що очікують, для підвищення пропускної здатності.

Основні види блокувань

У сучасному Java-стеку існує кілька реалізацій блокувань, кожна з яких оптимізована під конкретні сценарії. Вибір правильного блокування безпосередньо впливає на продуктивність і надійність багатопотокового додатка.

ReentrantLock

ReentrantLock — базова та найчастіше використовувана реалізація Lock. Вона підтримує повторне захоплення тим самим потоком: якщо потік уже володіє блокуванням, повторний виклик lock() не блокує його. Це запобігає deadlock при рекурсивних викликах.

ReentrantReadWriteLock

ReadWriteLock розділяє блокування на два режими: читання та запис. Кілька потоків можуть одночасно утримувати блокування читання, але запис потребує ексклюзивного доступу. Це значно підвищує продуктивність при частому читанні та рідкісному записі.

StampedLock

StampedLock — новітня реалізація, що з'явилася в Java 8. Вона підтримує три режими: запис, читання та оптимістичне читання. Оптимістичне читання не блокує інші потоки та перевіряє валідність даних після читання, що дає приріст продуктивності на 10-20% порівняно з ReadWriteLock.

ReentrantLock та його особливості

ReentrantLock — найпопулярніша реалізація Lock, що надає ряд можливостей, недоступних у synchronized. Розуміння її особливостей необхідне для ефективної роботи з багатопотоковістю.

Чесність блокування (fairness)

Конструктор ReentrantLock приймає параметр fair. При true блокування гарантує FIFO-порядок доступу, при false можливе захоплення новим потоком раніше за ті, що очікують. Чесний режим запобігає голодуванню, але знижує пропускну здатність на 10-20% через додаткові накладні витрати на підтримку черги.

Таймаути та переривчасте очікування

На відміну від synchronized, ReentrantLock підтримує tryLock з таймаутом. Якщо блокування не вдалося захопити за вказаний час, потік продовжує виконання, а не блокується нескінченно. Метод lockInterruptibly дозволяє перервати потік, що очікує, через Thread.interrupt().

val lock = ReentrantLock()

fun tryTask() {
    if (lock.tryLock(500, TimeUnit.MILLISECONDS)) {
        try {
            println("Блокування захоплено")
        } finally {
            lock.unlock()
        }
    } else {
        println("Не вдалося захопити блокування")
    }
}

Умови (Conditions)

ReentrantLock підтримує кілька умовних змінних через метод newCondition(). Кожна Condition має власну чергу очікування, що дозволяє організувати складні сценарії пробудження. Методи await() та signal() замінили wait() та notify() із synchronized-блоків, але з підтримкою кількох черг.

ReadWriteLock та StampedLock

ReadWriteLock та StampedLock вирішують задачу оптимізації доступу при переважанні операцій читання над записом. Вони значно ефективніші за ReentrantLock у сценаріях, де читання відбувається частіше за запис.

ReadWriteLock на практиці

Інтерфейс ReadWriteLock містить два методи: readLock() та writeLock(). Блокування читання може утримуватися кількома потоками одночасно, блокування запису — лише одним. Типовий приклад — потокобезпечний кеш: безліч потоків читають дані, і лише один періодично оновлює їх.

class SafeCache<K, V> {
    private val map = mutableMapOf<K, V>()
    private val rwLock = ReentrantReadWriteLock()

    fun get(key: K): V? {
        rwLock.readLock().lock()
        return try { map[key] } finally { rwLock.readLock().unlock() }
    }

    fun put(key: K, value: V) {
        rwLock.writeLock().lock()
        return try { map[key] = value } finally { rwLock.writeLock().unlock() }
    }
}

StampedLock та оптимістичне читання

StampedLock додає третій режим — tryOptimisticRead. Цей режим не блокує інші потоки, а лише запам'ятовує штамп (stamp) стану. Після читання розробник викликає validate(stamp), перевіряючи, чи не змінилися дані за час читання. Якщо дані змінилися, операцію потрібно повторити.

Блокування в мобільній розробці

У мобільних додатках блокування використовуються для координації доступу до спільних даних між потоками. Однак їх застосування потребує особливої обережності через обмежені ресурси пристрою та необхідність зберігати чуйність інтерфейсу.

Блокування в Android (Kotlin)

На Android ReentrantLock корисний при роботі з Room, кешами та файлами. Важливо пам'ятати: ніколи не захоплюйте блокування на головному потоці. Для асинхронного коду кращі корутини та Mutex із kotlinx.coroutines, які не блокують потік, а призупиняють корутину.

Блокування в iOS (Swift)

У iOS стандартний Lock із NSLock використовується рідше — розробники надають перевагу DispatchQueue з barrier-прапорцями або операційним блокуванням os_unfair_lock. Swift 5.7+ надає сучасні механізми синхронізації через actors, які автоматично захищають стан.

import Foundation

actor DataStore {
    private var items: [String] = []

    func add(_ item: String) {
        items.append(item)
    }

    func getAll() -> [String] {
        items
    }
}

Рекомендації щодо уникнення deadlock

Щоб уникнути deadlock, дотримуйтеся єдиного порядку захоплення всіх блокувань у проєкті. Використовуйте tryLock з таймаутом замість lock() скрізь, де можливе блокування на тривалий час. Розгляньте застосування Lock-Free алгоритмів (AtomicReference, ConcurrentHashMap) замість традиційних блокувань.

Найкращі практики роботи з Lock

Застосування Lock потребує дисципліни та дотримання кількох правил, які запобігають deadlock та падінню продуктивності. Ці практики вироблені спільнотою Java за 20 років використання пакета java.util.concurrent.

Звільнення в finally

Найважливіший патерн — lock у finally. Незалежно від того, завершилася критична секція успішно чи з винятком, блокування має бути звільнене. Це гарантує, що інші потоки не заблокуються назавжди через одну помилку. У Kotlin цей патерн елегантно вирішується через екстеншн withLock.

Мінімізація часу утримання

Критична секція має бути максимально короткою. Ніколи не виконуйте всередині блокування введення-виведення, мережеві запити або тривалі обчислення. Якщо потрібно прочитати дані з сервера, спочатку отримайте їх, а потім захопіть блокування лише для оновлення спільного стану. Це знижує конкуренцію та підвищує пропускну здатність системи.

Єдиний порядок захоплення

Для запобігання deadlock при роботі з кількома Lock фіксуйте глобальний порядок захоплення по всьому проєкту. Якщо спочатку захоплюється lockA, потім lockB — будь-яка зворотна послідовність має бути заборонена правилами code review. Для автоматичної перевірки використовуйте статичні аналізатори, такі як SpotBugs та IntelliJ Inspections.