锁

引入

在项目的开发当中，常常会出现一个方法或者变量多个线程去调用访问的场景，在这里，不管是读取、写入还是其他操作，如何能保证数据的准确性与系统业务的运行效率，Java便提供了种类丰富的锁以应对不同的使用场景，展现出了非常高的效率，总结一下JDK8下面的主流锁。

首先我们先构造一个类似高并发的场景，让大家有个初步的认识，在这里我启动三个线程是尝试对变量count做一个加1操作，每个线程重复运行100次，不加任何锁去保证操作的原子性，整体重复运行10次，看看每次的结果是如何的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public static int TestCAS() {
     for (int i = 0; i < 3; i++) {
         new Thread(
                 new Runnable() {
                     @Override
                     public void run() {
                         try {
                             Thread.sleep(10);
                         } catch (InterruptedException e) {
                             e.printStackTrace();
                         }
                         for(int j = 0; j < 100; j++){
                                 count++;
                         }
                     }
                 }
         ).start();
     }
     try {
         Thread.sleep(2000);
     } catch (InterruptedException e) {
         e.printStackTrace();
     }
     return count;
 }

 //main方法
 public static void main(String[] args) {
     for (int i = 0; i < 10; i++) {
         System.out.println(TestCAS());
         count = 0;
     }
 }

从理论来说我的需求结果应该输出10次300，我们看看真正运行的成果

1
2
3
4
5
6
7
8
9
10
11
运行结果：
300
106
300
300
259
300
201
201
300
300

运行结果还是很差强人意啊，40%数据都是错误的，而且你每次运行结果都不一样哈哈。这就是高并发会出现的问题，我不限制线程去抢夺资源，但是却无法保证每次计算数据的准确性，当然是不可取的，接下来我们慢慢对它优化，让它能够输出正确答案。

乐观锁

乐观锁与悲观锁并不是特指某个锁，而是在并发情况下保证数据完整性的不同策略，其中乐观锁基于冲突检测的方法，检测到冲突时操作就会失败。

CAS

CAS(Compare And Swap)是一种常见的“乐观锁”，它需要有三个操作数：内存地址V，旧值A，新值B。只用当前内存地址V上的值是A，B才会被写道V上，否则操作失败，重试或者异常。

Java从5.0开始引入了对CAS的支持，与之对应的是 java.util.concurrent.atomic 包下的AtomicInteger、Atomic Reference等类，它们提供了基于CAS的读写操作和并发环境下的内存可见性。

以AtomicInteger为例，我们看下底层实现吧：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
//AtomicInteger的增加方法
public final int incrementAndGet() {
    return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}


public final int getAndAddInt(Object var1, long var2, int var4) {
    int var5;
    do {
        var5 = this.getIntVolatile(var1, var2);
        //调用了原生的CAS方法
    } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

    return var5;
}

那我们用用看,对上面方法改进一下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
public static AtomicInteger count = new AtomicInteger(0);

public static int TestCAS() {
    for (int i = 0; i < 3; i++) {
        new Thread(
            new Runnable() {
                @Override
                public void run() {
                    try {
                        Thread.sleep(10);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    for(int j = 0; j < 100; j++){
                        count.incrementAndGet();
                    }
                }
            }
        ).start();
    }
    try {
        Thread.sleep(2000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    return count.get();
}

运行结果：
    300
    300
    300
    300
    300
    300
    300
    300
    300
    300

运行结果是正确的，看来这个方法是可以的，在这里可以看到，我们并没有在方法上加上常规的锁，考虑到线程切换，唤醒的系统开销，在并发量不是很高的场景下，选择乐观锁的效率肯定是比悲观锁效率要高的，但是并发量非常高的情况下是不推荐使用的，这里没有去阻塞线程，而是使其一直自旋，是需要消耗CPU效能的。

乐观锁适合读操作多的场景，锁的持有时间一般很短，不加锁的特点能够使其读操作的性能大幅提升。

ABA问题

乐观锁有什么问题吗，最经典的问题就是ABA问题，什么是ABA问题呢

ABA：如果另一个线程修改V值假设原来是A，先修改成B，再修改回成A。当前线程的CAS操作无法分辨当前V值是否发生过变化。

举一个例子，别人如果挪用了你的钱，在你发现之前又还了回来。钱的总数确实没有变，但是别人却已经触犯了法律

那我们怎么去解决这个问题呢，这里简单说明一下

AtomicStampedReference与Atomic Reference的引入

AtomicInteger只是对整数的封装

AtomicReference类提供了一个可以原子读写的对象引用变量。 原子意味着尝试更改相同AtomicReference的多个线程（例如，使用比较和交换操作）不会使AtomicReference最终达到不一致的状态。 AtomicReference甚至有一个先进的compareAndSet（）方法，它可以将引用与预期值（引用）进行比较，如果它们相等，则在AtomicReference对象内设置一个新的引用。

AtomicStampedReference它内部不仅维护了对象值，还维护了一个时间戳（我这里把它称为时间戳，实际上它可以使任何一个整数，它使用整数来表示状态值）。当AtomicStampedReference对应的数值被修改时，除了更新数据本身外，还必须要更新时间戳。当AtomicStampedReference设置对象值时，对象值以及时间戳都必须满足期望值，写入才会成功。因此，即使对象值被反复读写，写回原值，只要时间戳发生变化，就能防止不恰当的写入。

自旋锁

阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态转换需要耗费处理器时间。如果同步代码块中的内容过于简单，状态转换消耗的时间有可能比用户代码执行的时间还要长。

在许多场景中，同步资源的锁定时间很短，为了这一小段时间去切换线程，线程挂起和恢复现场的花费可能会让系统得不偿失。如果物理机器有多个处理器，能够让两个或以上的线程同时并行执行，我们就可以让后面那个请求锁的线程不放弃CPU的执行时间，看看持有锁的线程是否很快就会释放锁。

而为了让当前线程“稍等一下”，我们需让当前线程进行自旋，如果在自旋完成后前面锁定同步资源的线程已经释放了锁，那么当前线程就可以不必阻塞而是直接获取同步资源，从而避免切换线程的开销。这就是自旋锁。

自旋锁本身是有缺点的，它不能代替阻塞。自旋等待虽然避免了线程切换的开销，但它要占用处理器时间。如果锁被占用的时间很短，自旋等待的效果就会非常好。反之，如果锁被占用的时间很长，那么自旋的线程只会白浪费处理器资源。所以，自旋等待的时间必须要有一定的限度，如果自旋超过了限定次数（默认是10次，可以使用-XX:PreBlockSpin来更改）没有成功获得锁，就应当挂起线程。

自旋锁的实现原理同样也是CAS，AtomicInteger中调用unsafe进行自增操作的源码中的do-while循环就是一个自旋操作，如果修改数值失败则通过循环来执行自旋，直至修改成功。

1
2
3
4
5
6
7
8
9
public final int getAndAddInt(Object var1, long var2, int var4) {
    int var5;
    do {
        var5 = this.getIntVolatile(var1, var2);
        //这里只要返回false就不断的死循环，便是自旋锁
    } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

    return var5;
}
悲观锁

悲观锁，故名思议，总是假设最坏的情况，每次去拿数据的时候逗人为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会直接阻塞知道它拿到锁，传统的数据库的锁机制，Java中的synchronize和ReentrantLock等独占锁就是悲观锁思想的体现。

synchronized

简单介绍一下，synchronized是Java中的关键字，是一种同步锁。它修饰的对象有以下几种：

　　1. 修饰一个代码块，被修饰的代码块称为同步语句块，其作用的范围是大括号{}括起来的代码，作用的对象是调用这个代码块的对象；
　　2. 修饰一个方法，被修饰的方法称为同步方法，其作用的范围是整个方法，作用的对象是调用这个方法的对象；
　　3. 修改一个静态的方法，其作用的范围是整个静态方法，作用的对象是这个类的所有对象；
　　4. 修改一个类，其作用的范围是synchronized后面括号括起来的部分，作用主的对象是这个类的所有对象。

synchronized的底层是使用操作系统的mutex lock实现的。

注意两点：

1、synchronized同步快对同一条线程来说是可重入的，不会出现自己把自己锁死的问题；

2、同步块在已进入的线程执行完之前，会阻塞后面其他线程的进入。

我们试着用synchronized来优化一下代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
public static int count = 0;

public static int TestCAS() {
    for (int i = 0; i < 3; i++) {
        new Thread(
            new Runnable() {
                @Override
                public void run() {
                    try {
                        Thread.sleep(10);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    for(int j = 0; j < 100; j++){
                        synchronized (Example.class){
                            count++;
                        }
                    }
                }
            }
        ).start();
    }
    try {
        Thread.sleep(2000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    return count;
}


运行结果：
    300
    300
    300
    300
    300
    300
    300
    300
    300
    300

同样也是可行的，为什么Synchronized能实现线程同步？
在回答这个问题之前我们需要了解两个重要的概念：“Java对象头”、“Monitor”。

Java对象头

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

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

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

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

Monitor

Monitor可以理解为一个同步工具或一种同步机制，通常被描述为一个对象。每一个Java对象就有一把看不见的锁，称为内部锁或者Monitor锁。

Monitor是线程私有的数据结构，每一个线程都有一个可用monitor record列表，同时还有一个全局的可用列表。每一个被锁住的对象都会和一个monitor关联，同时monitor中有一个Owner字段存放拥有该锁的线程的唯一标识，表示该锁被这个线程占用。

现在话题回到synchronized，synchronized通过Monitor来实现线程同步，Monitor是依赖于底层的操作系统的Mutex Lock（互斥锁）来实现的线程同步。

如同我们在自旋锁中提到的“阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态转换需要耗费处理器时间。如果同步代码块中的内容过于简单，状态转换消耗的时间有可能比用户代码执行的时间还要长”。这种方式就是synchronized最初实现同步的方式，这就是JDK 6之前synchronized效率低的原因。这种依赖于操作系统Mutex Lock所实现的锁我们称之为“重量级锁”，JDK 6中为了减少获得锁和释放锁带来的性能消耗，引入了“偏向锁”和“轻量级锁”。

所以目前锁一共有4种状态，级别从低到高依次是：无锁、偏向锁、轻量级锁和重量级锁。锁状态只能升级不能降级

synchronized特点：保证内存可见性、操作原子性

synchronized影响性能的原因：

  • 1、加锁解锁操作需要额外操作；
  • 2、互斥同步对性能最大的影响是阻塞的实现，因为阻塞涉及到的挂起线程和恢复线程的操作都需要转入内核态中完成（用户态与内核态的切换的性能代价是比较大的）
    锁状态 存储内容
    无锁 对象的hashCode、对象的分代年龄，是否是偏向锁(0) 01
    偏向锁 偏向线程ID、偏向时间戳、对象分代年龄、是否是偏向锁(1) 01
    轻量级锁 指向栈中锁记录的指针 00
    重量级锁 指向互斥量(重量级锁)的指针 10
无锁

无锁没有对资源进行锁定，所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功。

无锁的特点就是修改操作在循环内进行，线程会不断的尝试修改共享资源。如果没有冲突就修改成功并退出，否则就会继续循环尝试。如果有多个线程修改同一个值，必定会有一个线程能修改成功，而其他修改失败的线程会不断重试直到修改成功。上面我们介绍的CAS原理及应用即是无锁的实现。无锁无法全面代替有锁，但无锁在某些场合下的性能是非常高的。

偏向锁

大多数情况下，锁不仅不存在多线程竞争，而且总是有同一个线程多次获得，偏向锁是为了在只有一个线程同步块是提高性能。

当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录路存储锁偏向的线程ID，以后该线程在进入和退出同步块是不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁，引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次的CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令（由于一旦出现多线程竞争的情况就必须撤销偏向锁，所以偏向锁的撤销操作的性能损耗必须小于节省下来的CAS原子指令的性能消耗）。

轻量锁

轻量级锁是为了在线程近乎交替执行同步块时提高性能。其他线程会通过自旋的形式尝试重新获取锁，不会阻塞，从而提高性能。

在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为“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中存储的是指向重量级锁的指针，此时等待锁的线程都会进入阻塞状态。

总结
  • 一个对象刚开始实例化的时候，没有任何线程来访问它的时候。它是可偏向的，意味着，它现在认为只可能有一个线程来访问它，所以当第一个线程来访问它的时候，它会偏向这个线程，此时，对象持有偏向锁。偏向第一个线程，这个线程在修改对象头成为偏向锁的时候使用CAS操作，并将对象头中的ThreadID改成自己的ID，之后再次访问这个对象时，只需要对比ID，不需要再使用CAS在进行操作。
  • 一旦有第二个线程访问这个对象，因为偏向锁不会主动释放，所以第二个线程可以看到对象时偏向状态，这时表明在这个对象上已经存在竞争了。检查原来持有该对象锁的线程是否依然存活，如果挂了，则可以将对象变为无锁状态，然后重新偏向新的线程。如果原来的线程依然存活，则马上执行那个线程的操作栈，检查该对象的使用情况，如果仍然需要持有偏向锁，则偏向锁升级为轻量级锁，（偏向锁就是这个时候升级为轻量级锁的），此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程会进入自旋等待获得该轻量级锁；如果不存在使用了，则可以将对象回复成无锁状态，然后重新偏向。
  • 轻量级锁认为竞争存在，但是竞争的程度很轻，一般两个线程对于同一个锁的操作都会错开，或者说稍微等待一下（自旋），另一个线程就会释放锁。 但是当自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁膨胀为重量级锁，重量级锁使除了拥有锁的线程以外的线程都阻塞，防止CPU空转。
ReentrantLock

java除了使用关键字synchronized外，还可以使用ReentrantLock实现独占锁的功能。而且ReentrantLock相比synchronized而言功能更加丰富，使用起来更为灵活，也更适合复杂的并发场景。

ReentrantLock常常对比着synchronized来分析，我们先对比着来看然后再一点一点分析。

（1）synchronized是独占锁，加锁和解锁的过程自动进行，易于操作，但不够灵活。ReentrantLock也是独占锁，加锁和解锁的过程需要手动进行，不易操作，但非常灵活。

（2）synchronized可重入，因为加锁和解锁自动进行，不必担心最后是否释放锁；ReentrantLock也可重入，但加锁和解锁需要手动进行，且次数需一样，否则其他线程无法获得锁。

（3）synchronized不可响应中断，一个线程获取不到锁就一直等着；ReentrantLock可以相应中断。

我们也来使用一下吧

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
private final static ReentrantLock reentrantLock = new ReentrantLock();//默认实现的是非公平锁，这个我们后面讨论
public static int count = 0;

public static int TestCAS() {
    for (int i = 0; i < 3; i++) {
        new Thread(
            new Runnable() {
                @Override
                public void run() {
                    try {
                        //手动上锁
                        reentrantLock.lock();
                        Thread.sleep(10);
                        for(int j = 0; j < 100; j++){
                            count++;
                        }
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    } finally {
                        //手动释放锁
                        reentrantLock.unlock();
                    }
                }
            }
        ).start();
    }
    try {
        Thread.sleep(2000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    return count;
}

运行结果：
    300
    300
    300
    300
    300
    300
    300
    300
    300
    300
公平锁与非公平锁

公平锁是指多个线程按照申请锁的顺序来获取锁，线程直接进入队列中排队，队列中的第一个线程才能获得锁。公平锁的优点是等待锁的线程不会饿死。缺点是整体吞吐效率相对非公平锁要低，等待队列中除第一个线程以外的所有线程都会阻塞，CPU唤醒阻塞线程的开销比非公平锁大。

非公平锁是多个线程加锁时直接尝试获取锁，获取不到才会到等待队列的队尾等待。但如果此时锁刚好可用，那么这个线程可以无需阻塞直接获取到锁，所以非公平锁有可能出现后申请锁的线程先获取锁的场景。非公平锁的优点是可以减少唤起线程的开销，整体的吞吐效率高，因为线程有几率不阻塞直接获得锁，CPU不必唤醒所有线程。缺点是处于等待队列中的线程可能会饿死，或者等很久才会获得锁。

啧，我们直接看一下直观的代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
public static void main(String[] args) {
    Runnable r = new DemoR();
    //之类创建三个线程去争夺资源
    new Thread(r, "线程1").start();
    new Thread(r, "线程2").start();
    new Thread(r, "线程3").start();

}

static class DemoR implements Runnable{
    private int r = 10;
    //默认为创建非公平锁
    Lock l = new ReentrantLock();

    @Override
    public void run() {
        while(true) {
            l.lock();
            if(r > 0) {
                try {
                    Thread.sleep(3);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                r--;
                System.out.println(Thread.currentThread().getName() + " " + r);
            } else {
                l.unlock();
                break;
            }
            l.unlock();
        }
    }
}

运行结果：
    线程1 9
    线程1 8
    线程1 7
    线程2 6
    线程2 5
    线程2 4
    线程2 3
    线程2 2
    线程2 1
    线程2 0

在这里可以比较明显的看到，基本上线程1和线程2在争夺资源，而线程三出现了“饿死”的现象，这在有些业务场景中是不允许的，那我们怎么去实现大家按顺序取用呢？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
//传入参数true,表示创建公平锁
Lock l = new ReentrantLock(true);

运行结果：
    线程1 9
    线程3 8
    线程2 7
    线程1 6
    线程3 5
    线程2 4
    线程1 3
    线程3 2
    线程2 1
    线程1 0

这个是如何办到的呢，我们来看看底层实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
//ReentrantLock传参，判断构建公平锁还是非公平锁 
public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

//公平锁实现
static final class FairSync extends Sync {
    private static final long serialVersionUID = -3000897897090466540L;

    final void lock() {
        acquire(1);
    }

    /**
* Fair version of tryAcquire. Don't grant access unless
* recursive call or no waiters or is first.
*/
    protected final boolean tryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
            //关键方法，判断线程是否是队列第一个
            if (!hasQueuedPredecessors() &&
                compareAndSetState(0, acquires)) {
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        else if (current == getExclusiveOwnerThread()) {
            int nextc = c + acquires;
            if (nextc < 0)
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        return false;
    }
}
//非公平锁实现
static final class NonfairSync extends Sync {
    private static final long serialVersionUID = 7316153563782823691L;

    /**
* Performs lock. Try immediate barge, backing up to normal
* acquire on failure.
*/
    final void lock() {
        if (compareAndSetState(0, 1))
            setExclusiveOwnerThread(Thread.currentThread());
        else
            acquire(1);
    }

    protected final boolean tryAcquire(int acquires) {
        return nonfairTryAcquire(acquires);
    }
}
可重入锁与非可重入锁

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

我们继续用代码演示一下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
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();
}

运行结果：
    第1获次取锁，这个锁是：Example.CAS.Example4$1@5c9d5a89
    第2次获取锁，这个锁是：Example.CAS.Example4$1@5c9d5a89
    第3次获取锁，这个锁是：Example.CAS.Example4$1@5c9d5a89
    第4次获取锁，这个锁是：Example.CAS.Example4$1@5c9d5a89
    第5次获取锁，这个锁是：Example.CAS.Example4$1@5c9d5a89
    第6次获取锁，这个锁是：Example.CAS.Example4$1@5c9d5a89
    第7次获取锁，这个锁是：Example.CAS.Example4$1@5c9d5a89
    第8次获取锁，这个锁是：Example.CAS.Example4$1@5c9d5a89
    第9次获取锁，这个锁是：Example.CAS.Example4$1@5c9d5a89
    第10次获取锁，这个锁是：Example.CAS.Example4$1@5c9d5a89

ReentrantLock 和 synchronized 不一样，需要手动释放锁，所以使用 ReentrantLock的时候一定要手动释放锁，并且加锁次数和释放次数要一样，否则可能会造成死锁

但如果是非可重入锁的话，线程进入内层方法获取不了锁。当前线程出现死锁，整个等待队列中的所有线程都无法被唤醒。

我们看下实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        if (compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {
        //获取锁的时候先判断，如果是当前线程就是已经占有锁的线程，则status+1，并返回true
        int nextc = c + acquires;
        if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

protected final boolean tryRelease(int releases) {
    //释放锁的时候也是先判断当前线程是否是已占有锁的线程，然后再判断status，如果status为0，才是真正的释放锁
    int c = getState() - releases;
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    setState(c);
    return free;
}
共享锁与排他锁

共享锁【S锁】
又称读锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。

排他锁【X锁】
又称写锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。这保证了其他事务在T释放A上的锁之前不能再读取和修改A。

ReentrantReadWriteLock

ReentrantReadWriteLock是一把可重入读写锁，它有以下几个特点

1、可重入（这里不再赘述了）

2、读写分离

我们知道，对于一个数据，不管是几个线程同时读都不会出现任何问题，但是写就不一样了，几个线程对同一个数据进行更改就可能会出现数据不一致的问题，因此想出了一个方法就是对数据加锁，这时候出现了一个问题：

线程写数据的时候加锁是为了确保数据的准确性，但是线程读数据的时候再加锁就会大大降低效率，这时候怎么办呢？那就对写数据和读数据分开，加上两把不同的锁，不仅保证了正确性，还能提高效率。

3、可以锁降级

4、不可锁升级

我们来实现以下哇

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
static ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock(true);//这里创建公平锁
private static Lock readLock = reentrantReadWriteLock.readLock();
private static Lock writeLock = reentrantReadWriteLock.writeLock();
private static List<String> data = new ArrayList<>();

public static void main(String[] args) {
    //新建三个线程来执行写任务
    for(int i = 0; i < 3; i ++) {
        new Thread(() -> write()).start();
    }
    //新建三个线程来执行读任务
    for(int i = 0; i < 3; i ++){
        new Thread(()->read()).start();
    }

}

//新建任务为写任务，当然是被写锁上锁的
public static void write() {
    try {
        writeLock.lock();
        data.add("写数据1");
        System.out.println(Thread.currentThread().getName() + "：写数据");
        //方便看到结果我们将线程阻塞三秒
        TimeUnit.SECONDS.sleep(3);
    } catch (InterruptedException e) {
        e.printStackTrace();
    } finally {
        writeLock.unlock();
    }
}
//新建任务为读任务，上读锁
public static void read() {
    try {
        readLock.lock();
        for (String value : data) {
            System.out.println(Thread.currentThread().getName() + "读数据");
        }
        TimeUnit.SECONDS.sleep(3);
    } catch (InterruptedException e) {
        e.printStackTrace();
    } finally {
        readLock.unlock();
    }
}

任务运行结果：
    Thread-0：写数据
    //隔了三秒
    Thread-1：写数据
    //隔了三秒
    Thread-2：写数据
    //隔了三秒
    Thread-3读数据
    Thread-3读数据
    Thread-3读数据
    Thread-4读数据
    Thread-4读数据
    Thread-4读数据
    Thread-5读数据
    Thread-5读数据
    Thread-5读数据

参考

java中的各种锁详细介绍

Java synchronized原理总结

一文彻底理解ReentrantLock可重入锁的使用

可重入锁详解（什么是可重入）

可重入读写锁ReentrantReadWriteLock的使用详解