public class ConditionCompareTest {
  private ReentrantLock lock = new ReentrantLock();
  private Condition condition = lock.newCondition();

  @Test
  public void runTest() throws InterruptedException {
    long begin = System.currentTimeMillis();
    for (int i = 0; i < 10000; i++) {
      if (i % 1000 == 0) {
        System.out.println(i);
      }
      aqsTest();
    }
    long cost = System.currentTimeMillis() - begin;
    System.out.println("耗时： " + cost);
  }

  @Test
  public void aqsTest() throws InterruptedException {
    AtomicInteger lockedNum = new AtomicInteger();
    List<Thread> list = Lists.newArrayList();
    // 步骤一：启动10个线程，并进入wait等待
    for (int i = 0; i < 10; i++) {
      Thread thread = new Thread(() -> {
        try {
          lock.lock();
          lockedNum.incrementAndGet();
          condition.await();
          lock.unlock();
        } catch (InterruptedException e) {
          e.printStackTrace();
        }
      });
      thread.start();
      list.add(thread);
    }

    // 步骤二：等待10个线程全部进入wait方法
    while (true) {
      if (lockedNum.get() != 10) {
        continue;
      }
      boolean allWaiting = true;
      for (Thread thread : list) {
        if (thread.getState() != Thread.State.WAITING) {
          allWaiting = false;
          break;
        }
      }
      if (allWaiting) {
        break;
      }
    }

    // 步骤三：唤醒10个线程
    lock.lock();
    condition.signalAll();
    lock.unlock();

    // 步骤四：等待10个线程全部执行完毕
    for (Thread thread : list) {
      thread.join();
    }
  }
}

4.2、基准测试Q&A

基于以上的测试我们还是有一些疑问的，不要小看这些疑问，通过这些疑问我们可以把之前的知识点全都串联起来

• Q：AQS测试中的“步骤二”，为什么在判断“等待10个线程全部进入wait方法”时，要引入lockedNum.get() != 10的判断？直接通过判断所有线程是否均为waiting方法不可以吗？
• A：如果真的删除lockedNum.get() != 10的判断，在多次并发测试时，会有较小的概率出现程序死锁的情况（作者电脑的环境是平均5万次调用会出现一次），为什么会出现死锁呢？我们追AQS源码就会发现，不管是调用lock()还是await，挂起线程使用的方法均为LockSupport.park()方法，此方法会将线程置为WAITING状态，也就是线程状态是WAITING状态时，有可能线程刚进入lock()方法，从而导致await与thread.join()的死锁
  
  
• Q：既然是这样，为什么JDK的测试没有出现死锁？
• A：我们看到JDK的加锁是通过synchronized关键字完成的，而当线程因为等待synchronized资源而阻塞时，线程状态将变为BLOCKED，而进入wait()方法后，状态才会变为WAITING
  
  
• Q：那看来只有通过引入AtomicInteger lockedNum变量才能解决死锁问题了
• A：其实解决问题的方式有很多种，我们甚至可以简单将ReentrantLock lock置为公平锁，也能解决上述死锁问题；因为当前场景发生死锁的情况是，singalAll()先于await()发生，而当所有线程都变成WAITING状态后，公平锁则确保了singalAll()一定是在所有线程都调用了await()。但因为synchronized本身是非公平锁，故如果AQS使用公平锁的话，性能偏差较大
  
  
• Q：那这样看来，AQS中的阻塞队列相对比JDK的没有优势可言啊，用法上没有JDK简洁，性能上还没人家快
• A：的确，如果真是只是单纯的使用阻塞、唤醒功能的话，还是建议使用JDK内置的方式；但AQS的优势并不在此

五、再说AQS条件队列

AQS的优势在于，其提供了丰富的api可以查询条件队列的状态；例如当我们想看一下在条件队列中等待节点的个数时，使用JDK的wait/notify时，是无法做的；AQS提供的api如下：

• boolean hasWaiters() 阻塞队列中是否有等待节点
• int getWaitQueueLength() 获取阻塞队列长度
• Collection<Thread> getWaitingThreads() 获取阻塞队列中线程对象

这些api为程序提供了更灵活的控制，条件队列对于javaer已不是黑盒；当然使用AQS的条件队列必然要引入独占锁，例如ReentrantLock，自然地我们还可以通过它查看条件队列外围的一些指标，例如：

• Interrupted 响应中断，借助独占锁，提供响应中断能力； wait/notify不提供，因为虽然wait方法响应中断，但是synchronized关键字是会一直阻塞的
• boolean tryLock() 尝试获取锁； wait/notify不提供
• int getHoldCount() 获取阻塞线程的数量
• boolean isLocked() 是否持有锁
• fair/nonFair 提供公平/非公平锁
• ...

可见整个AQS体系相比较Object的wait/notify方法是相当灵活的，提供了很多监控条件队列、阻塞队列的指标

六、致谢

这里要特别感谢一下神策数据的架构师金满仓，同时也是我私下的挚友。他功力深厚，对程序有着自己独到的见地，在整个AQS编写期间，不厌其烦地给我提供了很多理论及数据上的支持，帮我拓宽视野，再次感谢！