ReentrantLock.tryLock() 如何工作，从源代码看来它不使用同步块或函数

Question

当我在我的一个项目中使用 tryLock() 方法时，在使用相同的方法时，令人震惊的问题是 - tryLock() 据说是非阻塞机制，它是如何实现的设法在没有阻塞的情况下获得锁。

可以有两种情况

它内部没有使用synchronized block/method，那么问题来了，它在多线程环境下如何工作
内部使用的是synchronizedblock/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，它在多线程环境中如何工作？

Answer 1

how does it manages to get a lock without blocking?

它并不总是获得锁。这就是重点：当 lock.lock() 会阻止调用者时，lock.tryLock() 可能会失败。

it does not use synchronized block or function

那会破坏目的。关键是不要以任何理由阻止。

我不熟悉该代码，但看起来锁实际上是在 compareAndSetState(0, acquires) 中获取（或未获取）的。可能在它的核心某处有一条 Compare and Set 硬件指令。

FWIW，AtomicInteger.compareAndSet(...) 函数的作用非常相似。

ReentrantLock.tryLock() 如何工作，从源代码看来它不使用同步块或函数

How does ReentrantLock.tryLock() works as it seems from source code that it does not use synchronized block or function

java

multithreading

nonblocking

reentrantlock