Java 锁

1、乐观锁

1.1、什么是乐观锁？

乐观锁是相对悲观锁而言的，乐观锁假设数据一般情况不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果冲突，则返回给用户异常信息，让用户决定如何去做。乐观锁适用于读多写少的场景，这样可以提高程序的吞吐量。

乐观锁采取了更加宽松的加锁机制。也是为了避免数据库幻读、业务处理时间过长等原因引起数据处理错误的一种机制，但乐观锁不会刻意使用数据库本身的锁机制，而是依据数据本身来保证数据的正确性。

1.2、乐观锁的实现：

1. CAS 实现：Java 中java.util.concurrent.atomic包下面的原子变量使用了乐观锁的一种 CAS 实现方式。
2. 版本号控制：一般是在数据表中加上一个数据版本号 version 字段，表示数据被修改的次数。当数据被修改时，version 值会 +1。当线程 A 要更新数据时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值与当前数据库中的 version 值相等时才更新，否则重试更新操作，直到更新成功。

乐观锁是一种乐观思想，假定当前环境是读多写少，遇到并发写的概率比较低，读数据时认为别的线程不会正在进行修改（所以没有上锁）。写数据时，判断当前 与期望值是否相同，如果相同则进行更新（更新期间加锁，保证是原子性的）。
Java中的乐观锁：CAS，比较并替换，比较当前值（主内存中的值），与预期值（当前线程中的值，主内存中值的一份拷贝）是否一样，一样则更新，否则继续进行CAS操作。进行原子性操作是否和期望值一样，自旋操作。
如上图所示，可以同时进行读操作，读的时候其他线程不能进行写操作。
使用场景：
乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。
乐观锁应用在CAS上面：比较并交换的原子性操作上。

1.3、算法实现

介绍CAS算法：
硬件支持的原子性操作最典型的是：比较并交换（Compare-and-Swap，CAS）。 CAS 指令需要有 3 个操作数，分别是内存地址 V、旧的预期值 A 和新值 B。 当执行操作时，只有当 V 的值等于 A，才将 V 的值更新为 B。属于非阻塞算法的实现，轻量级锁。

//著名的CAS
//var1是比较值所属的对象，var2需要比较的值（但实际是使用地址偏移量来实现的），
//如果var1对象中偏移量为var2处的值等于var4，那么将该处的值设置为var5并返回true，如果不等于var4则返回false。
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
// 这里调用了本地方法  实现比较+替换方法的实现

版本控制算法：
版本控制算法就是在数据库中每个表添加一个version字段每当修改一次数据就修改version版本，修改之前修改乐观锁版本，进入的线程比较版本，不同则取消当前线程的修改。

版本实现算法：
一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version++即可。 当线程A要更新数据值时，在读取数据的同时也会读取version值， 在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新， 否则重试更新操作，直到更新成功。
举个例子：
假设数据库中帐户信息表中有一个 version 字段，并且 version=1;而当前帐户余额字段(balance)为 $100 。
操作员 A 此时将其读出 (version=1)，并从其帐户余额中扣除 $50($100-$50)。
操作员 A 操作的同事，操作员B 也读入此用户信息(version=1)，并从其帐户余额中扣除 $20($100-$20)。
操作员 A 完成了修改工作，version++(version=2)，连同帐户扣除后余额(balance=$50)，提交至数据库更新，
此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
操作员 B 完成了操作，也将版本号version++(version=2)试图向数据库提交数据(balance=$80)，
但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，
不满足提交版本必须大于记录当前版本才能执行更新的乐观锁策略，因此，操作员 B 的提交被驳回。

1.4、优缺点

优点：
乐观锁机制避免了长 事务 中的数据库加锁开销（操作员 A和操作员 B 操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。

缺点：

1.4.1、ABA问题

什么是ABA问题？
如果一个变量初次读取的时候是 A 值，它的值被改成了 B，后来又被改回为 A，那 CAS 操作就会误认为它从来没有被改变过。

J.U.C 包提供了一个带有标记的原子引用类 AtomicStampedReference 来解决这个问题， 它可以通过控制变量值的版本来保证 CAS 的正确性。 大部分情况下 ABA 问题不会影响程序并发的正确性， 如果需要解决 ABA 问题，改用传统的互斥同步可能会比原子类更高效。

1.4.2、自旋时间长开销大

自旋CAS（也就是不成功就一直循环执行直到成功）如果长时间不成功，会给CPU带来非常大的执行开销。 如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用， 第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源， 延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。 第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation） 而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。

解决方法：可以设置自旋次数就取消自旋

3.只能保证一个共享变量的原子操作 CAS只对单个共享变量有效，当操作涉及跨多个共享变量时CAS无效。 但是从 JDK 1.5开始，提供了AtomicReference类来保证引用对象之间的原子性， 可以把多个变量封装成对象里来进行 CAS 操作. 所以我们可以使用锁或者利用AtomicReference类把多个共享变量封装成一个共享变量来操作。

1.5、CAS与synchronized的使用场景

对于资源竞争较少（线程冲突较轻）的情况， 使用synchronized同步锁进行线程阻塞和唤醒切换以及用户态内核态间的切换操作额外浪费消耗cpu资源； 而CAS基于硬件实现，不需要进入内核，不需要切换线程，操作自旋几率较少，因此可以获得更高的性能。使用重量级锁进行阻塞线程会增加cpu的消耗，自旋会更快获取资源，提升性能。

对于资源竞争严重（线程冲突严重）的情况，CAS自旋的概率会比较大， 从而浪费更多的CPU资源，效率低于synchronized。

2、悲观锁

2.1、什么是悲观锁？

顾名思义，就是比较悲观的锁，总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。悲观锁中的共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程

当要对数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。这种借助数据库锁机制，在修改数据之前先锁定，再修改的方式被称之为悲观并发控制【Pessimistic Concurrency Control，缩写“PCC”，又名“悲观锁”】。
悲观锁，具有强烈的独占和排他特性。它指的是对数据被外界(包括本系统当前的其他事务，以及来自外部系统的事务处理)修改持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据)。

‘

悲观锁是一种悲观思想，即认为写多读少，遇到并发写的可能性高，每次去拿数据的时候都认为其他线程会修改，所以每次读写数据都会认为其他线程会修改，所以每次读写数据时都会上锁。其他线程想要读写这个数据时，会被这个线程block，直到这个线程释放锁然后其他线程获取到锁。 就是相当于重量级锁，进行阻塞线程。
Java中的悲观锁：synchronized修饰的方法和方法块、ReentrantLock。
如上图所示，只能有一个线程进行读操作或者写操作，其他线程的读写操作均不能进行
悲观锁的使用场景：
因此一般我们可以在并发量不是很大，并且出现并发情况导致的异常用户和系统都很难以接受的情况下，会选择悲观锁进行。通常是写多读少的场景使用较多。

2.2、悲观锁分类

悲观锁主要分为共享锁和排他锁：

• 共享锁【shared locks】又称为读锁，简称 S 锁。顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。
• 排他锁【exclusive locks】又称为写锁，简称 X 锁。顾名思义，排他锁就是不能与其他锁并存，如果一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁。获取排他锁的事务可以对数据行读取和修改。

  2.3、算法实现

  有用户A和用户B，在同一家店铺去购买同一个商品，但是商品的可购买数量只有一个

在不加锁的情况下，如果用户A和用户B同时下单，就会报错。
悲观锁的实现，往往依靠数据库提供的锁机制，在数据库中，我们如何用悲观锁去解决这个事情呢？

1. 加入当用户A对下单购买商品（臭豆腐）的时候，先去尝试对该数据（臭豆腐）加上悲观锁
2. 加锁失败：说明商品（臭豆腐）正在被其他事务进行修改，当前查询需要等待或者抛出异常，具体返回的方式需要由开发者根据具体情况去定义
3. 加锁成功：对商品（臭豆腐）进行修改，也就是只有用户A能买，用户B想买（臭豆腐）就必须一直等待（阻塞）。当用户A买好后，用户B再想去买（臭豆腐）的时候会发现数量已经为0，那么B看到后就会放弃购买
4. 在此期间如果有其他对该数据（臭豆腐）做修改或加锁的操作，都会等待我们解锁后或者直接抛出异常

那么如何加上悲观锁呢？我们可以通过以下语句给id=2的这行数据加上悲观锁，首先关闭MySQL数据库的自动提交属性。因为MySQL默认使用autocommit模式，也就是说，当我们执行一个更新操作后，MySQL会立刻将结果进行提交,（sql语句：set autocommit=0）

悲观锁加锁sql语句： select num from t_goods where id = 2 for update

我们通过开启mysql的两个会话，也就是两个命令行来演示：
事务A：
我们可以看到数据是立刻马上就可以查询出来，num=1
事务B：
我们是可以看到，事务B会一直等待事务A释放锁。如果事务A长期不释放锁，那么最终事务B将会报错，报错如下：Lock wait timeout exceeded; try restarting transaction，表示语句已被锁住

2.4、优缺点

优点：
悲观并发控制采取的是保守策略：“先取锁，成功了才访问数据”，这保证了数据获取和修改都是有序进行的，因此适合在写多读少的环境中使用。当然使用悲观锁无法维持非常高的性能，但是在乐观锁也无法提供更好的性能前提下，悲观锁却可以做到保证数据的安全性。

缺点：
由于需要加锁，而且可能面临锁冲突甚至死锁的问题，悲观并发控制增加了系统的额外开销，降低了系统的效率，同时也会降低了系统的并行性。

2.5、应用场景实现

2.5.1、synchronized

1、内存可见性

这里的本地内存并不是真实存在的，只是 Java 内存模型的一个抽象概念，它包含了控制器、运算器、缓存等。同时 Java 内存模型规定，线程对共享变量的操作必须在自己的本地内存中进行，不能直接在主内存中操作共享变量。这种内存模型会出现什么问题呢？

• 线程 A 获取到共享变量 X 的值，此时本地内存 A 中没有 X 的值，所以加载主内存中的 X 值并缓存到本地内存 A 中，线程 A 修改 X 的值为 1，并将 X 的值刷新到主内存中，这时主内存及本地内存中的 X 的值都为 1

• 线程 B 需要获取共享变量 X 的值，此时本地内存 B 中没有 X 的值，加载主内存中的 X 值并缓存到本地内存 B 中，此时 X 的值为 1。线程 B 修改 X 的值为 2，并刷新到主内存中，此时主内存及本地内存 B 中的 X 值为 2，本地内存 A 中的 X 值为 1

• 线程 A 再次获取共享变量 X 的值，此时本地内存中存在 X 的值，所以直接从本地内存中 A 获取到了 X 为 1 的值，但此时主内存中 X 的值为 2，到此出现了所谓内存不可见的问题

该问题 Java 内存模型是通过 synchronized 关键字和 volatile 关键字就可以解决，那么 synchronized 关键字是如何解决的呢，其实进入 synchronized 块就是把在 synchronized 块内使用到的变量从线程的本地内存中擦除，这样在 synchronized 块中再次使用到该变量就不能从本地内存中获取了，需要从主内存中获取，解决了内存不可见问题。

2、synchronized的特征

圈内经常拿 synchronized 关键字和 volatile 关键字的特性进行对比，synchronized 关键字可以保证并发编程的三大特性：原子性、可见性、有序性，而 volatile 关键字只能保证可见性和有序性，不能保证原子性，也称为是轻量级的 synchronized。

• 原子性：一个或多个操作要么全部执行成功，要么全部执行失败。synchronized 关键字可以保证只有一个线程拿到锁，访问共享资源
• 可见性：当一个线程对共享变量进行修改后，其他线程可以立刻看到。执行 synchronized 时，会对应执行 lock、unlock 原子操作，保证可见性
• 有序性：程序的执行顺序会按照代码的先后顺序执行

这里聊到了volatile关键字的使用 这里来介绍一个volatile关键字的含义

volatile是什么？
volatile在java语言中是一个关键字，用于修饰变量。被volatile修饰的变量后，表示这个变量在不同线程中是共享，编译器与运行时都会注意到这个变量是共享的，因此不会对该变量进行重排序。上面这句话可能不好理解，但是存在两个关键，共享和重排序。
变量的共享：
先来看一个被举烂了的例子:

public class VolatileTest {
    boolean isStop = false;
    public void test() {
        Thread t1 = new Thread() {
            @Override
            public void run() {
                isStop = true;
            }
        };
        Thread t2 = new Thread() {
            @Override
            public void run() {
                while (!isStop) {
                }
            }
        };
        t2.start();
        t1.start();
    }
    public static void main(String args[]) throws InterruptedException {
        new VolatileTest().test();
    }
}

上面的代码是一种典型用法，检查某个标记（isStop）的状态判断是否退出循环。但是上面的代码有可能会结束，也可能永远不会结束。因为每一个线程都拥有自己的工作内存，当一个线程读取变量的时候，会把变量在自己内存中拷贝一份。之后访问该变量的时候都通过访问线程的工作内存，如果修改该变量，则将工作内存中的变量修改，然后再更新到主存上。这种机制让程序可以更快的运行，然而也会遇到像上述例子这样的情况。
存在一种情况，isStop变量被分别拷贝到t1、t2两个线程中，此时isStop为false。t2开始循环，t1修改本地isStop变量称为true，并将isStop=true回写到主存，但是isStop已经在t2线程中拷贝过一份，t2循环时候读取的是t2 工作内存中的isStop变量，而这个isStop始终是false，程序死循环。我们称t2对t1更新isStop变量的行为是不可见的。就是目前的isStop变量是之前拷贝的，另外线程修改本线程不会获取到修改后的值。
如果isStop变量通过volatile进行修饰，t2修改isStop变量后，会立即将变量回写到主存中，并将t1里的isStop失效。t1发现自己变量失效后，会重新去主存中访问isStop变量，而此时的isStop变量已经变成true。循环退出。
volatile boolean isStop = false;
volatile如何使用
volatile关键字一般用于标记变量的修饰，类似上述例子。《Java并发编程实战》中说，volatile只保证可见性，而加锁机制既可以确保可见性又可以确保原子性。当且仅当满足以下条件下，才应该使用volatile变量：
1、对变量的写入操作不依赖变量的当前值，或者确保只有单个线程变更变量的值。
2、该变量不会于其他状态一起纳入不变性条件中
3、在访问变量的时候不需要加锁。

逐一分析：
第一条说明volatile不能作为多线程中的计数器，计数器的count++操作，分为三步，第一步先读取count的数值，第二步count+1，第三步将count+1的结果写入count。volatile不能保证操作的原子性。上述的三步操作中，如果有其他线程对count进行操作，就可能导致数据出错。

public class VolatileTest {
    private volatile int lower = 0;
    private volatile int upper = 5;
    public int getLower() {
        return lower;
    }
    public int getUpper() {
        return upper;
    }
    public void setLower(int lower) {
        if (lower > upper) {
            return;
        }
        this.lower = lower;
    }
    public void setUpper(int upper) {
        if (upper < lower) {
            return;
        }
        this.upper = upper;
    }
}

述程序中，lower初始为0,upper初始为5，并且upper和lower都用volatile修饰。我们期望不管怎么修改upper或者lower，都能保证upper>lower恒成立。然而如果同时有两个线程，t1调用setLower，t2调用setUpper，两线程同时执行的时候。有可能会产生upper<lower这种不期望的结果。

public void test() {
        Thread t1 = new Thread() {
            @Override
            public void run() {
                try {
                    Thread.sleep(10);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                setLower(4);
            }
        };
        Thread t2 = new Thread() {
            @Override
            public void run() {
                try {
                    Thread.sleep(10);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                setUpper(3);
            }
        };
        t1.start();
        t2.start();
        while (t1.isAlive() || t2.isAlive()) {
        }
        System.out.println("(low:" + getLower() + ",upper:" + getUpper() + ")");
    }
    public static void main(String args[]) throws InterruptedException {
        for (int i = 0; i < 100; i++) {
            VolatileTest volaitil = new VolatileTest();
            volaitil.test();
        }
    }

此时程序一直正常运行，但是出现的结果却是我们不想要的。

第三条：当访问一个变量需要加锁时，一般认为这个变量需要保证原子性和可见性，而volatile关键字只能保证变量的可见性，无法保证原子性。

最后贴个volatile的常见例子，在单例模式双重检查中的使用：

public class Singleton {
    private static volatile Singleton instance=null;
    private Singleton(){
    }
    public static Singleton getInstance(){
        if(instance==null){
            synchronized(Singleton.class){
                if(instance==null){
                    instance=new Singleton();
                }
            }
        }
        return instance;
    }
}

new Singleton()分为三步,1、分配内存空间，2、初始化对象，3、设置instance指向被分配的地址。然而指令的重新排序，可能优化指令为1、3、2的顺序。如果是单个线程访问，不会有任何问题。但是如果两个线程同时获取getInstance，其中一个线程执行完1和3步骤，此时其他的线程可以获取到instance的地址，在进行if(instance==null)时，判断出来的结果为false，导致其他线程直接获取到了一个未进行初始化的instance，这可能导致程序的出错。所以用volatile修饰instance，禁止指令的重排序，保证程序能正常运行。（Bug很难出现，没能模拟出来）。
然而，《java并发编程实战中》中有对DCL的描述如下：”DCL的这种使用方法已经被广泛废弃了——促使该模式出现的驱动力（无竞争同步的执行速度很慢，以及JVM启动很慢）已经不复存在了，因而它不是一种高效的优化措施。延迟初始化占位类模式能带来同样的优势，并且更容易理解。”，其实我个小码畜的角度来看，服务端的单例更多时候做延迟初始化并没有很大意义，延迟初始化一般用来针对高开销的操作，并且被延迟初始化的对象都是不需要马上使用到的。然而，服务端的单例在大部分的时候，被设计为单例的类大部分都会被系统很快访问到。本篇文章只是讨论volatile，并不针对设计模式进行讨论，因此后续有时间，再补上替代上述单例的写法。

3、实现什么类型的锁

• 悲观锁：synchronized 关键字实现的是悲观锁，每次访问共享资源时都会上锁
• 非公平锁：synchronized 关键字实现的是非公平锁，即线程获取锁的顺序并不一定是按照线程阻塞的顺序
• 可重入锁：synchronized 关键字实现的是可重入锁，即已经获取锁的线程可以再次获取锁
• 独占锁或者排他锁：synchronized 关键字实现的是独占锁，即该锁只能被一个线程所持有，其他线程均被阻塞

4、底层原理

synchronized 底层原理是比较难理解的，理解 synchronized 需要一定的 Java 虚拟机的知识。

在 jdk1.6 之前，synchronized 被称为重量级锁，在 jdk1.6 中，为了减少获得锁和释放锁带来的性能开销，引入了偏向锁和轻量级锁。下面先介绍 jdk1.6 之前的 synchronized 原理。

1）、对象头

我们知道，Java 对象保存在堆内存中。一个 Java 对象包含三部分：对象头、实例数据和对齐填充。其中对象头是一个很关键的部分，因为对象头中包含锁状态标志、线程持有的锁等标志。

synchronized 是悲观锁，在操作同步资源之前需要给同步资源先加锁，这把锁就是存在 Java 对象头里的，而 Java 对象头又是什么呢？

每一个 Java 类，在被 JVM 加载的时候，JVM 会给这个类创建一个 instanceKlass，保存在方法区，用来在 JVM 层表示该 Java 类。当我们在 Java 代码中，使用 new 创建一个对象的时候，JVM 会创建一个 instanceOopDesc 对象，这个对象中包含了对象头以及实例数据。

我们以 Hotspot 虚拟机为例，Hotspot 的对象头主要包括两部分数据：Mark Word（标记字段）、Klass Pointer（类型指针）

Mark Word： 默认存储对象的 HashCode，分代年龄和锁标志位信息。Mark Word 用于存储对象自身的运行时数据，所以 Mark Word 被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据。它会根据对象的状态复用自己的存储空间，也就是说在运行期间 Mark Word 里存储的数据会随着锁标志位的变化而变化。

Klass Point： 对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

重量级锁的底部实现原理是Monitor ，jdk1.6之前只能实现重量级锁，基于Monitor对象来实现重量级锁，底层原理是由C++编写。

jdk1.6之后synchronized进行优化 进行锁升级。
在 JDK1.6 中，为了减少获得锁和释放锁带来的性能消耗，引入了偏向锁和轻量级锁，锁的状态变成了四种，如下图所示。锁的状态会随着竞争激烈逐渐升级，但通常情况下，锁的状态只能升级不能降级。这种只能升级不能降级的策略是为了提高获得锁和释放锁的效率。

常见问题汇总：
1、了解锁消除吗？
锁消除是指 Java 虚拟机在即时编译时，通过对运行上下的扫描，消除那些不可能存在共享资源竞争的锁。锁消除可以节约无意义的请求锁时间。

2、了解锁粗化吗？
一般情况下，为了提高性能，总是将同步块的作用范围限制到最小，这样可以使得需要同步的操作尽可能地少。但如果一系列连续的操作一直对某个对象反复加锁和解锁，频繁地进行互斥同步操作也会引起不必要的性能消耗。
如果虚拟机检测到有一系列操作都是对某个对象反复加锁和解锁，会将加锁同步的范围粗化到整个操作序列的外部。可以看下面这个经典案例。

for(int i=0;i<n;i++){
    synchronized(lock){
    }
}

这段代码会导致频繁地加锁和解锁，锁粗化后

synchronized(lock){
    for(int i=0;i<n;i++){
    }
}

3、当线程 1 进入到一个对象的 synchronized 方法 A 后，线程 2 是否可以进入到此对象的 synchronized 方法 B?
不能，线程 2 只能访问该对象的非同步方法。因为执行同步方法时需要获得对象的锁，而线程 1 在进入 sychronized 修饰的方 A 时已经获取到了锁，线程 2 只能等待，无法进入到 synchronized 修饰的方法 B，但可以进入到其他非 synchronized 修饰的方法。

4、synchronized 和 volatile 的区别？

• volatile 主要是保证内存的可见性，即变量在寄存器中的内存是不确定的，需要从主存中读取。synchronized 主要是解决多个线程访问资源的同步性
• volatile 作用于变量，synchronized 作用于代码块或者方法
• volatile 仅可以保证数据的可见性，不能保证数据的原子性。synchronized 可以保证数据的可见性和原子性
• volatile 不会造成线程的阻塞，synchronized 会造成线程的阻塞

5、synchronized 和 Lock 的区别？

• Lock 是显示锁，需要手动开启和关闭。synchronized 是隐士锁，可以自动释放锁
• Lock 是一个接口，是 JDK 实现的。synchronized 是一个关键字，是依赖 JVM 实现的
• Lock 是可中断锁，synchronized 是不可中断锁，需要线程执行完才能释放锁
• 发生异常时，Lock 不会主动释放占有的锁，必须通过 unloc k进行手动释放，因此可能引发死锁。synchronized 在发生异常时会自动释放占有的锁，不会出现死锁的情况
• Lock 可以判断锁的状态，synchronized 不可以判断锁的状态
• Lock 实现锁的类型是可重入锁、公平锁。synchronized 实现锁的类型是可重入锁，非公平锁
• Lock 适用于大量同步代码块的场景，synchronized 适用于少量同步代码块的场景

2.5.2、Vector

Vector的一些方法实现了synchronized的方法实现。
这里查找一些方法

/**
 * 通过index获取容器中的元素（此方法用虽不会修改容器，不过还是用synchronized修饰了，同步方法，this对象锁，防止读到不是最新的数据）
 */
public synchronized E get(int index) {
    // 检查是否超出最后一个元素的边界（注意这里的边界检查并不是检查下标是否超过数组的长度）
    if (index >= elementCount)
        throw new ArrayIndexOutOfBoundsException(index);
    // 下标合法则调用elementData方法获取元素
    return elementData(index);
}
@SuppressWarnings("unchecked")
E elementData(int index) {
    return (E) elementData[index];
}

方法实现了synchronized的方法锁，不能同时操作，线程安全。

2.5.3、HashTable

这里直接赋值源码就可以理解

public synchronized V put(K key, V value) {
    // Make sure the value is not null
    if (value == null) {
        throw new NullPointerException();
    }
    // Makes sure the key is not already in the hashtable.
    Entry<?,?> tab[] = table;
    int hash = key.hashCode();
    int index = (hash & 0x7FFFFFFF) % tab.length;
    @SuppressWarnings("unchecked")
    Entry<K,V> entry = (Entry<K,V>)tab[index];
    for(; entry != null ; entry = entry.next) {
        if ((entry.hash == hash) && entry.key.equals(key)) {
            V old = entry.value;
            entry.value = value;
            return old;
        }
    }
    addEntry(hash, key, value, index);
    return null;
}
public synchronized V get(Object key) {
    Entry<?,?> tab[] = table;
    int hash = key.hashCode();
    int index = (hash & 0x7FFFFFFF) % tab.length;
    for (Entry<?,?> e = tab[index] ; e != null ; e = e.next) {
        if ((e.hash == hash) && e.key.equals(key)) {
            return (V)e.value;
        }
    }
    return null;
}

都实现了synchronized的方法锁安全，使其线程安全。

3、自旋锁

3.1、自旋锁的概率

自旋锁（spinlock）：是指当一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环。
获取锁的线程一直处于活跃状态，但是并没有执行任何有效的任务，使用这种锁会造成busy-waiting。
它是为实现保护共享资源而提出一种锁机制。其实，自旋锁与互斥锁比较类似，它们都是为了解决对某项资源的互斥使用。无论是互斥锁，还是自旋锁，在任何时刻，最多只能有一个保持者，也就说，在任何时刻最多只能有一个执行单元获得锁。但是两者在调度机制上略有不同。对于互斥锁，如果资源已经被占用，资源申请者只能进入睡眠状态。但是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，”自旋”一词就是因此而得名。
在获取锁的过程中，线程一直处于活跃状态。因此与mutex不同，spinlock不会导致线程的状态切换(用户态->内核态)，一直处于用户态，即线程一直都是active的；不会使线程进入阻塞状态，减少了不必要的上下文切换，执行速度快。
由于自旋时不释放CPU，如果持有自旋锁的线程一直不释放自旋锁，那么等待该自旋锁的线程会一直浪费CPU时间。因此，自旋锁主要适用于被持有时间短，线程不希望在重新调度上花过多时间的情况。

自旋锁是一种技术： 为了让线程等待，我们只须让线程执行一个忙循环（自旋）。 现在绝大多数的个人电脑和服务器都是多路（核）处理器系统，如果物理机器有一个以上的处理器或者处理器核心，能让两个或以上的线程同时并行执行，就可以让后面请求锁的那个线程“稍等一会”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。

自旋次数默认值：10次，可以使用参数-XX:PreBlockSpin来自行更改。自适应自旋： 自适应意味着自旋的时间不再是固定的，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定的。有了自适应自旋，随着程序运行时间的增长及性能监控信息的不断完善，虚拟机对程序锁的状态预测就会越来越精准。
Java中的自旋锁： CAS操作中的比较操作失败后的自旋等待

自旋和非自旋之间获取锁的流程

可以看出，非自旋锁和自旋锁最大的区别，就是如果它遇到拿不到锁的情况，它会把线程阻塞，直到被唤醒。而自旋锁会不停地尝试。

3.2、自旋锁的实现

根据自旋锁的原理，我们先尝试写出伪代码实现：

//循环检查锁状态，并尝试获取，直到成功
while (true):
  locked = get_lock()
  if locked == false:
    locked = true
    break
//上锁后执行相关任务
do_something
//执行完毕，释放锁
locked = false

细心的同学可以发现上面的逻辑在并发场景会遇到问题：两个线程可能会同时进入if语句，同时获取锁，导致锁不生效。
如何解决这个问题？我们可以把查询锁（get_lock）和设置锁（locked=true）组合成一个原子操作，保证同一时间只有一个线程在执行。如下所示：get_and_set就是CAS操作。

//这里get_and_set(locked)就是一个原子操作，执行成功后把locked设置成true。
while (get_and_set(locked) == false):
  continue
do_something
locked = false

如此，就实现了一个简单的自旋锁。
那么现在的问题是如何实现get_and_set(locked)这个原子操作？这里有两个常用的方法可以使用：TAS（test and set）和CAS （compare and swap）。

1. TAS：一个TAS指令包括两个子步骤，把给定的内存地址设置为1，然后返回之前的旧值。
2. CAS：CAS指令需要三个参数，一个内存位置(V)、一个期望旧值(A)、一个新值(B)。过程如下：a. 比较内存V的值是否与A相等？
   b. 如果相等，则用新值B替换内存位置V的旧值
   c. 如果不相等，不做任何操作。
   d. 无论哪个情况，CAS都会把内存V原来的值返回。

很多语言都提供了封装后的TAS和CAS调用方法。
先看一个实现自旋锁的例子，java.util.concurrent包里提供了很多面向并发编程的类. 使用这些类在多核CPU的机器上会有比较好的性能.主要原因是这些类里面大多使用(失败-重试方式的)乐观锁而不是synchronized方式的悲观锁.

class spinlock {
    private AtomicReference<Thread> cas;
    spinlock(AtomicReference<Thread> cas){
        this.cas = cas;
    }
    public void lock() {
        Thread current = Thread.currentThread();
        // 利用CAS
        while (!cas.compareAndSet(null, current)) { //为什么预期是null？？
            // DO nothing
            System.out.println("I am spinning");
        }
    }
    public void unlock() {
        Thread current = Thread.currentThread();
        cas.compareAndSet(current, null);
    }
}
// 利用CAS来实现原则操作  自旋锁实现操作

lock（)方法利用的CAS，当第一个线程A获取锁的时候，能够成功获取到，不会进入while循环，如果此时线程A没有释放锁，另一个线程B又来获取锁，此时由于不满足CAS，所以就会进入while循环，不断判断是否满足CAS，直到A线程调用unlock方法释放了该锁。

这里来看一个例子实现自旋锁的：

public class 自旋锁 {
    public static void main(String[] args) {
        AtomicReference<Thread> cas = new AtomicReference<Thread>();
        Thread thread1 = new Thread(new Task(cas));
        Thread thread2 = new Thread(new Task(cas));
        thread1.start();
        thread2.start();
    }
}
//自旋锁验证
class Task implements Runnable {
    // 利用cas实现原子操作
    private AtomicReference<Thread> cas;
    // 自旋锁
    private spinlock slock ;
    public Task(AtomicReference<Thread> cas) {
        this.cas = cas;
        this.slock = new spinlock(cas);
    }
    @Override
    public void run() {
        slock.lock(); //上锁
        for (int i = 0; i < 10; i++) {
            //Thread.yield();
            System.out.println(i);
        }
        slock.unlock();
    }
}

/**
 * @discription 实现一个可重入的自旋锁
 */
public class ReentrantSpinLock {
    private AtomicReference<Thread> owner = new AtomicReference<>();
    // 重入次数
    private int count = 0;
    public static void main(String[] args) {
        ReentrantSpinLock spinLock = new ReentrantSpinLock();
        Runnable runnable = new Runnable() {
            @Override
            public void run() {
                System.out.println(Thread.currentThread().getName() + "开始尝试获取自旋锁");
                spinLock.lock();
                try{
                    System.out.println(Thread.currentThread().getName() + "获取到了自旋锁");
                    Thread.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally {
                    spinLock.unlock();
                    System.out.println(Thread.currentThread().getName() + "释放了了自旋锁");
                }
            }
        };
        Thread thread1 = new Thread(runnable);
        Thread thread2 = new Thread(runnable);
        thread1.start();
        thread2.start();
    }
    public void lock(){
        Thread thread = Thread.currentThread();
        if(thread == owner.get()){
            ++count;
            return;
        }
        //自旋获取锁
        while (!owner.compareAndSet(null,thread)){
            System.out.println("自旋了");
        }
    }
    public void unlock(){
        Thread thread = Thread.currentThread();
        //只有持有锁的线程才能解锁
        if(thread == owner.get()){
            if(count > 0){
                --count;
            }else {
                //此处无需CAS操作，因为没有竞争，因为只有线程持有者才能解锁
                owner.set(null);
            }
        }
    }
}

这里获取了锁另外的线程进行自旋操作，判断获取锁线程是否释放锁（主要是通过内存的不同值来实现判断）

3.3、自旋锁的优缺点

自旋锁的优点： 避免了线程切换的开销。挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给Java虚拟机的并发性能带来了很大的压力。 线程一直是active的状态，不会使线程进入阻塞状态，不需要进入上下文的切换，执行速度快。

自旋锁的缺点： 占用处理器的时间，如果占用的时间很长，会白白消耗处理器资源，而不会做任何有价值的工作，带来性能的浪费。因此自旋等待的时间必须有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程。 所以自旋锁一般有一个默认的自旋次数为10。

3.4、可重入的自旋锁和不可重入的自旋锁

文章开始的时候的那段代码，仔细分析一下就可以看出，它是不支持重入的，即当一个线程第一次已经获取到了该锁，在锁释放之前又一次重新获取该锁，第二次就不能成功获取到。由于不满足CAS，所以第二次获取会进入while循环等待，而如果是可重入锁，第二次也是应该能够成功获取到的。
而且，即使第二次能够成功获取，那么当第一次释放锁的时候，第二次获取到的锁也会被释放，而这是不合理的。
例如将代码改成如下：

@Override
public void run() {
    slock.lock(); //上锁
    slock.lock(); //再次获取自己的锁！由于不可重入，则会陷入循环
    for (int i = 0; i < 10; i++) {
        //Thread.yield();
        System.out.println(i);
    }
    slock.unlock();
}

则运行结果将会无限打印，陷入无终止的循环！
为了实现可重入锁，我们需要引入一个计数器，用来记录获取锁的线程数。

public class ReentrantSpinLock {
    private AtomicReference<Thread> cas = new AtomicReference<Thread>();
    private int count;
    public void lock() {
        Thread current = Thread.currentThread();
        if (current == cas.get()) { // 如果当前线程已经获取到了锁，线程数增加一，然后返回
            count++;
            return;
        }
        // 如果没获取到锁，则通过CAS自旋
        while (!cas.compareAndSet(null, current)) {
            // DO nothing
        }
    }
    public void unlock() {
        Thread cur = Thread.currentThread();
        if (cur == cas.get()) {
            if (count > 0) {// 如果大于0，表示当前线程多次获取了该锁，释放锁通过count减一来模拟
                count--;
            } else {// 如果count==0，可以将锁释放，这样就能保证获取锁的次数与释放锁的次数是一致的了。
                cas.compareAndSet(cur, null);
            }
        }
    }
}

这里就实现了可重入锁然后你加锁次数同时也需要你解锁次数。

//可重入自旋锁验证
class Task1 implements Runnable{
    private AtomicReference<Thread> cas;
    private ReentrantSpinLock slock ;
    public Task1(AtomicReference<Thread> cas) {
        this.cas = cas;
        this.slock = new ReentrantSpinLock(cas);
    }
    @Override
    public void run() {
        slock.lock(); //上锁
        slock.lock(); //再次获取自己的锁！没问题！
        for (int i = 0; i < 10; i++) {
            //Thread.yield();
            System.out.println(i);
        }
        slock.unlock(); //释放一层，但此时count为1，不为零，导致另一个线程依然处于忙循环状态，所以加锁和解锁一定要对应上，避免出现另一个线程永远拿不到锁的情况
        slock.unlock();
    }
}

3.5、总结

• 自旋锁：线程获取锁的时候，如果锁被其他线程持有，则当前线程将循环等待，直到获取到锁。
• 自旋锁等待期间，线程的状态不会改变，线程一直是用户态并且是活动的(active)。
• 自旋锁如果持有锁的时间太长，则会导致其它等待获取锁的线程耗尽CPU。
• 自旋锁本身无法保证公平性，同时也无法保证可重入性。

• 基于自旋锁，可以实现具备公平性和可重入性质的锁

  4、可重入锁

  4.1、什么是可重入锁？

• 同一个线程可以重入上锁的代码段，不同的线程则需要进行阻塞

• Java的可重入锁有:ReentrantLock（显式的可重入锁）、synchronized（隐式的可重入锁）
• 可重入锁的最大作用是避免死锁
• 同步锁可以再次进入（同一个线程）

synchronized 是隐式锁，Lock是显式锁
即synchronized 加锁解锁自动完成
Lock加锁解锁要手动完成

就比如锁方法A上锁lock而方法B也上锁lock,并且在方法A中调用方法B，不会出现死锁的情况，因为它们处于同一个线程用的是同一把锁，所以可重入锁运行再次进入。也可以叫递归锁。
可重入，即一个线程可以多次（重复）进入同类型的锁而不出现异常（死锁），这里的死锁：自己等待自己释放再获取，所以无限循环。相当于如果不同方法用同一个锁，但是线程还是同一个线程的话，会造成死锁，，如果实现可重入锁的话就不会出现死锁。只需要加锁和解锁的次数相同就行。
如：同一线程，执行逻辑中，嵌套获执行多个synchronized代码块或者嵌套执行ReentrantLock代码块。

为什么需要死锁：最大程度避免死锁。

可重入锁是一种技术： 任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞。
可重入锁的原理： 通过组合自定义同步器来实现锁的获取与释放。
再次获取锁：识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取。获取锁后，进行计数自增，释放锁：释放锁时，进行计数自减。
Java中的可重入锁： ReentrantLock、synchronized修饰的方法或代码段。
可重入锁的作用： 避免死锁。

4.2、可重入锁的实现

synchronized的可重入锁的实现方式。

package com.test.reen;
// 演示可重入锁是什么意思，可重入，就是可以重复获取相同的锁，synchronized和ReentrantLock都是可重入的
// 可重入降低了编程复杂性
public class WhatReentrant {
    public static void main(String[] args) {
        new Thread(new Runnable() {
            @Override
            public void run() {
                synchronized (this) {
                    System.out.println("第1次获取锁，这个锁是：" + this);
                    int index = 1;
                    while (true) {
                        synchronized (this) {
                            // 进行计数
                            System.out.println("第" + (++index) + "次获取锁，这个锁是：" + this);
                        }
                        if (index == 10) {
                            break;
                        }
                    }
                }
            }
        }).start();
    }
}

ReentrantLock锁的实现方式。

package com.test.reen;
import java.util.Random;
import java.util.concurrent.locks.ReentrantLock;
// 演示可重入锁是什么意思
public class WhatReentrant2 {
    public static void main(String[] args) {
        ReentrantLock lock = new ReentrantLock();
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    lock.lock();
                    System.out.println("第1次获取锁，这个锁是：" + lock);
                    int index = 1;
                    while (true) {
                        try {
                            lock.lock();
                            System.out.println("第" + (++index) + "次获取锁，这个锁是：" + lock);
                            try {
                                Thread.sleep(new Random().nextInt(200));
                            } catch (InterruptedException e) {
                                e.printStackTrace();
                            }
                            if (index == 10) {
                                break;
                            }
                        } finally {
                            lock.unlock();
                        }
                    }
                } finally {
                    lock.unlock();
                }
            }
        }).start();
    }
}

其实实现方式很相似，只不过ReentrantLock的锁方法比较多。
ReentrantLock 和 synchronized 不一样，需要手动释放锁，所以使用 ReentrantLock的时候一定要手动释放锁，并且加锁次数和释放次数要一样
以下代码演示，加锁和释放次数不一样导致的死锁

package com.test.reen;
import java.util.Random;
import java.util.concurrent.locks.ReentrantLock;
public class WhatReentrant3 {
    public static void main(String[] args) {
        ReentrantLock lock = new ReentrantLock();
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    lock.lock();
                    System.out.println("第1次获取锁，这个锁是：" + lock);
                    int index = 1;
                    while (true) {
                        try {
                            lock.lock();
                            System.out.println("第" + (++index) + "次获取锁，这个锁是：" + lock);
                            try {
                                Thread.sleep(new Random().nextInt(200));
                            } catch (InterruptedException e) {
                                e.printStackTrace();
                            }
                            if (index == 10) {
                                break;
                            }
                        } finally {
//                            lock.unlock();// 这里故意注释，实现加锁次数和释放次数不一样
                        }
                    }
                } finally {
                    lock.unlock();
                }
            }
        }).start();
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    lock.lock();
                    for (int i = 0; i < 20; i++) {
                        System.out.println("threadName:" + Thread.currentThread().getName());
                        try {
                            Thread.sleep(new Random().nextInt(200));
                        } catch (InterruptedException e) {
                            e.printStackTrace();
                        }
                    }
                } finally {
                    lock.unlock();
                }
            }
        }).start();
    }
}

由于加锁次数和释放次数不一样，第二个线程始终无法获取到锁，导致一直在等待。
稍微改一下，在外层的finally里头释放9次，让加锁和释放次数一样，就没问题了

非重入锁也叫自旋锁。

4.3、ReentrantLock锁

4.3.1、ReentrantLock概述

• 提供了无条件的，可轮询的，定时的以及可中断的锁获取操作
• 加锁和解锁都是显式的

ReentrantLock是Java中常用的锁，属于乐观锁类型，多线程并发情况下。能保证共享数据安全性，线程间有序性
ReentrantLock通过原子操作和阻塞实现锁原理，一般使用lock获取锁，unlock释放锁，
下面说一下锁的基本使用和底层基本实现原理，lock和unlock底层
lock的时候可能被其他线程获得所，那么此线程会阻塞自己，关键原理底层用到Unsafe类的API: CAS和park

4.3.2、底层实现原理

JAVA的java.util.concurrent框架中提供了ReentrantLock类（于JAVA SE 5.0时引入），ReentrantLock实现了lock接口，具体在JDK中的定义如下：

public class ReentrantLock implements Lock, java.io.Serializable {
 public ReentrantLock() {
        sync = new NonfairSync();
    }
    /**
     * Creates an instance of {@code ReentrantLock} with the
     * given fairness policy.
     *
     * @param fair {@code true} if this lock should use a fair ordering policy
     */
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }
}

所以该锁可以实现公平所和非公平锁，默认是非公平锁第一步是新建锁对象。由源码可知，ReentrantLock默认情况是非公平锁，即通过NonfairSync创建非公平锁同步对象。
java.util.concurrent.locks.ReentrantLock#ReentrantLock()。
可以通过构造器实现创建公平锁的ReentrantLock可重入锁。
看到一个类首先就需要知道它的构造方法有哪些，ReentrantLock有两个构造方法，一个是无参的ReentrantLock() ；另一个含有布尔参数public ReentrantLock(boolean fair)。后面一个构造函数说明ReentrantLock可以新建公平锁；而Synchronized只能建立非公平锁。

Lock接口的方法

Lock接口中有lock和unlock方法，还有newCondition() 方法，这就是上面说的ReentrantLock里面设置内部Condititon类。由于ReentrantLock实现了Lock接口，因此它必须实现该方法，具体如下：

  public Condition newCondition() {
        return sync.newCondition();
    }

ReentrantLock主要用到unsafe的CAS和park两个功能实现锁（CAS + park ）

多个线程同时操作一个数N，使用原子（CAS）操作，原子操作能保证同一时间只能被一个线程修改，而修改数N成功后，返回true，其他线程修改失败，返回false，
这个原子操作可以定义线程是否拿到锁，返回true代表获取锁，返回false代表为没有拿到锁。 拿到锁的线程，自然是继续执行后续逻辑代码，而没有拿到锁的线程，则调用park，将线程（自己）阻塞。 线程阻塞需要其他线程唤醒，ReentrantLock中用到了链表用于存放等待或者阻塞的线程，每次线程阻塞，先将自己的线程信息放入链表尾部，再阻塞自己；之后需要拿到锁的线程，在调用unlock 释放锁时，从链表中获取阻塞线程，调用unpark 唤醒指定线程

底层实现的双向链表来实现阻塞线程，链表的头结点为空，就是当前获取到锁的线程结点，但是线程部分是在为空声明该线程是出队列，当前获取锁的线程，后面有个第一位排队的结点会判断prev结点是否为空，如果为空的话就会执行自旋判断是否能够获取到锁。

AQS队列

1、非公平锁NonfairSync

java.util.concurrent.locks.ReentrantLock.NonfairSync
通过NonfairSync创建非公平锁对象，NonfairSync继承Sync，实现lock方法，这个lock方法就是可重入锁实现可重入的入口。
由这个lock方法可知，先进入的逻辑是CAS，如果CAS失败，则执行acquire(1)，这个acquire是可重入的入口，即通过acquire实现可重入。
重入过程：
（1）线程t1，第一次获取锁x.lock()，CAS成功，嵌套调用，第二次获取锁x.lock()时，CAS失败。
（2）第二次CAS失败后，会执行acquire(1)，实现重入。忽略线程中断，并使当前线程持有锁的次数+1，保证逻辑正常执行。
为什么第二次CAS失败：因为第一次已经CAS了，内存数据已经发生了改变，变为1，所以第二次CAS(0,1)时，0≠1，因此失败。
接下来需要解析acquire(1)方法。

执行步骤：

1. CAS原子性的修改AbstractQueuedSynchronizer#state的值，由0改为1，成功则说明当前线程加锁成功.
2. 设置AbstractOwnableSynchronizer#exclusiveOwnerThread的值为当前线程，表示当前锁的拥有者是当前线程。(前两步是当前线程还未获得当前锁的时候，当前时候尝试获取锁的代码块)
3. 如果1中修改失败，则进入acquire(1)。申请1个state，acquire方法中首先尝试获取锁tryAcquire()，如果获取失败，则将当前线程以独占模式Node.EXCLUSIVE加入等待队列尾部（addWaiter方法）。
4. acquireQueued()：以独占无中断模式获取锁，这个方法会一直无限循环，直到获取到资源或者被中断才返回。如果等待过程中被中断则返回true。这里有自旋锁的意思，加入队列中的线程，不断的重试检测是否可以执行任务。（这两个就是还未获取到锁，加入阻塞队列）

   2、acquire

   java.util.concurrent.locks.AbstractQueuedSynchronizer#acquire
   acquire重入逻辑的入口。
   在acquire中有两个过程，即tryAcquire和acquireQueued。
   其中，
   （1）tryAcquire是可重入的入口，实现当前线程的锁持有数自增，并且返回true，保证不会触发线程中断selfInterrupt()；
   （2）acquireQueued则是轮询获取已在队列中的线程，进一步判断，同一线程是否在队列，保证不会中断当前线程。返回false，保证不会触发线程中断selfInterrupt()。不过获取前，有一个入队的操作：addWaiter。
   因为判断的逻辑为：if(!tryAcquire(…)&&acquireQueued(…))，所以，返回true，不会触发。
   好了，下面需要进入tryAcquire看看如何实现。
   
   这里就是实现为线程入队，插入链表的实现。

3、nonFairTryAcquire

tryAcquire的具体实现是在NonfairSync类中，然后调用其父类Sync 中的nonfairTryAcquire（）方法。
java.util.concurrent.locks.ReentrantLock.Sync#nonfairTryAcquire
使当前线程持有锁的次数+1，保证逻辑正常执行。
进入该方法，可知，首先获取state，因为第一次获取锁后，state=1，
此时，会进入else if的逻辑，同一线程，则保证：current == getExclusiveOwnerThread()为true，
所以，此时，会将当前线程持有锁的次数+1，即next = c + acquires
当然了，释放锁的时候，也要逐步释放。

static final class NonfairSync extends Sync {
    protected final boolean tryAcquire(int acquires) {
        return nonfairTryAcquire(acquires);
    }
}
final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();//:1、获取volatile int state的值
    if (c == 0) {//2：state=0表示当前可以加锁
        if (compareAndSetState(0, acquires)) {//CAS将state设置为acquires的值
            setExclusiveOwnerThread(current);//设置当前拥有锁的线程
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {//当前锁的拥有者线程是currentThread
        int nextc = c + acquires;//将state累加上acquires
        if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
        setState(nextc);//设置state的值。由于这里只有获取锁的线程才能执行，所以不会出现并发，不需要额外的加锁处理
        //这也是ReentrantLock为什么是可重入锁的原因，同一个线程加多次锁（lock.lock）也就是给state的值累加而已。
        return true;
    }
    return false;//当前锁的拥有者线程不是currentThread，直接返回false，也就是获取锁失败
}

• nonfairTryAcquire的实现：如果当前没有锁，那么加锁。如果已经有了锁，那么看看当前锁的拥有者线程是不是currentThread，是则累加state的值，不是则返回失败。
• 所以，使用ReentrantLock时，线程获得锁的标记是在state上的，state=0表示没有被加锁，state=1表示加锁成功，state>1表示锁重入。

4、addWaiter

这是什么操作？

• 按照指定模式（独占还是共享）将节点添加到等待队列。

将线程放入队列。填充队列prev和tail，这里，填充了prev才能保证后面的方法acquireQueued返回true。
java.util.concurrent.locks.AbstractQueuedSynchronizer#addWaiter

private Node addWaiter(Node mode) {
    Node node = new Node(Thread.currentThread(), mode);
    //1、首先尝试以快速方式添加到队列末尾
    Node pred = tail;//pred指向现有tail末尾节点
    if (pred != null) {
    //新加入节点的前一个节点是现有AQS队列的tail节点
        node.prev = pred;
          //CAS原子性的修改tail节点
        if (compareAndSetTail(pred, node)) {    
            //修改成功，新节点成功加入AQS队列，pred节点的next节点指向新的节点
            pred.next = node;
            return node;
        }
    }
    //2、pred为空，或者修改tail节点失败，
    //则走enq方法将节点插入队列
    enq(node);
    return node;
}
private Node enq(final Node node) {
    for(;;) {//CAS
        Node t = tail;
        if (t == null) { 
        // 必须初始化。这里是AQS队列为空的情况。
        //通过CAS的方式创建head节点，并且tail和head都指向
        //同一个节点。
            if (compareAndSetHead(new Node()))
            //注意这里初始化head节点，并不关联任何线程！！
                tail = head;
        } else {
        //这里变更node节点的prev指针，并且移动tail指针指向node，
        //前一个节点的next指向新插入的node
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}

• addWaiter首先会以快速方式将node添加到队尾，如果失败则走enq方法。失败有两种可能，一个是tail为空，也就是AQS为空的情况下。另一是compareAndSetTail失败，也就是多线程并发添加到队尾，此时会出现CAS失败。

• 注意enq方法，在t==null时，首先创建空的头节点，不关联任何的线程，nextWaiter和thread变量都是null。

  5、acquireQueued

• tryAcquire失败没有获取到锁，addWaiter加入了AQS等待队列，进入acquireQueued方法中，acquireQueued方法以独占无中断模式获取锁，这个方法会一直无限循环，直到获取到资源或者被中断才返回。

进一步确认当前线程在队列，而不强行中断，保证线程正常执行。
java.util.concurrent.locks.AbstractQueuedSynchronizer#acquireQueued

final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;//是否获取到资源
    try {
        boolean interrupted = false;//是否中断
        for (;;) {
            //获取前一个节点
            final Node p = node.predecessor();
            //如果当前node节点是第二个节点，紧跟在head后面，
            //那么tryAcquire尝试获取资源
            if (p == head && tryAcquire(arg)) {                
                setHead(node);//获取锁成功，当前节点成为head节点
                p.next = null; // 目的：辅助GC，next为空说明当前节点出队列就可以进行gc
                failed = false;
                return interrupted;//返回是否中断过
            }
            //当shouldParkAfterFailedAcquire返回成功，
            //也就是前驱节点是Node.SIGNAL状态时，
            //进行真正的park将当前线程挂起，并且检查中断标记，
            //如果是已经中断，则设置interrupted =true。
            //如果shouldParkAfterFailedAcquire返回false，
            //则重复上述过程，直到获取到资源或者被park。
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);//添加AQS失败，取消任务
    }
}
//前面讲过，head节点不与任何线程关联，他的thread是null，
//当然head节点的prev肯定也是null
private void setHead(Node node) {
    head = node;
    node.thread = null;
    node.prev = null;
}
//在Acquire失败后，是否要park中断
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    int ws= pred.waitStatus;//获取到上一个节点的waitStatus
    if (ws == Node.SIGNAL)//前面讲到当一个节点状态时SIGNAL时，
    //他有责任唤醒后面的节点。所以这里判断前驱节点是SIGNAL状态，
    //则可以安心的park中断了。
        return true;
    if (ws > 0) {
        /*
         * 过滤掉中间cancel状态的节点
         * 前驱节点被取消的情况（线程允许被取消哦）。向前遍历，
         * 直到找到一个waitStatus大于0的（不是取消状态或初始状态）
         * 的节点，该节点设置为当前node的前驱节点。
         */
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0);
        pred.next = node;
    } else {
        /*
         * 修改前驱节点的WaitStatus为Node.SIGNAL。
         * 明确前驱节点必须为Node.SIGNAL，当前节点才可以park 
         * 注意，这个CAS也可能会失败，因为前驱节点的WaitStatus状态
         * 可能会发生变化
         */
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}
//阻塞当前线程
//park并且检查是否被中断过
private final boolean parkAndCheckInterrupt() {
    LockSupport.park(this);
    return Thread.interrupted();
}

4.3.3、总结

可重入，即一个线程可以多次（重复）进入同类型的锁而不出现异常（死锁）；
ReentrantLock提供两类锁：公平锁和非公平锁；
可重入是因为可重锁lock中核心逻辑：如果CAS，成功，则继续执行设置独占，setExclusiveOwnerThread；CAS失败，进入可重入逻辑；
可重入执行逻辑入口：acquire(…)，java.util.concurrent.locks.AbstractQueuedSynchronizer#acquire
可重入的核心三个操作：
（1）addWaiter：线程入队；
（2）acquireQueued：确认线程在队列中，不中断线程，返回false；
（3）tryAcquire：同一线程获取锁次数+1，不中断线程，返回true；
保证线程不中断：if(!tryAcquire(…)&&acquireQueued)。

4.3.4、ReentrantLock和synchronized的区别

可重入性：
从名字上理解，ReenTrantLock的字面意思就是再进入的锁，其实synchronized关键字所使用的锁也是可重入的，两者关于这个的区别不大。
两者都是同一个线程没进入一次，锁的计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。
锁的实现：
Synchronized是依赖于JVM实现的，而ReenTrantLock是JDK实现的，有什么区别，说白了就类似于操作系统来控制实现和用户自己敲代码实现的区别。前者的实现是比较难见到的，后者有直接的源码可供阅读。
性能的区别：
在Synchronized优化以前，synchronized的性能是比ReenTrantLock差很多的，但是自从Synchronized引入了偏向锁，轻量级锁（自旋锁）后，两者的性能就差不多了。
在两种方法都可用的情况下，官方甚至建议使用synchronized，其实synchronized的优化我感觉就借鉴了ReenTrantLock中的CAS技术。都是试图在用户态就把加锁问题解决，避免进入内核态的线程阻塞。
功能区别：
便利性：很明显Synchronized的使用比较方便简洁，并且由编译器去保证锁的加锁和释放，而ReenTrantLock需要手工声明来加锁和释放锁，为了避免忘记手工释放锁造成死锁，所以最好在finally中声明释放锁。
锁的细粒度和灵活度：很明显ReenTrantLock优于Synchronized
ReenTrantLock独有的能力：
1.ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。
2.ReenTrantLock提供了一个Condition（条件）类，用来实现分组唤醒需要唤醒的线程们，而不是像synchronized要么随机唤醒一个线程要么唤醒全部线程。
3.ReenTrantLock提供了一种能够中断等待锁的线程的机制，通过lock.lockInterruptibly()来实现这个机制。
ReenTrantLock实现的原理：
在网上看到相关的源码分析，本来这块应该是本文的核心，但是感觉比较复杂就不一一详解了，简单来说，ReenTrantLock的实现是一种自旋锁，通过循环调用CAS操作来实现加锁。
它的性能比较好也是因为避免了使线程进入内核态的阻塞状态。想尽办法避免线程进入内核的阻塞状态是我们去分析和理解锁设计的关键钥匙。
什么情况下使用ReenTrantLock：
答案是，如果你需要实现ReenTrantLock的三个独有功能时。

面试题1： 可重入锁如果加了两把，但是只释放了一把会出现什么问题？
答：程序卡死，线程不能出来，也就是说我们申请了几把锁，就需要释放几把锁。
面试题2： 如果只加了一把锁，释放两次会出现什么问题？答：会报错，
java.lang.IllegalMonitorStateException。

5、读写锁

ReentrantReadWriteLock，CopyOnWriteArrayList、CopyOnWriteArraySet

5.1、读写锁概述

读写锁是一种技术： 通过ReentrantReadWriteLock类来实现。为了提高性能， Java提供了读写锁，在读的地方使用读锁，在写的地方使用写锁，灵活控制，如果没有写锁的情况下，读是无阻塞的，在一定程度上提高了程序的执行效率。 读写锁分为读锁和写锁，多个读锁不互斥，读锁与写锁互斥，这是由 jvm 自己控制的。
对于多个线程共享同一个资源的时候，多个线程同时对共享资源做读操作是不会发生线程安全性问题的，但是一旦有一个线程对共享数据做写操作其他的线程再来读写共享资源的话，就会发生数据安全性问题，所以出现了读写锁ReentrantReadWriteLock。读写锁允许多个线程同时获取读锁，但有一个线程获取写锁之后其他线程都会进入等待队列进行等待。
[

](https://blog.csdn.net/qq_37685457/article/details/89855519)
读锁： 允许多个线程获取读锁，同时访问同一个资源

写锁： 只允许一个线程获取写锁，不允许同时访问同一个资源。

所有读写锁的实现必须确保写操作对读操作的内存影响。换句话说，一个获得了读锁的线程必须能看到前一个释放的写锁所更新的内容。
读写锁比互斥锁允许对于共享数据更大程度的并发。每次只能有一个写线程，但是同时可以有多个线程并发地读数据。ReadWriteLock适用于读多写少的并发情况。

这里读写锁实现的是ReentrantReadWriteLock

5.2、读写锁的实现

/*** 创建一个读写锁* 它是一个读写融为一体的锁，在使用的时候，需要转换*/
private ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock();
获取读锁和释放读锁 
// 获取读锁
rwLock.readLock().lock();
// 释放读锁
rwLock.readLock().unlock();
获取写锁和释放写锁 
// 创建一个写锁
rwLock.writeLock().lock();
// 写锁 释放
rwLock.writeLock().unlock();

Java中的读写锁：ReentrantReadWriteLock

5.3、ReentrantReadWriteLock

5.3.1、概述

ReentrantReadWriteLock是Lock的另一种实现方式，我们已经知道了ReentrantLock是一个排他锁，同一时间只允许一个线程访问，而ReentrantReadWriteLock允许多个读线程同时访问，但不允许写线程和读线程、写线程和写线程同时访问。相对于排他锁，提高了并发性。在实际应用中，大部分情况下对共享数据（如缓存）的访问都是读操作远多于写操作，这时ReentrantReadWriteLock能够提供比排他锁更好的并发性和吞吐量。
读写锁内部维护了两个锁，一个用于读操作，一个用于写操作。所有 ReadWriteLock实现都必须保证 writeLock操作的内存同步效果也要保持与相关 readLock的联系。也就是说，成功获取读锁的线程会看到写入锁之前版本所做的所有更新。

ReentrantReadWriteLock支持以下功能：
1）支持公平和非公平的获取锁的方式；
2）支持可重入。读线程在获取了读锁后还可以获取读锁；写线程在获取了写锁之后既可以再次获取写锁又可以获取读锁；
3）还允许从写入锁降级为读取锁，其实现方式是：先获取写入锁，然后获取读取锁，最后释放写入锁。但是，从读取锁升级到写入锁是不允许的；
4）读取锁和写入锁都支持锁获取期间的中断；
5）Condition支持。仅写入锁提供了一个 Conditon 实现；读取锁不支持 Conditon ，readLock().newCondition() 会抛出 UnsupportedOperationException。

5.3.2、ReentrantReadWriteLock特性

• 获取顺序
  • 非公平模式（默认）：当以非公平初始化时，读锁和写锁的获取的顺序是不确定的。非公平锁主张竞争获取，可能会延缓一个或多个读或写线程，但是会比公平锁有更高的吞吐量。
  • 公平模式：当以公平模式初始化时，线程将会以队列的顺序获取锁。当当前线程释放锁后，等待时间最长的写锁线程就会被分配写锁；或者有一组读线程组等待时间比写线程长，那么这组读线程组将会被分配读锁。当有写线程持有写锁或者有等待的写线程时，一个尝试获取公平的读锁（非重入）的线程就会阻塞。这个线程直到等待时间最长的写锁获得锁后并释放掉锁后才能获取到读锁。
• 可重入

允许读锁可写锁可重入。写锁可以获得读锁，读锁不能获得写锁。

• 锁降级

允许写锁降低为读锁

• 中断锁的获取

在读锁和写锁的获取过程中支持中断

• 支持Condition

写锁提供Condition实现

• 监控

提供确定锁是否被持有等辅助方法

5.3.3、实现

下面一段代码展示了锁降低的操作：

class CachedData {
   //被缓存的具体对象
   Object data;
   //当前对象是否可用，使用volatile来保证可见性
   volatile boolean cacheValid;
   //今天的主角，ReentrantReadWriteLock 
   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.
         //经典处理之二，在独占锁内部要处理数据时，一定要做二次校验
         //因为可能同时有多个线程全都在获取写锁，
         //当时线程1释放写锁之后，线程2马上获取到写锁，此时如果不做二次校验那可能就导致某些操作做了多次
         if (!cacheValid) {
           data = ...
           //当缓存对象更新成功后，重置标记为true
           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();
     }
   }
 }

5.3.4、底层实现

读写锁的读锁原理：
如果有线程想申请读锁的话，首先会判断写锁是否被持有，如果写锁被持有且当前线程并不是持有写锁的线程，那么就会返回-1，获取锁失败，进入到等待队列等待。如果写锁未被线程所持有或者当前线程和持有写锁的线程是同一线程的话就会开始获取读锁。线程首先会判断读锁的数量是否超过65535个，如果没超过就CAS修改state变量的高16位的值，也就是将state的值+1，如果这个步骤失败的话它会循环这个操作，直到成功为止。CAS修改成功之后，代表读锁获取成功，会判断一下当前线程是否是第一次读线程，如果是，就设置第一次多线程和第一次读计数器（为了性能和可重入）。如果不是第一次获取读锁，判断一下是否是与第一次读线程相同，如果与第一次读线程是同一线程就将第一次读计数器+1。如果也不是第一次读线程，判断一下是否是最后一次读线程，如果是就将最后一次读计数器+1。如果都不是，就新建一个计数器，设置最后一次读线程为自己本身线程，然后刷新它的读计数器。

这里哆嗦通过判断是否可以分享否则入阻塞队列

protected final int11 tryAcquireShared(int unused) {
    Thread current = Thread.currentThread();
    int c = getState();
    // exclusiveCount(c) != 0 ---》 用 state & 65535 得到低 16 位的值。如果不是0，说明写锁别持有了。
    // getExclusiveOwnerThread() != current----> 不是当前线程
    // 如果写锁被霸占了，且持有线程不是当前线程，返回 false，加入队列。获取写锁失败。
    // 反之，如果持有写锁的是当前线程，就可以继续获取读锁了。
    if (exclusiveCount(c) != 0 && getExclusiveOwnerThread() != current)
        // 获取锁失败
        return -1;
    // 如果写锁没有被霸占，则将高16位移到低16位。
    int r = sharedCount(c);// c >>> 16
    // !readerShouldBlock() 和写锁的逻辑一样（根据公平与否策略和队列是否含有等待节点）
    // 不能大于 65535，且 CAS 修改成功
    if (!readerShouldBlock() && r < 65535 && compareAndSetState(c, c + 65536)) {
        // 如果读锁是空闲的， 获取锁成功。
        if (r == 0) {
            // 将当前线程设置为第一个读锁线程
            firstReader = current;
            // 计数器为1
            firstReaderHoldCount = 1;
        }// 如果读锁不是空闲的，且第一个读线程是当前线程。获取锁成功。
         else if (firstReader == current) {// 
            // 将计数器加一
            firstReaderHoldCount++;
        } else {// 如果不是第一个线程，获取锁成功。
            // cachedHoldCounter 代表的是最后一个获取读锁的线程的计数器。
            HoldCounter rh = cachedHoldCounter;
            // 如果最后一个线程计数器是 null 或者不是当前线程，那么就新建一个 HoldCounter 对象
            if (rh == null || rh.tid != getThreadId(current))
                // 给当前线程新建一个 HoldCounter ------>详见下图get方法
                cachedHoldCounter = rh = readHolds.get();
            // 如果不是 null，且 count 是 0，就将上个线程的 HoldCounter 覆盖本地的。
            else if (rh.count == 0)
                readHolds.set(rh);
            // 对 count 加一
            rh.count++;
        }
        return 1;
    }
    // 死循环获取读锁。包含锁降级策略。
    return fullTryAcquireShared(current);
}

ReentrantReadWriteLock 也是基于AQS实现的，它的自定义同步器（继承AQS）需要在同步状态（一个整型变量state）上维护多个读线程和一个写线程的状态，使得该状态的设计成为读写锁实现的关键。如果在一个整型变量上维护多种状态，就一定需要“按位切割使用”这个变量，读写锁将变量切分成了两个部分，高16位表示读，低16位表示写。
ReentrantReadWriteLock含有两把锁readerLock和writerLock，其中ReadLock和WriteLock都是内部类。

/** Inner class providing readlock */
private final ReentrantReadWriteLock.ReadLock readerLock;
/** Inner class providing writelock */
private final ReentrantReadWriteLock.WriteLock writerLock;
/** Performs all synchronization mechanics */
final Sync sync;

写锁的获取与释放（WriteLock）
写锁是一个可重入的独占锁，使用AQS提供的独占式获取同步状态的策略。

//获取写锁
public void lock() {
    sync.acquire(1);
}
//AQS实现的独占式获取同步状态方法
public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}
//自定义重写的tryAcquire方法
protected final boolean tryAcquire(int acquires) {
    /*
     * Walkthrough:
     * 1. If read count nonzero or write count nonzero
     *    and owner is a different thread, fail.
     * 2. If count would saturate, fail. (This can only
     *    happen if count is already nonzero.)
     * 3. Otherwise, this thread is eligible for lock if
     *    it is either a reentrant acquire or
     *    queue policy allows it. If so, update state
     *    and set owner.
     */
    Thread current = Thread.currentThread();
    int c = getState();
    int w = exclusiveCount(c);    //取同步状态state的低16位，写同步状态
    if (c != 0) {
        // (Note: if c != 0 and w == 0 then shared count != 0)
        //存在读锁或当前线程不是已获取写锁的线程，返回false
        if (w == 0 || current != getExclusiveOwnerThread())
            return false;
        //判断同一线程获取写锁是否超过最大次数，支持可重入
        if (w + exclusiveCount(acquires) > MAX_COUNT)    //
            throw new Error("Maximum lock count exceeded");
        // Reentrant acquire
        setState(c + acquires);
        return true;
    }
    //此时c=0,读锁和写锁都没有被获取
    if (writerShouldBlock() ||
        !compareAndSetState(c, c + acquires))
        return false;
    setExclusiveOwnerThread(current);
    return true;
}

高16位是保存读线程的数量

从源代码可以看出，获取写锁的步骤如下：
1）判断同步状态state是否为0。如果state!=0，说明已经有其他线程获取了读锁或写锁，执行2）；否则执行5）。
2）判断同步状态state的低16位（w）是否为0。如果w=0，说明其他线程获取了读锁，返回false；如果w!=0，说明其他线程获取了写锁，执行步骤3）。
3）判断获取了写锁是否是当前线程，若不是返回false，否则执行4）；
4）判断当前线程获取写锁是否超过最大次数，若超过，抛异常，反之更新同步状态（此时当前线程以获取写锁，更新是线程安全的），返回true。
5）此时读锁或写锁都没有被获取，判断是否需要阻塞（公平和非公平方式实现不同），如果不需要阻塞，则CAS更新同步状态，若CAS成功则返回true，否则返回false。如果需要阻塞则返回false。
writerShouldBlock() 表示当前线程是否应该被阻塞。NonfairSync和FairSync中有不同是实现。

//FairSync中需要判断是否有前驱节点，如果有则返回false，否则返回true。遵循FIFO
final boolean writerShouldBlock() {
    // 将线程插入阻塞队列
    return hasQueuedPredecessors();
}
//NonfairSync中直接返回false，可插队。
final boolean writerShouldBlock() {
    return false; // writers can always barge
}

//写锁释放
public void unlock() {
    sync.release(1);
}
//AQS提供独占式释放同步状态的方法
public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);
        return true;
    }
    return false;
}
//自定义重写的tryRelease方法
protected final boolean tryRelease(int releases) {
    if (!isHeldExclusively())
        throw new IllegalMonitorStateException();
    int nextc = getState() - releases;    //同步状态减去releases
    //判断同步状态的低16位（写同步状态）是否为0，如果为0则返回true，否则返回false.
    //因为支持可重入
    boolean free = exclusiveCount(nextc) == 0;
    if (free)
        setExclusiveOwnerThread(null);
    setState(nextc);    //以获取写锁，不需要其他同步措施，是线程安全的
    return free;
}

读锁的获取与释放（ReadLock）
读锁是一个可重入的共享锁，采用AQS提供的共享式获取同步状态的策略。

public void lock() {
    sync.acquireShared(1);
}
//使用AQS提供的共享式获取同步状态的方法
public final void acquireShared(int arg) {
    if (tryAcquireShared(arg) < 0)
        doAcquireShared(arg);
}
//自定义重写的tryAcquireShared方法，参数是unused，因为读锁的重入计数是内部维护的
protected final int tryAcquireShared(int unused) {
    /*
     * Walkthrough:
     * 1. If write lock held by another thread, fail.
     * 2. Otherwise, this thread is eligible for
     *    lock wrt state, so ask if it should block
     *    because of queue policy. If not, try
     *    to grant by CASing state and updating count.
     *    Note that step does not check for reentrant
     *    acquires, which is postponed to full version
     *    to avoid having to check hold count in
     *    the more typical non-reentrant case.
     * 3. If step 2 fails either because thread
     *    apparently not eligible or CAS fails or count
     *    saturated, chain to version with full retry loop.
     */
    Thread current = Thread.currentThread();
    int c = getState();
    //exclusiveCount(c)取低16位写锁。存在写锁且当前线程不是获取写锁的线程，返回-1，获取读锁失败。
    if (exclusiveCount(c) != 0 &&
        getExclusiveOwnerThread() != current)
        return -1;
    int r = sharedCount(c);    //取高16位读锁，
    //readerShouldBlock（）用来判断当前线程是否应该被阻塞
    if (!readerShouldBlock() &&
        r < MAX_COUNT &&    //MAX_COUNT为获取读锁的最大数量，为16位的最大值
        compareAndSetState(c, c + SHARED_UNIT)) {
        //firstReader是不会放到readHolds里的, 这样，在读锁只有一个的情况下，就避免了查找readHolds。
        if (r == 0) {    // 是 firstReader，计数不会放入  readHolds。
            firstReader = current;
            firstReaderHoldCount = 1;
        } else if (firstReader == current) {    //firstReader重入
            firstReaderHoldCount++;
        } else {
            // 非 firstReader 读锁重入计数更新
            HoldCounter rh = cachedHoldCounter;    //读锁重入计数缓存，基于ThreadLocal实现
            if (rh == null || rh.tid != current.getId())
                cachedHoldCounter = rh = readHolds.get();
            else if (rh.count == 0)
                readHolds.set(rh);
            rh.count++;
        }
        return 1;
    }
    //第一次获取读锁失败，有两种情况：
    //1）没有写锁被占用时，尝试通过一次CAS去获取锁时，更新失败（说明有其他读锁在申请）
    //2）当前线程占有写锁，并且有其他写锁在当前线程的下一个节点等待获取写锁，除非当前线程的下一个节点被取消，否则fullTryAcquireShared也获取不到读锁
    return fullTryAcquireShared(current);
}

从源代码可以看出，获取读锁的大致步骤如下：
1）通过同步状态低16位判断，如果存在写锁且当前线程不是获取写锁的线程，返回-1，获取读锁失败；否则执行步骤2）。
2）通过readerShouldBlock判断当前线程是否应该被阻塞，如果不应该阻塞则尝试CAS同步状态；否则执行3）。
3）第一次获取读锁失败，通过fullTryAcquireShared再次尝试获取读锁。
readerShouldBlock方法用来判断当前线程是否应该被阻塞，NonfairSync和FairSync中有不同是实现。

//FairSync中需要判断是否有前驱节点，如果有则返回false，否则返回true。遵循FIFO
final boolean readerShouldBlock() {
    return hasQueuedPredecessors();
}
final boolean readerShouldBlock() {
    return apparentlyFirstQueuedIsExclusive();
}
//当head节点不为null且head节点的下一个节点s不为null且s是独占模式（写线程）且s的线程不为null时，返回true。
//目的是不应该让写锁始终等待。作为一个启发式方法用于避免可能的写线程饥饿，这只是一种概率性的作用，因为如果有一个等待的写线程在其他尚未从队列中出队的读线程后面等待，那么新的读线程将不会被阻塞。
final boolean apparentlyFirstQueuedIsExclusive() {
    Node h, s;
    return (h = head) != null &&
        (s = h.next)  != null &&
        !s.isShared()         &&
        s.thread != null;
}

fullTryAcquireShared方法

final int fullTryAcquireShared(Thread current) {
    /*
     * This code is in part redundant with that in
     * tryAcquireShared but is simpler overall by not
     * complicating tryAcquireShared with interactions between
     * retries and lazily reading hold counts.
     */
    HoldCounter rh = null;
    for (;;) {
        int c = getState();
        //如果当前线程不是写锁的持有者，直接返回-1，结束尝试获取读锁，需要排队去申请读锁
        if (exclusiveCount(c) != 0) {
            if (getExclusiveOwnerThread() != current)
                return -1;
            // else we hold the exclusive lock; blocking here
            // would cause deadlock.
        //如果需要阻塞，说明除了当前线程持有写锁外，还有其他线程已经排队在申请写锁，故，即使申请读锁的线程已经持有写锁（写锁内部再次申请读锁，俗称锁降级）还是会失败，因为有其他线程也在申请写锁，此时，只能结束本次申请读锁的请求，转而去排队，否则，将造成死锁。
        } else if (readerShouldBlock()) {
            // Make sure we're not acquiring read lock reentrantly
            if (firstReader == current) {
                //如果当前线程是第一个获取了写锁，那其他线程无法申请写锁
                // assert firstReaderHoldCount > 0;
            } else {
                //从readHolds中移除当前线程的持有数，然后返回-1，然后去排队获取读锁。
                if (rh == null) {
                    rh = cachedHoldCounter;
                    if (rh == null || rh.tid != current.getId()) {
                        rh = readHolds.get();
                        if (rh.count == 0)
                            readHolds.remove();
                    }
                }
                if (rh.count == 0)
                    return -1;
            }
        }
        if (sharedCount(c) == MAX_COUNT)
            throw new Error("Maximum lock count exceeded");
        if (compareAndSetState(c, c + SHARED_UNIT)) {
            //示成功获取读锁，后续就是更新readHolds等内部变量，
            if (sharedCount(c) == 0) {
                firstReader = current;
                firstReaderHoldCount = 1;
            } else if (firstReader == current) {
                firstReaderHoldCount++;
            } else {
                if (rh == null)
                    rh = cachedHoldCounter;
                if (rh == null || rh.tid != current.getId())
                    rh = readHolds.get();
                else if (rh.count == 0)
                    readHolds.set(rh);
                rh.count++;
                cachedHoldCounter = rh; // cache for release
            }
            return 1;
        }
    }
}