java中锁那个英语单词怎么读 java 的锁

Java中的锁

• 锁
• 锁的分类

• 1. 乐观锁 VS 悲观锁

• 1.1 乐观锁和悲观锁是一种广义上的概念，体现了看待线程同步的不同角度。
• 1.2 根据概念对比：
• 1.3 调用方式：
• 1.4 CAS算法（compare and swap）

• 2、自旋锁 VS 适应性自旋锁
• 3、无锁 VS 偏向锁 VS 轻量级锁 VS 重量级锁
• 4、公平锁 VS 非公平锁
• 5、可重入锁 VS 非可重入锁
• 6、独享锁 VS 共享锁
• 7、AQS 了解

• 7.1、原理概述
• 7.2、AQS 对资源的共享⽅式
• 7.3、AQS 底层使用了模板模式
• 7.4、AQS 组件总结
• 7.5、CountDownLatch使用场景

• 参考

锁

使用锁是为了解决并发产生的数据脏读，数据不一致的问题。

锁的分类

按照锁的特性来分类，可将Java中的锁分类如下：

1. 乐观锁 VS 悲观锁

1.1 乐观锁和悲观锁是一种广义上的概念，体现了看待线程同步的不同角度。

• 悲观锁：对于同一个数据的并发操作，悲观锁认为自己在使用数据时一定会有其它线程来修改数据，因此在获取数据的时候会先加锁，确保数据不会被别的线程修改。Java中，synchronized关键字和Lock的实现类都是悲观锁。
• 乐观锁：对于同一个数据的并发操作，乐观锁认为自己在使用数据时不会由别的线程来修改数据，所以不会添加锁，只是在更新数据的时候去判断之前有没有别的线程更新了这个数据。如果数据未被更新，当前线程将自己修改的数据写入。如果数据已被其它线程更新，则根据不同的实现方式执行不同的操作（报异常或重试）。

1.2 根据概念对比：

• 悲观锁适合写操作多的场景，先加锁保证数据的准确
• 乐观锁适合读操作多的场景，不加锁保证读操作的性能提升

1.3 调用方式：

• 悲观锁基本都是显式的加锁后操作同步资源
• 乐观锁直接操作同步资源

// ------------------------- 悲观锁的调用方式 -------------------------
// synchronized
public synchronized void testMethod() {
    // 操作同步资源
}
// ReentrantLock
private ReentrantLock lock = new ReentrantLock(); // 需要保证多个线程使用的是同一个锁
public void modifyPublicResources() {
    lock.lock();
    // 操作同步资源
    lock.unlock();
}

// ------------------------- 乐观锁的调用方式 -------------------------
private AtomicInteger atomicInteger = new AtomicInteger();  // 需要保证多个线程使用的是同一个AtomicInteger
atomicInteger.incrementAndGet(); //执行自增1

为什么乐观锁能够做到不锁定同步资源也可以正确的实现线程同步呢？下面介绍乐观锁的主要实现方式 “CAS”。

1.4 CAS算法（compare and swap）

CAS是一种无锁算法，在不使用锁（没有线程被阻塞）的情况下实现多线程之间的变量同步。

• 乐观锁的主要实现方式
• CAS算法涉及到三个操作数：
  1、需要读写的内存值 V
  2、进行比较的值 A
  3、要写入的新值 B
  当且仅当内存位置 V 的值等于预期值 A 时，CAS通过原子方式用新值 B 来更新 V 的值（“比较 + 更新” 整体是一个原子操作），否则不会执行任何操作。一般情况下，“更新” 是一个不断重试的操作。
• java.util.concurrent包中的原子类就是通过CAS来实现了乐观锁，下面是原子类AutomicInteger的源码：

public class AtomicInteger extends Number implements java.io.Serializable {
	private static final long serialVersionUID = 6214790243416807050L;
	// setup to Unsafe.compareAndSwapInt for updates
	private static final Unsafe unsafe = Unsafe.getUnsafe();
	private static final long valueOffset;
	
	static {
		try{
			valueOffset = unsafe.objectFieldOffset
				(AtomicInteger.class.getDeclaredField(name: "value"));
		} catch (Exception ex) {throw new Error(ex);}
	}
	private volatile int value;
}

根据定义：
1、unsafe：获取并操作内存的数据。
2、valueOffset：存储value在AtomicInteger中的偏移量。
3、value：存储AtomicInteger的int值，该属性需要借助volatile关键字保证其在线程间是可见的。

接下来，我们查看AtomicInteger的自增函数incrementAndGet()的源码时，发现自增函数底层调用的是unsafe.getAndAddInt()。但是由于JDK本身只有Unsafe.class，只通过class文件中的参数名，并不能很好的了解方法的作用，所以我们通过OpenJDK 8 来查看Unsafe的源码：：

// ------------------------- JDK 8 -------------------------
// AtomicInteger 自增方法
public final int incrementAndGet() {
  return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}

// Unsafe.class
public final int getAndAddInt(Object var1, long var2, int var4) {
  int var5;
  do {
      var5 = this.getIntVolatile(var1, var2);
  } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
  return var5;
}

// ------------------------- OpenJDK 8 -------------------------
// Unsafe.java
public final int getAndAddInt(Object o, long offset, int delta) {
   int v;
   do {
       v = getIntVolatile(o, offset);
   } while (!compareAndSwapInt(o, offset, v, v + delta));
   return v;
}

根据OpenJDK8的源码可以看出，getAndAddInt()循环获取给定对象 o 中的偏移量处的值 v ，然后判断内存值是否等于 v 。如果相等则将内存值设置为 v + delta ，否则返回false，继续循环进行重试，直到设置成功才退出循环，并且将旧值返回。整个 “比较 + 更新” 操作封装在compareAndSwapInt()中，在JNI中式借助于一个CPU指令完成的，属于原子操作，可以保证多个线程都能够看到同一个变量的修改值。
后续JDK通过CPU的cmpxchg指令，去比较寄存器中的 A 和内存中的 V。如果相等，就把要写入的新值 B 存入内存中。如果不相等，就将内存值 V 赋值给寄存器中的值 A 。然后通过Java代码中的while循环再次调用cmpxchg指令进行重试，直到设置成功为止。（这不就是 “CAS + 自旋” 的乐观锁机制么）

• CAS 的问题：
  1、ABA 问题： CAS需要在操作值的时候检查内存值是否发生变化，没有发生变化才会更新内存值。但是如果内存值原来是A，后来变成了B，然后又变成了A，那么CAS进行检查时会发现值没有发生变化，但是实际上是有变化的。ABA问题的解决思路就是在变量前面添加版本号，每次变量更新的时候都把版本号加一，这样变化过程就从“A－B－A”变成了“1A－2B－3A”。（JDK从1.5开始提供了AtomicStampedReference类来解决ABA问题，具体操作封装在compareAndSet()中。compareAndSet()首先检查当前引用和当前标志与预期引用和预期标志是否相等，如果都相等，则以原子方式将引用值和标志的值设置为给定的更新值。）
  2、循环时间长开销大： CAS操作如果长时间不成功，会导致其一直自旋，给CPU带来非常大的开销。
  3、只能保证一个共享变量的原子操作： 对一个共享变量执行操作时，CAS能够保证原子操作，但是对多个共享变量操作时，CAS是无法保证操作的原子性的。（Java从1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，可以把多个变量放在一个对象里来进行CAS操作。）

2、自旋锁 VS 适应性自旋锁

• 自旋即自我旋转自我循环，通过自己不断的循环达到目标，区别于其它锁，竞争不到锁就进入阻塞。
• 阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态转换需要耗费处理器时间。如果同步代码块中的内容过于简单，状态转换消耗的时间有可能比用户代码执行的时间还要长，为了这一小段时间去切换线程，线程挂起和恢复的时间花费会让系统得不偿失。因此如果物理机有多个处理器，能够让两个或以上的线程同时并行执行，可以让后面请求锁的线程不放弃CPU的执行时间，等待持有锁的线程释放锁，从而避免线程切换的花销。 而这中间为了让线程 “等一下” ，就需要让当前线程进行自旋，如果在自旋完成后前面锁定同步资源的线程已经释放了锁，那么当前线程就可以不必阻塞等待而是直接获取同步资源，从而避免切换资源的开销。这就是自旋锁。

• 自旋锁本身是有缺点的，它不能代替阻塞。虽然它通过自旋等待避免了线程切换的开销，但它要占用处理器时间。如果锁被占用的时间很短，自旋等待的效果就会非常好。反之，如果锁占用的时间很长，那么自旋的线程只会白白浪费处理器资源。
• 所以，自旋等待的时间必须有一定的限度，如果自旋超过了限定次数（默认10次，可使用 -XX:PreBlockSpin 来更改）没有成功获取到锁，就应当挂起线程。
• 自旋锁的实现原理同样是CAS，AtomicIntefer中调用unsafe进行自增操作的源码中的do-while循环就是一个自选操作，如果修改数值失败则通过循环来执行自旋，直至修改成功。

// Unsafe.class
    public final int getAndAddInt(Object var1, long var2, int var4) {
        int var5;
        do {
            var5 = this.getIntVolatile(var1, var2);
        } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

        return var5;
    }

• 自旋锁在JDK1.4.2中引入，使用-XX:+UseSpinning来开启。JDK 6中变为默认开启，并且引入了自适应的自旋锁（适应性自旋锁）。
• 自适应意味着自旋的时间（次数）不再固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也是很有可能再次成功，进而它将允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功获得过，那在以后尝试获取这个锁时将可能省略掉自旋过程，直接阻塞线程，避免浪费处理器资源。

3、无锁 VS 偏向锁 VS 轻量级锁 VS 重量级锁

• 这四种锁是指锁的状态，专门针对synchronized的。
  首先为什么synchronized能实现线程同步？
  回答这个问题前需要了解两个概念：
  1)、Java对象头：synchronized是悲观锁，在操作同步资源之前需要给同步资源先加锁，这把锁就是存在Java对象头里的，而Java对象头又是什么呢？
  以Hotspot虚拟机为例，Hotspot的对象头主要包括两部分数据：Mark Word（标记字段）、Klass Pointer（类型指针）。
  Mark Word： 默认存储对象的HashCode，分代年龄和锁标志位信息。这些信息都是与对象自身定义无关的数据，所以Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据。它会根据对象的状态复用自己的存储空间，也就是说在运行期间Mark Word里存储的数据会随着锁标志位的变化而变化。
  Klass Point： 对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。
  2)、Monitor: Monitor可以理解为一个同步工具或一种同步机制，通常被描述为一个对象。每一个Java对象就有一把看不见的锁，称为内部锁或者Monitor锁。Monitor是线程私有的数据结构，每一个线程都有一个可用monitor record列表，同时还有一个全局的可用列表。每一个被锁住的对象都会和一个monitor关联，同时monitor中有一个Owner字段存放拥有该锁的线程的唯一标识，表示该锁被这个线程占用。
  3、那么synchronized如何实现线程同步：sychronized通过Mointor来实现线程同步，Monitor是依赖于底层的操作系统的Mutex Lock（互斥锁）来实现的线程同步。如同在自旋锁中提到的“阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态转换需要耗费处理器时间。如果同步代码块中的内容过于简单，状态转换消耗的时间有可能比用户代码执行的时间还要长”。这种方式就是synchronized最初实现同步的方式，这就是JDK 6之前synchronized效率低的原因。这种依赖于操作系统Mutex Lock所实现的锁我们称之为“重量级锁”，JDK 6中为了减少获得锁和释放锁带来的性能消耗，引入了“偏向锁”和“轻量级锁”。
  4、目前锁一共有4种状态，级别从低到高依次是：无锁、偏向锁、轻量级锁和重量级锁。锁状态只能升级不能降级。
  下面是四种锁状态对应的Mark Word内容



• 无锁：
  1、没有对资源进行锁定, 所有线程都能同时访问并修改资源, 但是同时只有一个线程能修改成功。
  2、无锁的特点是修改的操作时在循环内执行的, 线程会不断的尝试修改直到成功并退出。如果有多个线程同时修改共享资源, 那同时只有一个线程能成功, 其他线程修改失败, 失败后不断重试直到成功。
• 偏向锁：
  1、偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁，降低获取锁的代价。
  2、在大多数情况下，锁总是由同一线程多次获得，不存在多线程竞争，所以出现了偏向锁。其目标就是在只有一个线程执行同步代码块时能够提高性能。
  3、当一个线程访问同步代码块并获取锁时，会在Mark Word里存储锁偏向的线程ID。在线程进入和退出同步块时不再通过CAS操作来加锁和解锁，而是检测Mark Word里是否存储着指向当前线程的偏向锁。引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令即可。
  4、偏向锁不会主动释放锁, 只有遇到其他线程尝试竞争偏向锁时, 持有偏向锁的线程才会释放锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态。撤销偏向锁后恢复到无锁（标志位为“01”）或轻量级锁（标志位为“00”）的状态。
• 轻量级锁：
  1、当锁是偏向锁的时候，被另外的线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，从而提高性能。
  2、在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，然后拷贝对象头中的Mark Word复制到锁记录中。
  拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock Record里的owner指针指向对象的Mark Word。
  如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，表示此对象处于轻量级锁定状态。
  如果轻量级锁的更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行，否则说明多个线程竞争锁。
  若当前只有一个等待线程，则该线程通过自旋进行等待。但是当自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁升级为重量级锁。
• 重量级锁：升级为重量级锁时，锁标志的状态值变为“10”，此时Mark Word中存储的是指向重量级锁的指针，此时等待锁的线程都会进入阻塞状态。

综上，偏向锁通过对比Mark Word解决加锁问题，避免执行CAS操作。而轻量级锁是通过用CAS操作和自旋来解决加锁问题，避免线程阻塞和唤醒而影响问题。重量级锁是将除了拥有锁的线程意外的线程都阻塞。

4、公平锁 VS 非公平锁

• 公平锁：如下图所示，假设有一口水井，有管理员看守，管理员有一把锁，只有拿到锁的人才能够打水，打完水要把锁还给管理员。每个过来打水的人都要管理员的允许并拿到锁之后才能去打水，如果前面有人正在打水，那么这个想要打水的人就必须排队。管理员会查看下一个要去打水的人是不是队伍里排最前面的人，如果是的话，才会给你锁让你去打水；如果你不是排第一的人，就必须去队尾排队，这就是公平锁。



• 非公平锁：对于非公平锁，管理员对打水的人没有要求。即使等待队伍里有排队等待的人，但如果在上一个人刚打完水把锁还给管理员而且管理员还没有允许等待队伍里下一个人去打水时，刚好来了一个插队的人，这个插队的人是可以直接从管理员那里拿到锁去打水，不需要排队，原本排队等待的人只能继续等待。如下图所示：



• 下面通过ReentrantLock的源码看下公平锁和非公平锁：



• 根据代码可知，ReentrantLock里面有一个内部类Sync，Sync继承AQS（AbstractQueuedSynchronizer），添加锁和释放锁的大部分操作实际上都是在Sync中实现的。它有公平锁FairSync和非公平锁NonfairSync两个子类。ReentrantLock默认使用非公平锁，也可以通过构造器来显示的指定使用公平锁。

下面是公平锁与非公平锁的加锁方法的源码：

通过上图中的源代码对比，我们可以明显的看出公平锁与非公平锁的lock()方法唯一的区别就在于公平锁在获取同步状态时多了一个限制条件：hasQueuedPredecessors()。

public final boolean hasQueuedPredecessors() {
        Node h, s;
        if ((h = head) != null) {
            if ((s = h.next) == null || s.waitStatus > 0) {
                s = null; // traverse in case of concurrent cancellation
                for (Node p = tail; p != h && p != null; p = p.prev) {
                    if (p.waitStatus <= 0)
                        s = p;
                }
            }
            if (s != null && s.thread != Thread.currentThread())
                return true;
        }
        return false;
    }

进入hasQueuedPredecessors()，可以看到该方法主要做一件事情：主要是判断当前线程是否位于同步队列中的第一个。如果是则返回true，否则返回false。

综上，公平锁就是通过同步队列来实现多个线程按照申请锁的顺序来获取锁，从而实现公平的特性。非公平锁加锁时不考虑排队等待问题，直接尝试获取锁，所以存在后申请却先获得锁的情况。

5、可重入锁 VS 非可重入锁

可重入锁又名递归锁，是指同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁（前提是锁对象是同一个对象或者class），不会因为之前已经获取过还没释放锁而阻塞。Java中ReentrantLock和synchronized都是可重入锁，可重入锁的一个优点是可一定程度避免死锁。下面用示例代码来进行分析：

public class Widget {
    public synchronized void doSomething() {
        System.out.println("方法1执行...");
        doOthers();
    }

    public synchronized void doOthers() {
        System.out.println("方法2执行...");
    }
}

上面的代码中，类中的两个方法都被synchronized修饰，doSomething()方法调用doOthers()方法。由于synchronized是可重入锁，所以同一个线程在调用doOthers()时可以直接获得当前对象的锁，进入doOthers()进行操作。相反如果是一个不可重入锁，那么当前线程在调用doOthers()方法之前需要将执行doSomething()时获取当前对象的锁释放掉，实际上该对象锁已被当前线程锁持有，且无法释放，此时就会出现死锁。

那为什么可重入锁就可以在嵌套调用时自动获得锁呢？还是通过打水的例子和源码来分析下：

• 可重入锁：还是打水的例子，有多个人在排队打水，此时管理员允许锁和同一个人的多个水桶绑定。这个人用多个水桶打水时，第一个水桶和锁绑定并打完水之后，第二个水桶也可以直接和锁绑定并开始打水，所有的水桶都打完水之后打水人才会将锁还给管理员。这个人的所有打水流程都能够成功执行，后续等待的人也能够打到水。这就是可重入锁。
• 非可重入锁：如果是非可重入锁的话，此时管理员只允许锁和同一个人的一个水桶绑定。第一个水桶和锁绑定打完水之后并不会释放锁，导致第二个水桶不能和锁绑定也无法打水。当前线程出现死锁，整个等待队列中的所有线程都无法被唤醒。

之前说过ReentrantLock和synchronized都是重入锁，那么通过重入锁ReentrantLock以及非可重入锁NonReentrantLock的源码来对比分析一下为什么非可重入锁在重复调用同步资源时会出现死锁。

首先ReentrantLock和NonReentrantLock都继承父类AQS，其父类AQS中维护了一个同步状态status来计数重入次数，status初始值为0。

当线程尝试获取锁时，可重入锁先尝试获取并更新status值，如果status == 0表示没有其他线程在执行同步代码，则把status置为1，当前线程开始执行。如果status != 0，则判断当前线程是否是获取到这个锁的线程，如果是的话执行status+1，且当前线程可以再次获取锁。而非可重入锁是直接去获取并尝试更新当前status的值，如果status != 0的话会导致其获取锁失败，当前线程阻塞。

释放锁时，可重入锁同样先获取当前status的值，在当前线程是持有锁的线程的前提下。如果status-1 == 0，则表示当前线程所有重复获取锁的操作都已经执行完毕，然后该线程才会真正释放锁。而非可重入锁则是在确定当前线程是持有锁的线程之后，直接将status置为0，将锁释放。

6、独享锁 VS 共享锁

独享锁和共享锁同样是一种概念。大致先介绍一下具体的概念，然后通过ReentrantLock和ReentrantReadWriteLock的源码来介绍独享锁和共享锁。

独享锁也叫排他锁，是指该锁一次只能被一个线程所持有。如果线程T对数据A加上排它锁后，则其他线程不能再对A加任何类型的锁。**获得排它锁的线程即能读数据又能修改数据。**JDK中的synchronized和JUC中Lock的实现类就是互斥锁。

共享锁是指该锁可被多个线程所持有。如果线程T对数据A加上共享锁后，则其他线程只能对A再加共享锁，不能加排它锁。获得共享锁的线程只能读数据，不能修改数据。

独享锁与共享锁也是通过AQS来实现的，通过实现不同的方法，来实现独享或者共享。

下图为ReentrantReadWriteLock的部分源码：

可以看到ReentrantReadWriteLock有两把锁：ReadLock和WriteLock，由词知意，一个读锁一个写锁，合称“读写锁”。再进一步观察可以发现ReadLock和WriteLock是靠内部类Sync实现的锁。Sync是AQS的一个子类，这种结构在CountDownLatch、ReentrantLock、Semaphore里面也都存在。

在ReentrantReadWriteLock里面，读锁和写锁的锁主体都是Sync，但读锁和写锁的加锁方式不一样。读锁是共享锁，写锁是独享锁。读锁的共享锁可保证并发读非常高效，而读写、写读、写写的过程互斥，因为读锁和写锁是分离的。所以ReentrantReadWriteLock的并发性相比一般的互斥锁有了很大提升。

那读锁和写锁的具体加锁方式有什么区别呢？在了解源码之前我们需要回顾一下其他知识。 在最开始提及AQS的时候我们也提到了state字段（int类型，32位），该字段用来描述有多少线程获持有锁。

在独享锁中这个值通常是0或者1（如果是重入锁的话state值就是重入的次数），在共享锁中state就是持有锁的数量。但是在ReentrantReadWriteLock中有读、写两把锁，所以需要在一个整型变量state上分别描述读锁和写锁的数量（或者也可以叫状态）。于是将state变量“按位切割”切分成了两个部分，高16位表示读锁状态（读锁个数），低16位表示写锁状态（写锁个数）。如下图所示：

了解了概念之后我们再来看代码，先看写锁的加锁源码：

protected final boolean tryAcquire(int acquires) {
	Thread current = Thread.currentThread();
	int c = getState(); // 取到当前锁的个数
	int w = exclusiveCount(c); // 取写锁的个数w
	if (c != 0) { // 如果已经有线程持有了锁(c!=0)
    // (Note: if c != 0 and w == 0 then shared count != 0)
		if (w == 0 || current != getExclusiveOwnerThread()) // 如果写线程数（w）为0（换言之存在读锁） 或者持有锁的线程不是当前线程就返回失败
			return false;
		if (w + exclusiveCount(acquires) > MAX_COUNT)    // 如果写入锁的数量大于最大数（65535，2的16次方-1）就抛出一个Error。
      throw new Error("Maximum lock count exceeded");
		// Reentrant acquire
    setState(c + acquires);
    return true;
  }
  if (writerShouldBlock() || !compareAndSetState(c, c + acquires)) // 如果当且写线程数为0，并且当前线程需要阻塞那么就返回失败；或者如果通过CAS增加写线程数失败也返回失败。
		return false;
	setExclusiveOwnerThread(current); // 如果c=0，w=0或者c>0，w>0（重入），则设置当前线程或锁的拥有者
	return true;
}

tryAcquire()除了重入条件（当前线程为获取了写锁的线程）之外，增加了一个读锁是否存在的判断。如果存在读锁，则写锁不能被获取，原因在于：必须确保写锁的操作对读锁可见，如果允许读锁在已被获取的情况下对写锁的获取，那么正在运行的其他读线程就无法感知到当前写线程的操作。
因此，只有等待其他读线程都释放了读锁，写锁才能被当前线程获取，而写锁一旦被获取，则其他读写线程的后续访问均被阻塞。写锁的释放与ReentrantLock的释放过程基本类似，每次释放均减少写状态，当写状态为0时表示写锁已被释放，然后等待的读写线程才能够继续访问读写锁，同时前次写线程的修改对后续的读写线程可见。

接着是读锁的代码：

protected final int tryAcquireShared(int unused) {
    Thread current = Thread.currentThread();
    int c = getState();
    if (exclusiveCount(c) != 0 &&
        getExclusiveOwnerThread() != current)
        return -1;                                   // 如果其他线程已经获取了写锁，则当前线程获取读锁失败，进入等待状态
    int r = sharedCount(c);
    if (!readerShouldBlock() &&
        r < MAX_COUNT &&
        compareAndSetState(c, c + SHARED_UNIT)) {
        if (r == 0) {
            firstReader = current;
            firstReaderHoldCount = 1;
        } else if (firstReader == current) {
            firstReaderHoldCount++;
        } else {
            HoldCounter rh = cachedHoldCounter;
            if (rh == null || rh.tid != getThreadId(current))
                cachedHoldCounter = rh = readHolds.get();
            else if (rh.count == 0)
                readHolds.set(rh);
            rh.count++;
        }
        return 1;
    }
    return fullTryAcquireShared(current);
}

可以看到在tryAcquireShared(int unused)方法中，如果其他线程已经获取了写锁，则当前线程获取读锁失败，进入等待状态。如果当前线程获取了写锁或者写锁未被获取，则当前线程（线程安全，依靠CAS保证）增加读状态，成功获取读锁。读锁的每次释放（线程安全的，可能有多个读线程同时释放读锁）均减少读状态，减少的值是“1<<16”。所以读写锁才能实现读读的过程共享，而读写、写读、写写的过程互斥。

此时，我们再回头看一下上面互斥锁ReentrantLock中公平锁和非公平锁的加锁源码就可以发现，ReentrantLock虽然有公平锁和非公平锁两种，但是它们添加的都是独享锁。根据源码所示，当某一个线程调用lock方法获取锁时，如果同步资源没有被其他线程锁住，那么当前线程在使用CAS更新state成功后就会成功抢占该资源。而如果公共资源被占用且不是被 当前线程（公平锁和非公平锁中有句判断current == getExclusiveOwerThread()） 占用，那么就会加锁失败。所以可以确定ReentrantLock无论读操作还是写操作，添加的锁都是都是独享锁。

7、AQS 了解

上面提到的好几种锁的父类就是AQS，所以这里把AQS也大概介绍下AQS的全称为（AbstractQueuedSynchronizer），这个类在 java.util.concurrent.locks 包下⾯。
AQS是一个用来构建锁和同步器的框架，使用AQS能简单高效地构造出应用广泛的大量同步器，⽐如我们提到的 ReentrantLock，ReentrantReadWriteLock 等皆是基于 AQS 的。

7.1、原理概述

AQS 核⼼思想是，如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的⼯作线程，并且将共享资源设置为锁定状态。如果被请求的共享资源被占⽤，那么就需要⼀套线程阻塞等待以及被唤醒时锁分配的机制，这个机制 AQS 是⽤ CLH 队列锁实现的，即将暂时获取不到锁的线程加⼊到队列中。

CLH(Craig,Landin,and Hagersten)队列是⼀个虚拟的双向队列（虚拟的双向队列即不存在
队列实例，仅存在结点之间的关联关系）。AQS 是将每条请求共享资源的线程封装成⼀个CLH 锁队列的⼀个结点（Node）来实现锁的分配。

原理图如下：

AQS 使⽤⼀个 int 成员变量status来表示同步状态，通过内置的 FIFO 队列来完成获取资源线程的排队⼯作。AQS 使⽤ CAS 对该同步状态进⾏原⼦操作实现对其值的修改。

private volatile int state;//共享变量，使⽤volatile修饰保证线程可⻅性

状态信息通过 protected 类型的 getState，setState，compareAndSetState 进⾏操作

//返回同步状态的当前值
protected final int getState() {
return state;
}
// 设置同步状态的值
protected final void setState(int newState) {
state = newState;
}
//原⼦地（CAS操作）将同步状态值设置为给定值update如果当前同步状态的值等于expect（期望值）
protected final boolean compareAndSetState(int expect, int update) {
return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

7.2、AQS 对资源的共享⽅式

AQS 定义两种资源共享⽅式

• Exclusive（独占）：只有⼀个线程能执⾏，如 ReentrantLock 。⼜可分为公平锁和⾮公平锁。
• Share（共享）：多个线程可同时执⾏，如CountDownLatch 、 Semaphore 、 CountDownLatch 、 CyclicBarrier 、 ReadWriteLock 等。

不同的⾃定义同步器争⽤共享资源的⽅式也不同。⾃定义同步器在实现时只需要实现共享资源state 的获取与释放⽅式即可，⾄于具体线程等待队列的维护（如获取资源失败⼊队/唤醒出队等），AQS 已经在顶层实现好了。

7.3、AQS 底层使用了模板模式

同步器的设计是基于模板⽅法模式的，如果需要⾃定义同步器⼀般的⽅式是这样（模板设计模式很经典的⼀个应⽤）：

1. 使⽤者继承 AbstractQueuedSynchronizer 并重写指定的⽅法。（这些重写⽅法很简单，⽆⾮是对于共享资源 state 的获取和释放）

2. 将 AQS 组合在⾃定义同步组件的实现中，并调⽤其模板⽅法，⽽这些模板⽅法会调⽤使⽤者重写的⽅法。

这和我们以往通过实现接⼝的⽅式有很⼤区别，这是模板⽅法模式很经典的⼀个运⽤。

AQS 使⽤了模板⽅法模式，⾃定义同步器时需要重写下⾯⼏个 AQS 提供的模板⽅法：

isHeldExclusively()//该线程是否正在独占资源。只有⽤到condition才需要去实现它。
tryAcquire(int)//独占⽅式。尝试获取资源，成功则返回true，失败则返回false。
tryRelease(int)//独占⽅式。尝试释放资源，成功则返回true，失败则返回false。
tryAcquireShared(int)//共享⽅式。尝试获取资源。负数表示失败；0表示成功，但没有剩余可⽤资
源；正数表示成功，且有剩余资源。
tryReleaseShared(int)//共享⽅式。尝试释放资源，成功则返回true，失败则返回false。

默认情况下，每个⽅法都抛出 UnsupportedOperationException 。 AQS 类中的其他⽅法都是 final ，所以⽆法被其他类使用，只有这几个⽅法可以被其他类使用。

以 ReentrantLock 为例，state 初始化为 0，表示未锁定状态。A 线程 lock()时，会调用tryAcquire()独占该锁并将 state+1。此后，其他线程再 tryAcquire()时就会失败，直到 A 线程unlock()到 state=0（即释放锁）为⽌，其它线程才有机会获取该锁。当然，释放锁之前，A 线程⾃己是可以重复获取此锁的（state 会累加），这就是可重⼊的概念。但要注意，获取多少次就要释放多么次，这样才能保证 state 是能回到零态的。

再以 CountDownLatch 以例，任务分为 N 个⼦线程去执⾏，state 也初始化为 N（注意 N 要与线程个数⼀致）。这 N 个⼦线程是并⾏执⾏的，每个⼦线程执⾏完后 countDown() ⼀次，state 会CAS(Compare and Swap)减 1。等到所有⼦线程都执⾏完后(即 state=0)，会 unpark()主调⽤线程，然后主调⽤线程就会从 await() 函数返回，继续后续动作。

⼀般来说，⾃定义同步器要么是独占⽅法，要么是共享⽅式，他们也只需实现 tryAcquire-tryRelease 、 tryAcquireShared-tryReleaseShared 中的⼀种即可。但 AQS 也⽀持⾃定义同步器同时实现独占和共享两种⽅式，如 ReentrantReadWriteLock 。

7.4、AQS 组件总结

• Semaphore (信号量)-允许多个线程同时访问： synchronized 和 ReentrantLock 都是⼀次只允许⼀个线程访问某个资源， Semaphore (信号量)可以指定多个线程同时访问某个源。
• CountDownLatch （倒计时器）： CountDownLatch 是⼀个同步⼯具类，⽤来协调多个线程之间的同步。这个⼯具通常⽤来控制线程等待，它可以让某⼀个线程等待直到倒计时结束，再开始执⾏。
• CyclicBarrier (循环栅栏)： CyclicBarrier 和 CountDownLatch ⾮常类似，它也可以实现线程间的技术等待，但是它的功能⽐ CountDownLatch 更加复杂和强⼤。主要应⽤场景和CountDownLatch 类似。 CyclicBarrier 的字⾯意思是可循环使⽤（ Cyclic ）的屏障（ Barrier ）。它要做的事情是，让⼀组线程到达⼀个屏障（也可以叫同步点）时被阻塞，直到最后⼀个线程到达屏障时，屏障才会开⻔，所有被屏障拦截的线程才会继续⼲
  活。 CyclicBarrier 默认的构造⽅法是 CyclicBarrier(int parties) ，其参数表示屏障拦截的线程数量，每个线程调⽤ await() ⽅法告诉 CyclicBarrier 我已经到达了屏障，然后当前线程被阻塞。

7.5、CountDownLatch使用场景

CountDownLatch 的作⽤就是 允许 count 个线程阻塞在⼀个地⽅，直⾄所有线程的任务都执⾏完毕。之前在项⽬中，有⼀个使⽤多线程读取多个⽂件处理的场景，我⽤到了 CountDownLatch 。具体场景是下⾯这样的：

要读取处理 6 个⽂件，这 6 个任务都是没有执⾏顺序依赖的任务，但是我们需要返回给⽤户的时候将这⼏个⽂件的处理的结果进⾏统计整理。

为此我定义了⼀个线程池和 count 为 6 的 CountDownLatch 对象 。使⽤线程池处理读取任务，每⼀个线程处理完之后就将 count-1，调⽤ CountDownLatch 对象的 await() ⽅法，直到所有⽂件读取完之后，才会接着执⾏后⾯的逻辑。

public class CountDownLatchExample1 {
        // 处理⽂件的数量
        private static final int threadCount = 6;
        public static void main(String[] args) throws InterruptedException {
            // 创建⼀个具有固定线程数量的线程池对象（推荐使⽤构造⽅法创建）
            ExecutorService threadPool = Executors.newFixedThreadPool(10);
            final CountDownLatch countDownLatch = new CountDownLatch(threadCount);
            for (int i = 0; i < threadCount; i++) {
                final int threadnum = i;
                threadPool.execute(() -> {
                    try {
                        //处理⽂件的业务操作
                        // ......
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    } finally {
                        //表示一个文件已经被完成
                        countDownLatch.countDown();
                    }
                });
            }
            countDownLatch.await();
            threadPool.shutdown();
            System.out.println("finish");
        }
    }

有没有可以改进的地⽅呢？
可以使⽤ CompletableFuture 类来改进！Java8 的 CompletableFuture 提供了很多对多线程友好的⽅法，使⽤它可以很⽅便地为我们编写多线程程序，什么异步、串行、并行或者等待所有线程执行完任务什么的都非常方便。

CompletableFuture<Void> task1 =
            CompletableFuture.supplyAsync(()->{
                //⾃定义业务操作
            });
            ......
    CompletableFuture<Void> task6 =
            CompletableFuture.supplyAsync(()->{
                //⾃定义业务操作
            });
            ......
    CompletableFuture<Void>
            headerFuture=CompletableFuture.allOf(task1,.....,task6);
	try {
	        headerFuture.join();
	    } catch (Exception ex) {
	        ......
	    }
	System.out.println("all done. ");

上⾯的代码还可以接续优化，当任务过多的时候，把每⼀个 task 都列出来不太现实，可以考虑通过循环来添加任务。

//⽂件夹位置
    List<String> filePaths = Arrays.asList(...)
    // 异步处理所有⽂件
    List<CompletableFuture<String>> fileFutures = filePaths.stream()
            .map(filePath -> doSomeThing(filePath))
            .collect(Collectors.toList());
    // 将他们合并起来
    CompletableFuture<Void> allFutures = CompletableFuture.allOf(
            fileFutures.toArray(new CompletableFuture[fileFutures.size()])
    );