AQS对资源共享方式的非公平锁表述错误

[WeiKangJian]

原文中是当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的。
实际上源码中是当该锁释放时候，新来的线程和队列中第一个线程进行竞争，如果失败，加入到等待队列中去，对于队列中的所有等待线程依然是FIFO的。不公平是新线程相对于等待队列中的线程。原文的表述方式可能让读者误解非公平锁的实现方式

[jqh924]

👍 金庆华 魏康健 <notifications@github.com> 于2019年11月25日周一 下午10:19写道：

…

原文中是当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的。 实际上源码中是当该锁释放时候，新来的线程和队列中第一个线程进行竞争，如果失败，加入到等待队列中去，对于队列中的所有等待线程依然是FIFO的。不公平是新线程相对于等待队列中的线程。原文的表述方式可能让读者误解非公平锁的实现方式 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#569?email_source=notifications&email_token=AAL22AGK72PN2JWDJAEYMRDQVPNGDA5CNFSM4JRJTZW2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H32N6WQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAL22ADV23MO4HCDVX23TM3QVPNGDANCNFSM4JRJTZWQ> .

[LiWenGu]

确实是这样
JDK1.8

static final class NonfairSync extends Sync {
    private static final long serialVersionUID = 7316153563782823691L;

    /**
     * Performs lock.  Try immediate barge, backing up to normal
     * acquire on failure.
     */
    final void lock() {
        // 通过CAS改状态，其实就是和队列里的头抢锁
        if (compareAndSetState(0, 1))
            setExclusiveOwnerThread(Thread.currentThread());
        else
            // 如果抢失败了，就执行正常的 AQS 逻辑，即入队列，等唤醒
            acquire(1);
    }

    protected final boolean tryAcquire(int acquires) {
        return nonfairTryAcquire(acquires);
    }
}

原文中是当线程要获取锁时，无视队列顺序直接去抢锁，谁抢到就是谁的。
实际上源码中是当该锁释放时候，新来的线程和队列中第一个线程进行竞争，如果失败，加入到等待队列中去，对于队列中的所有等待线程依然是FIFO的。不公平是新线程相对于等待队列中的线程。原文的表述方式可能让读者误解非公平锁的实现方式

[Snailclimb]

赞！！！感谢各位大佬！