Как работает ReentrantLock.tryLock (), как видно из исходного кода, что он не использует синхронизированный блок или функцию - PullRequest
Новая
       15

Как работает ReentrantLock.tryLock (), как видно из исходного кода, что он не использует синхронизированный блок или функцию

0 голосов
/ 24 мая 2018

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

Может быть два сценария

  1. Он не использует synchronized блок / метод внутри, тогда вопрос в том, как он работает в многопоточной среде
  2. Он использует synchronized block / method для внутреннего использования, тогда возникает вопрос, как это неблокирует

Чтобы найти ответ, я проверил приведенный ниже код для tryLock

public boolean tryLock() {
    return sync.nonfairTryAcquire(1);
}

И здесь идет код для sync.nonfairTryAcquire(1), который фактически выполняет работу 

 final boolean nonfairTryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
            if (compareAndSetState(0, acquires)) {
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        else if (current == getExclusiveOwnerThread()) {
            int nextc = c + acquires;
            if (nextc < 0) // overflow
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        return false;
    }

Поскольку кажется, что код для tryLock() нигде не использует synchronized, как это работает в многопоточной среде?

1 Ответ

0 голосов
/ 24 мая 2018

как удается получить блокировку без блокировки?

Это не не всегда получает блокировку.В этом весь смысл: lock.tryLock() может потерпеть неудачу, когда lock.lock() заблокировал бы вызывающего абонента.

он не использует синхронизированный блок или функцию

, которая бы победилацель.Дело в том, что не блокировать по любой причине.

Я не знаком с этим кодом, но похоже, что блокировка фактически получена (или нет) в compareAndSetState(0, acquires).Возможно, где-то в основе лежит аппаратная инструкция Compare and Set .

FWIW, AtomicInteger.compareAndSet (...) делает нечто очень похожее.

...