Java AQS如何实现非公平锁

Question

最近看了AQS的源码 但是看完之后有很多问题

final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            final Node p = node.predecessor();
            if (p == head && tryAcquire(arg)) {
                setHead(node);
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    int ws = pred.waitStatus;
    if (ws == Node.SIGNAL)
        /*
         * This node has already set status asking a release
         * to signal it, so it can safely park.
         */
        return true;
    if (ws > 0) {
        /*
         * Predecessor was cancelled. Skip over predecessors and
         * indicate retry.
         */
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0);
        pred.next = node;
    } else {
        /*
         * waitStatus must be 0 or PROPAGATE.  Indicate that we
         * need a signal, but don't park yet.  Caller will need to
         * retry to make sure it cannot acquire before parking.
         */
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}

这是自旋请求资源的方法，但是shouldParkAfterFailedAcquire()方法中，可以得知，在队列中等待的线程，基本都会被park,然后来看release()

public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);
        return true;
    }
    return false;
}

unparkSuccessor将会唤醒后继节点，但是只唤醒了一个，所以我产生了一个疑问，如果只唤醒了一个线程，那么用aqs实现非公平锁，在tryRelease中直接抢锁，但是抢锁失败后，加入队列中，仍然需要按照顺序被唤醒，还是不是完完全全的非公平，但是总觉得是不是有问题，请大神指点我一下

Answer 1

我最近也是有这个疑问，楼主现在知道了吗？求解答

补充：
自己琢磨了下，个人理解应该是这样的，欢迎指正

线程在doAcquire方法中获取锁时，会先加入同步队列，之后根据情况再陷入阻塞。当阻塞后的节点一段时间后醒来时，这时候来了新的更多的线程来抢锁，这些新线程还没有加入到同步队列中去，也就是在tryAcquire方法中获取锁。
在公平锁下，这些新线程会发现同步队列中存在节点等待，那么这些新线程将无法获取到锁，乖乖去排队；
而在非公平锁下，这些新线程会跟排队苏醒的线程进行锁争抢，失败的去同步队列中排队。
因此这里的公平与否，针对的其实是苏醒线程与还未加入同步队列的线程
而对于已经在同步队列中阻塞的线程而言，它们内部自身其实是公平的，因为它们是按顺序被唤醒的，这是根据AQS节点唤醒机制和同步队列的FIFO特性决定的
————————————————
版权声明：本文为CSDN博主「Mutou_ren」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Mutou_ren/article/details/103883011