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顺序获取。