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

Question

就像我在一个项目中使用tryLock()方法一样，同时使用相同的问题时，引人注意的问题是tryLock()被称为非阻塞机制，它如何设法在不阻塞的情况下获得锁定。

可能有两种情况

1. 它没有在内部使用synchronized块/方法，那么问题是，它如何在多线程环境中工作
2. 它在内部使用synchronized阻塞/方法，那么问题是，它如何非阻塞

为了找到答案，我检查了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

它如何设法获得锁而不阻塞？

它并不总是能锁住。 重点lock.tryLock() ：当lock.lock()阻止了调用者时， lock.lock()可能失败。

它不使用同步块或功能

那会破坏目的。 重点不是出于任何原因进行阻止。

我不熟悉该代码，但看起来好像是在compareAndSetState(0, acquires) ）中实际获取（或不compareAndSetState(0, acquires)该锁。 可能在其中心某处有“ 比较并设置”硬件指令。

FWIW， AtomicInteger.compareAndSet（...）函数的作用非常相似。