Краткий ответ

Да. Неблокирующий вызов tryLock() без тайм-аута может захватить свободную блокировку, даже если другой поток уже ожидает её получения. Параметр честности ReentrantLock на такой вызов не распространяется.

Исторический контекст

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

Честные блокировки появились как компромисс для сценариев, где важнее предсказуемое обслуживание очереди, чем максимальная производительность. Они стараются отдавать блокировку наиболее давно ожидающему потоку, однако это не превращает планирование потоков в строгую FIFO-очередь.

Постановка проблемы

Разработчик может включить честный режим и предположить, что любой последующий захват обязан уважать очередь ожидания. Если после этого использовать tryLock() для быстрого захвата, новый поток способен обойти уже ожидающие потоки.

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

Подробное решение

Конструктор ReentrantLock(true) включает честный режим для блокирующих операций захвата. Вызов lock() обычно ориентируется на очередь ожидающих потоков, а поток, уже владеющий этой блокировкой, может повторно войти в неё благодаря повторной входимости.

Безтайм-аутный tryLock() работает иначе: он проверяет, свободна ли блокировка в данный момент, и немедленно забирает её при успехе. Он намеренно может обойти ожидающий поток, поэтому даже честный ReentrantLock не делает такой вызов справедливым.

Временная форма tryLock(timeout, unit) учитывает честность блокировки при ожидании. Поэтому выбор зависит от требования: безтайм-аутный вариант даёт минимальную задержку и быстрый отказ, а временной вариант лучше сохраняет порядок ожидания, но может блокироваться и реагировать на interrupt.

import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.ReentrantLock;

ReentrantLock lock = new ReentrantLock(true);

if (lock.tryLock()) {          // может обойти очередь
    try {
        process();
    } finally {
        lock.unlock();
    }
}

if (lock.tryLock(100, TimeUnit.MILLISECONDS)) { // учитывает fairness
    try {
        process();
    } finally {
        lock.unlock();
    }
}

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

Ситуация из практики

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

Рассматривались два варианта. Полностью неблокирующая схема с tryLock() имела меньшую среднюю задержку при слабой конкуренции, но давала нестабильные задержки и риск длительного ожидания. Использование только lock() соблюдало ожидаемую очередь, но лишало систему возможности ограничить время ожидания.

Выбрали tryLock() с тайм-аутом и обработкой неуспешной попытки как контролируемого отказа. Это сохранило ограничение времени ожидания и сделало честный режим значимым; результатом стали более предсказуемые задержки и отсутствие ложного ожидания строгой справедливости от безтайм-аутного вызова.

Что кандидаты часто упускают

Гарантирует ли честный ReentrantLock строгий порядок FIFO?

Нет. Он предоставляет более высокую вероятность обслуживания давно ожидающих потоков, но не гарантирует абсолютный FIFO-порядок. На результат влияют планировщик ОС, приоритеты, прерывания, тайм-ауты и момент, в который поток фактически становится ожидающим.

Обходит ли очередь временной tryLock с тайм-аутом?

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

Устраняет ли честная блокировка голодание?

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