AQS(队列同步器)的FIFO问题

AQS(队列同步器)的FIFO问题

最近学习java的并发多线程，看的是《java并发编程的艺术》这本书。书中讲到了java中Lock接口的具体实现，依赖的就是AQS(AbstractQueuedSynchronized)架构。AQS中一个Volatile int 变量state来记录同步状态。每次lock时会调用aqs的tryAcquire()方法尝试获得同步状态（具体是获取state判断并用cas操作修改state），当获取不成功时就会将其加入aqs中的等待队列，当获得同步状态的线程释放锁时，才会唤醒等待队列中的线程，但只有队列中第一个能获得同步状态。
然后在书中作者附上了一个自定义的Lock实现类组合aqs的子类实现共享式同步状态锁，代码为

public class TwinsLock implements Lock {   //共享式访问
    private final Sync sync = new Sync(2);
    private static final class Sync extends AbstractQueuedSynchronizer {
        Sync(int count) {
            if (count <= 0) {
                throw new IllegalArgumentException("count must large than zero.");
            }
            setState(count);
        }
        public int tryAcquireShared(int reduceCount) {
            System.out.println(Thread.currentThread().getName()+"请求锁");
            for (;;) {
                int current = getState();
                int newCount = current - reduceCount;
                if (newCount < 0 || compareAndSetState(current,
                        newCount)) {
                    return newCount;
                }
            }
        }
        public boolean tryReleaseShared(int returnCount) {
            System.out.println(getFirstQueuedThread());
            System.out.println(Thread.currentThread().getName()+"释放锁");
            for (;;) {
                int current = getState();
                int newCount = current + returnCount;
                if (compareAndSetState(current, newCount)) {
                    return true;
                }
            }
        }
    }
    public void lock() {
        sync.acquireShared(1);
    }
    public void unlock() {
        sync.releaseShared(1);
    }

    @Override
    public void lockInterruptibly() throws InterruptedException {

    }

    @Override
    public boolean tryLock() {
        return false;
    }

    @Override
    public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {
        return false;
    }

    @Override
    public Condition newCondition() {
        return null;
    }
}

public class TwinsLockTest {
    @Test
    public void test() {
        final Lock lock = new TwinsLock();
        class Worker extends Thread {
            Worker(String name){
                super(name);
            }
            public void run() {
                while (true) {
//                    SleepUtils.second(1);
                    lock.lock();
                    try {
                        SleepUtils.second(1);
                        System.out.println(Thread.currentThread().getName());
                        SleepUtils.second(1);
                    } finally {
                        lock.unlock();
                    }
                }
            }
        }
// 启动10个线程
        for (int i = 0; i < 10; i++) {
            Worker w = new Worker("Thread->"+i);
            w.setDaemon(true);
            w.start();
        }
// 每隔1秒换行
        for (int i = 0; i < 100; i++) {
            SleepUtils.second(1);
            System.out.println();
        }
    }
}

结果为：

虽然确实做到2个线程共享式同步状态，但是却是反复是相同的线程获得锁，而不是等待队列中的第一个线程。前面说只有等待队列中第一个线程能获取到同步状态，即队列中的线程FIFO，而这为什么不符合等待队列FIFO的原则？

然后我对代码加了一点输出信息得到：

作者给出的代码中一个线程释放掉锁后立刻去获取锁，于此同时，等待队列中的线程被唤醒也来尝试获取锁，但是等待队列中的线程是唤醒并尝试获取，比起这边直接去获取可能会有点慢（个人理解），所以等待队列中的线程来不及改变state状态，而此时state状态是可获取的就被原线程获取到state并修改，并没有加入等待队列中（个人理解就是这个线程跑的快，在队列中的线程还没来得及反应就插队了）。所以等待队列中的线程竞争失败继续等待，而原线程获得锁继续执行。
折腾半天后继续往后面看清楚，其实这就是后面所说的公平锁和非公平锁的概念了，非公平锁上，只有当锁被某个线程持有时，新发出请求的线程才会被放入队列中（此时和公平锁是一样的），所以获取顺序不一定符合FIFO，即这个例子是非公平的锁。
所以最后呈现出获得锁的线程并没有按照FIFO顺序获取。