本篇内容介绍了“JUC中的AQS机制的使用方法”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

公司主营业务：成都做网站、网站建设、外贸营销网站建设、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。创新互联建站是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联建站推出金川免费做网站回馈大家。

为了解决原子性的问题，Java加入了锁机制，同时保证了可见性和顺序性。JDK1.5的并发包中新增了Lock接口以及相关实现类来实现锁功能，比synchronized更加灵活，开发者可根据实际的场景选择相应的实现类。

Lock特性

可重入

像synchronized和ReentrantLock都是可重入锁，可重入性表明了锁的分配机制是基于线程的分配，而不是基于方法调用的分配。

举个简单的例子，当一个线程已经获取到锁，当后续再获取同一个锁，直接获取成功。但获取锁和释放锁必须要成对出现。

可响应中断

当线程因为获取锁而进入阻塞状态，外部是可以中断该线程的，调用方通过捕获InterruptedException可以捕获中断

可设置超时时间

获取锁时，可以指定超时时间，可以通过返回值来判断是否成功获取锁

公平性

提供公平性锁和非公平锁（默认）两种选择。

•  公平锁，线程将按照他们发出请求的顺序来获取锁，不允许插队；

•  非公平锁，则允许插队：当一个线程发生获取锁的请求的时刻，如果这个锁是可用的，那这个线程将跳过所在队列里等待线程并获得锁。

考虑这么一种情况：A线程持有锁，B线程请求这个锁，因此B线程被挂起；A线程释放这个锁时，B线程将被唤醒，因此再次尝试获取锁；与此同时，C线程也请求获取这个锁，那么C线程很可能在B线程被完全唤醒之前获得、使用以及释放这个锁。

这是种双赢的局面，B获取锁的时刻（B被唤醒后才能获取锁）并没有推迟，C更早地获取了锁，并且吞吐量也获得了提高。在大多数情况下，非公平锁的性能要高于公平锁的性能。

另外，这个公平性是针对线程而言的，不能依赖此来实现业务上的公平性，应该由开发者自己控制，比如通过FIFO队列来保证公布。

读写锁

允许读锁和写锁分离，读锁与写锁互斥，但是多个读锁可以共存，适用于读频次远大于写频次的场景

丰富的API

提供了多个方法来获取锁相关的信息，可以帮助开发者监控和排查问题

•  isFair()：判断锁是否是公平锁

•  isLocked()：判断锁是否被任何线程获取了

•  isHeldByCurrentThread()：判断锁是否被当前线程获取了

•  hasQueuedThreads()：判断是否有线程在等待该锁

•  getHoldCount()：查询当前线程占有lock锁的次数

•  getQueueLength()：获取正在等待此锁的线程数

锁的使用

ReentrantLock

独占锁的实现，拥有上面列举的除读写锁之外的所有特性，使用比较简单

class X {     // 创建独占锁实例     private final ReentrantLock lock = new ReentrantLock();     // ...     public void m() {       lock.lock();  // block until condition holds       try {         // ... method body       } finally {         // 必须要释放锁，unlock与lock成对出现         lock.unlock()       }     }   }

ReentrantReadWriteLock

读写锁的实现，拥有上面列举的所有特性。并且写锁可降级为读锁，反之不行。

class CachedData {     Object data;     volatile boolean cacheValid;     final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();     void processCachedData() {       rwl.readLock().lock();       if (!cacheValid) {         // Must release read lock before acquiring write lock         rwl.readLock().unlock();         rwl.writeLock().lock();         try {           // Recheck state because another thread might have           // acquired write lock and changed state before we did.           if (!cacheValid) {            data = ...             cacheValid = true;           }          // Downgrade by acquiring read lock before releasing write lock           rwl.readLock().lock();         } finally {           rwl.writeLock().unlock(); // Unlock write, still hold read         }       }       try {         use(data);       } finally {         rwl.readLock().unlock();       }     }   }

StampedLock

StampedLock也是一种读写锁，提供两种读模式：乐观读和悲观读。乐观读允许读的过程中也可以获取写锁后写入！这样一来，我们读的数据就可能不一致，所以，需要一点额外的代码来判断读的过程中是否有写入。

乐观锁的意思就是乐观地估计读的过程中大概率不会有写入，因此被称为乐观锁。反过来，悲观锁则是读的过程中拒绝有写入，也就是写入必须等待。显然乐观锁的并发效率更高，但一旦有小概率的写入导致读取的数据不一致，需要能检测出来，再读一遍就行。

public class Point {      private final StampedLock stampedLock = new StampedLock();      private double x;      private double y;      public void move(double deltaX, double deltaY) {          long stamp = stampedLock.writeLock(); // 获取写锁          try {              x += deltaX;              y += deltaY;          } finally {              stampedLock.unlockWrite(stamp); // 释放写锁          }      }      public double distanceFromOrigin() {          long stamp = stampedLock.tryOptimisticRead(); // 获得一个乐观读锁          // 注意下面两行代码不是原子操作          // 假设x,y = (100,200)          double currentX = x;          // 此处已读取到x=100，但x,y可能被写线程修改为(300,400)          double currentY = y;          // 此处已读取到y，如果没有写入，读取是正确的(100,200)          // 如果有写入，读取是错误的(100,400)          if (!stampedLock.validate(stamp)) { // 检查乐观读锁后是否有其他写锁发生              stamp = stampedLock.readLock(); // 获取一个悲观读锁              try {                  currentX = x;                  currentY = y;              } finally {                  stampedLock.unlockRead(stamp); // 释放悲观读锁              }          }          return Math.sqrt(currentX * currentX + currentY * currentY);      }  }

Condition

Condition成为条件队列或条件变量，为一个线程挂起执行（等待）提供了一种方法，直到另一线程通知某些状态条件现在可能为真为止。由于对该共享状态信息的访问发生在不同的线程中，因此必须由互斥锁对其其进行保护。

await方法：必须在获取锁之后的调用，表示释放当前锁，阻塞当前线程；等待其他线程调用锁的signal或signalAll方法，线程唤醒重新获取锁。

Lock配合Condition，可以实现synchronized 与 对象（wait，notify）同样的效果，来进行线程间基于共享变量的通信。但优势在于同一个锁可以由多个条件队列，当某个条件满足时，只需要唤醒对应的条件队列即可，避免无效的竞争。

// 此类实现类似阻塞队列（ArrayBlockingQueue）  class BoundedBuffer {   final Lock lock = new ReentrantLock();   final Condition notFull  = lock.newCondition();    final Condition notEmpty = lock.newCondition();    final Object[] items = new Object[100];   int putptr, takeptr, count;   public void put(Object x) throws InterruptedException {     lock.lock();     try {       while (count == items.length)         notFull.await();       items[putptr] = x;       if (++putptr == items.length) putptr = 0;       ++count;       notEmpty.signal();     } finally {       lock.unlock();     }   }   public Object take() throws InterruptedException {     lock.lock();     try {       while (count == 0)         notEmpty.await();       Object x = items[takeptr];      if (++takeptr == items.length) takeptr = 0;       --count;       notFull.signal();       return x;     } finally {       lock.unlock();     }   }  }

BlockingQueue

BlockingQueue阻塞队列实际上是一个生产者/消费者模型，当队列长度大于指定的最大值，生产线程就会被阻塞；反之当队列元素为空时，消费线程就会被阻塞；同时当消费成功时，就会唤醒阻塞的生产者线程；生产成功就会唤醒消费者线程；

内部使用就是ReentrantLock + Condition来实现的，可以参照上面的示例。

CountDownLatch

称之为倒计时器锁，初始化指定数值，调用countDown可以对数值减一，当数值减为0时，就会唤醒所有因为调用await方法而阻塞的线程。

可以达到一组线程等待另外一组线程都完成任务的效果。

class Driver { // ...     void main() throws InterruptedException {       CountDownLatch startSignal = new CountDownLatch(1);       CountDownLatch doneSignal = new CountDownLatch(N);       for (int i = 0; i < N; ++i) // create and start threads         new Thread(new Worker(startSignal, doneSignal)).start();       doSomethingElse();            // don't let run yet       startSignal.countDown();      // let all threads proceed       doSomethingElse();       doneSignal.await();           // wait for all to finish     }  }  class Worker implements Runnable {     private final CountDownLatch startSignal;     private final CountDownLatch doneSignal;     Worker(CountDownLatch startSignal, CountDownLatch doneSignal) {       this.startSignal = startSignal;       this.doneSignal = doneSignal;     }     public void run() {       try {         startSignal.await();         doWork();         doneSignal.countDown();       } catch (InterruptedException ex) {} // return;     }     void doWork() { ... }  }

CyclicBarrier

称之为同步屏障，它使得一组线程互相等待，直到到达某个公共屏障点。

初始化指定数值，调用await方法会使得线程阻塞，直到指定数量的线程都调用await方法时，所有被阻塞的线程会被唤醒，继续执行。

与CountDownLatch的区别是，CountDownLatch是一组线程等待另外一组线程，而CyclicBarrier是一组线程之间相互等待。

Semaphore

称之为信号量，与互斥锁ReentrantLock用法类似，区别就是Semaphore共享的资源是多个，允许多个线程同时竞争成功。

AQS原理

AQS 是 AbstractQueuedSynchronizer的缩写，中文 抽象队列同步器，是构建各类锁和同步器的基础实现。内部维护了共享变量state （int类型） 和 双向队列 （包含头指针和尾指针）

并发问题解决

原子性

Unsafe.compareAndSwapXXX 实现CAS更改 state 和 队列指针 内部依赖CPU提供的原子指令

可见性与有序性

volatile 修饰 state 与 队列指针 （prev/next/head/tail）

线程阻塞与唤醒

Unsafe.park Unsafe.parkNanos Unsafe.unpark

Unsafe类是在sun.misc包下，不属于Java标准。提供了内存管理、对象实例化、数组操作、CAS操作、线程挂起与恢复等功能，Unsafe类提升了Java运行效率，增强了Java语言底层的操作能力。很多Java的基础类库，包括一些被广泛使用的高性能开发库都是基于Unsafe类开发的，比如Netty、Cassandra、Hadoop、Kafka等

AQS内部有两种模式：独占模式和共享模式

AQS 的设计是基于模板方法的，使用者需要继承 AQS 并重写指定的方法。不同的自定义同步器争用共享资源的方式不同，比如可重入、公平性等都是子类来实现。

自定义同步器在实现时只需要实现共享资源state的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等），由AQS内部处理。

独占模式

•  只有一个线程都能够获取到锁

•  锁释放后需要唤醒后继节点

AQS提供的独占模式相关的方法

// 获取独占锁（线程阻塞直至获取成功）  public final void acquire(int)  // 获取独占锁，可被中断  public final void acquireInterruptibly(int)   // 获取独占锁，可被中断 和 指定超时时间  public final boolean tryAcquireNanos(int, long)   // 释放独占锁（释放锁后，将等待队列中第一个等待节点唤醒 ）  public final boolean release(int)

AQS子类需要实现的独占模式相关的方法

// 尝试获取独占锁  protected boolean tryAcquire(int)  // 尝试释放独占锁  protected boolean tryRelease(int)

获取独占锁的流程

•  调用子类tryAcquire尝试获取锁，获取成功，直接返回

•  通过自旋CAS将当前线程封装成节点加入队列末尾

•  循环等待或尝试tryAcquire获取锁

•   判断前置节点如果为head，则尝试获取锁

•   根据队列中节点状态，决定是否需要阻塞当前线程

•   tryAcquire获取锁成功后，将当前节点设置为head 并 返回

•  如果当前线程中断或超时，则执行cancelAcquire

•   将当前节点状态置为CANCELED，并从队列删除

•   如果前置节点为Head，则将后置节点唤醒

释放独占锁的流程

共享模式

•  多个线程都能够获取到锁

•  锁释放后需要唤醒后继节点

•  锁获取后如果还有资源需要唤醒后继共享节点

AQS提供的共享模式相关的方法

// 获取共享锁（线程阻塞直至获取成功）  public final void acquireShared(int)   // 获取共享锁，可被中断  public final acquireSharedInterruptibly(int)  // 获取共享锁，可被中断 和 指定超时时间  public final tryAcquireSharedNanos(int, long)    // 获取共享锁  public final boolean releaseShared(int)

AQS子类需要实现的共享模式相关的方法

// 尝试获取共享锁  protected int tryAcquireShared(int)  // 尝试释放共享锁  protected boolean tryReleaseShared(int)

获取共享锁的流程

1.调用子类tryAcquireShared尝试获取锁，获取成功，直接返回

2.通过自旋CAS将当前线程封装成节点加入队列末尾

3.循环等待或尝试tryAcquireShared获取锁

•  判断前置节点如果为head，则尝试获取锁

•  根据队列中节点状态，决定是否需要阻塞当前线程

•  tryAcquireShared获取锁成功后，将当前节点设置为head

•   如果资源有剩余或者原先的head节点状态为SIGNAL/PROPAGATE，则调用doReleaseShared

•   如果当前head节点状态为SIGNAL，唤醒后继节点

•   如果当前head节点状态为ZERO，将head节点状态置为PROPAGATE

•  如果当前线程中断或超时，则执行cancelAcquire

•   将当前节点状态置为CANCELED，并从队列删除

•   如果前置节点为Head，则将后置节点唤醒

释放共享锁的流程

等待队列中节点的状态变化

ReentrantLock示例

tryAcquire逻辑

tryRelease逻辑

“JUC中的AQS机制的使用方法”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！

新闻标题：JUC中的AQS机制的使用方法
转载源于：http://azwzsj.com/article/ghejjg.html