Ответ
Да, работал. ReentrantLock — это альтернатива synchronized, предоставляющая больше гибкости. Основные преимущества:
- Возможность честного (fair) или нечестного (non-fair) распределения блокировок.
- Методы
tryLock(),lockInterruptibly(), позволяющие избежать deadlock. - Поддержка условий (
Condition) для более сложной синхронизации.
Пример:
val lock = ReentrantLock()
fun safeIncrement() {
lock.lock()
try {
counter++
} finally {
lock.unlock() // Важно освобождать в finally!
}
}Использую, когда нужен контроль над блокировками или сложная логика синхронизации.
Ответ 18+ 🔞
А, ну это же классика, ебать мои старые костыли! ReentrantLock — это типа как synchronized, только на стероидах, со всеми этими наворотами. Ну, знаешь, когда обычного synchronized уже мало, и хочется покомандовать процессом по-взрослому.
Основные плюсы, из-за которых его тащат, это:
- Можно выбрать, кому отдавать блокировку — кто первый встал, того и тапки (честный режим,
fair), или просто первому, кто успел вломиться (нечестный,non-fair). Обычно второй быстрее, ёпта. - Есть всякие хитрые методы вроде
tryLock(), чтобы не зависать намертво, если замок занят, илиlockInterruptibly(), чтобы тебя могли вежливо попросить отъебаться, если что. Спасение от дедлоков, ядрёна вошь! - И самое сокровенное — поддержка условий, этих самых
Condition. Это когда тебе нужно не просто в семафор поиграть, а устроить целый театр с ожиданием и пробуждением по конкретным сигналам. Ёперный театр, но мощная штука.
Вот, смотри, как это обычно выглядит в коде:
val lock = ReentrantLock()
fun safeIncrement() {
lock.lock() // Захватываем, как будто это последний пряник на тарелке
try {
counter++
} finally {
lock.unlock() // А это святое — отпускай в finally, иначе все накроется медным тазом!
}
}Лично я его в ход пускаю, когда обычной синхронизации уже не хватает, и начинается эта самая сложная логика, где потокам нужно не просто молчать, а общаться между собой по-умному. А так — да похуй, для простых случаев и synchronized с головой.
