可重入锁
什么是 “可重入”，可重入就是说某个线程已经获得某个锁，可以再次获取锁而不会出现死锁。可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。当一个线程执行到第一个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2
像synchronized和ReentrantLock都是可重入锁，对于Java ReentrantLock而言, 他的名字就可以看出是一个可重入锁，其名字是Re entrant Lock重新进入锁。对于Synchronized而言,也是一个可重入锁。可重入锁的一个好处是可一定程度避免死锁。例如
synchronized
/**
* @author zhy
*/
public class LockTest {
public static void main(String[] args) {
new Thread(new Runnable() {
@Override
public void run() {
synchronized (this) {
System.out.println("第1次获取锁，这个锁是：" + this);
int index = 1;
do {
synchronized (this) {
System.out.println("第" + (++index) + "次获取锁，这个锁是：" + this);
}
} while (index != 10);
}
}
}).start();
}
}控制台打印：
第1次获取锁，这个锁是：com.zhy.admin.LockTest$1@15c02541
第2次获取锁，这个锁是：com.zhy.admin.LockTest$1@15c02541
第3次获取锁，这个锁是：com.zhy.admin.LockTest$1@15c02541
第4次获取锁，这个锁是：com.zhy.admin.LockTest$1@15c02541
第5次获取锁，这个锁是：com.zhy.admin.LockTest$1@15c02541
第6次获取锁，这个锁是：com.zhy.admin.LockTest$1@15c02541
第7次获取锁，这个锁是：com.zhy.admin.LockTest$1@15c02541
第8次获取锁，这个锁是：com.zhy.admin.LockTest$1@15c02541
第9次获取锁，这个锁是：com.zhy.admin.LockTest$1@15c02541
第10次获取锁，这个锁是：com.zhy.admin.LockTest$1@15c02541ReentrantLock：
import java.util.concurrent.locks.ReentrantLock;
/**
* @author zhy
*/
public class LockTest {
public static void main(String[] args) {
ReentrantLock lock = new ReentrantLock(false);
new Thread(() -> {
try {
lock.lock();
System.out.println("第1次获取锁，这个锁是：" + lock);
int index = 1;
while (true) {
try {
lock.lock();
System.out.println("第" + (++index) + "次获取锁，这个锁是：" + lock);
if (index == 10) {
break;
}
} finally {
lock.unlock();
}
}
} finally {
lock.unlock();
}
}).start();
}
}第1次获取锁，这个锁是：java.util.concurrent.locks.ReentrantLock@798aadc8[Locked by thread Thread-0]
第2次获取锁，这个锁是：java.util.concurrent.locks.ReentrantLock@798aadc8[Locked by thread Thread-0]
第3次获取锁，这个锁是：java.util.concurrent.locks.ReentrantLock@798aadc8[Locked by thread Thread-0]
第4次获取锁，这个锁是：java.util.concurrent.locks.ReentrantLock@798aadc8[Locked by thread Thread-0]
第5次获取锁，这个锁是：java.util.concurrent.locks.ReentrantLock@798aadc8[Locked by thread Thread-0]
第6次获取锁，这个锁是：java.util.concurrent.locks.ReentrantLock@798aadc8[Locked by thread Thread-0]
第7次获取锁，这个锁是：java.util.concurrent.locks.ReentrantLock@798aadc8[Locked by thread Thread-0]
第8次获取锁，这个锁是：java.util.concurrent.locks.ReentrantLock@798aadc8[Locked by thread Thread-0]
第9次获取锁，这个锁是：java.util.concurrent.locks.ReentrantLock@798aadc8[Locked by thread Thread-0]
第10次获取锁，这个锁是：java.util.concurrent.locks.ReentrantLock@798aadc8[Locked by thread Thread-0]ReentrantLock 和 synchronized 不一样，需要手动释放锁，所以使用 ReentrantLock的时候一定要手动释放锁，并且加锁次数和释放次数要一样，否则会出现死锁。
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，将锁释放。
举例子：给一把钥匙去库房领口罩，要求一队人一起去，第一个取一个口罩后锁上门。需要等第二个人领口罩，可是第二个人没有钥匙，第一个人需要等第二个人一起回去，大家都在那里耗着，死锁了。
可中断锁
如果某一线程A正在执行锁中的代码，另一线程B正在等待获取该锁，可能由于等待时间过长，线程B不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它，这种就是可中断锁。
synchronized就不是可中断锁
ReentrantLock的中断和非中断加锁模式的区别在于：线程尝试获取锁操作失败后，在等待过程中，如果该线程被其他线程中断了，它是如何响应中断请求的。lock方法会忽略中断请求，继续获取锁直到成功；lockInterruptibly则直接抛出中断异常来立即响应中断，由上层调用者处理中断。持有锁的线程长期不释放的时候，正在等待的线程可以选择放弃等待，这相当于Synchronized来说可以避免出现死锁的情况。通过lock.lockInterruptibly()来实现这个机制
Lock是可中断锁线程在调用lock方法来获得另一个线程所持有的锁的时候，很可能发生阻塞。应该更加谨慎地申请锁。tryLock方法试图申请一个锁，在成功获得锁后返回true,否则，立即返回false，而且线程可以立即离开去做其他事。可以调用tryLock时，使用超时参数。lock方法不能被中断。如果一个线程在等待获得一个锁时被中断，中断线程在获得锁之前一直处于阻塞状态。如果出现死锁，那么，lock方法就无法终止。
列如：
ReentrantLock
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.ReentrantLock;
/**
* @author zhy
* @date 2020/9/11 14:52
*/
public class LockTest {
private ReentrantLock lock1 = new ReentrantLock();
private ReentrantLock lock2 = new ReentrantLock();
/**
* ReentrantLock响应中断
*
* @throws Exception
*/
private void exeInterupt() throws Exception {
Thread t1 = new Thread(new DemoThread(lock1, lock2));
Thread t2 = new Thread(new DemoThread(lock2, lock1));
t1.start();
t2.start();
System.out.println(t1.getName() + "中断");
//主线程睡眠1秒，避免线程t1直接响应run方法中的睡眠中断
Thread.sleep(1000);
t1.interrupt();
//阻塞主线程，避免所有线程直接结束，影响死锁效果
Thread.sleep(10000);
}
/**
* ReentrantLock实现死锁
*/
static class DemoThread implements Runnable {
ReentrantLock lock1;
ReentrantLock lock2;
public DemoThread(ReentrantLock lock1, ReentrantLock lock2) {
this.lock1 = lock1;
this.lock2 = lock2;
}
@Override
public void run() {
try {
//可中断的获取锁
lock1.lockInterruptibly();
//lock1.lock();
//睡眠200毫秒，保证两个线程分别已经获取到两个锁，实现相互的锁等待
TimeUnit.MILLISECONDS.sleep(200);
//lock2.lock();
//可中断的获取锁
lock2.lockInterruptibly();
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock1.unlock();
lock2.unlock();
System.out.println("线程" + Thread.currentThread().getName() + "正常结束");
}
}
}
public static void main(String[] args) throws Exception {
LockTest test = new LockTest();
//测试ReentrantLock响应中断
test.exeInterupt();
}
}公平锁/非公平锁
公平锁：线程获取锁的顺序和调用lock的顺序一样，首先判断当前AQS的state是否等于0,锁是否被占用,如果没有被占用的话,继续判断队列中是否有排在前面的线程在等待锁,没有的话就修改statte状态，然后将当前线程记录为独占锁的线程,继续判断当前线程是否为独断锁的线程,ReentrantLock是可冲入的,线程可以不停地Lock来增加state的值,对应的需要unlock来解锁,减少state的值，如果上面的条件判断失败,即获取锁失败,则将线程加入到等待线程队列队尾,然后阻塞线程,等待被唤醒。
非公平锁：线程获取锁的顺序和调用lock的顺序无关，全凭运气，多个线程等待同一个锁时，必须按照申请锁的时间顺序获得锁。非公平锁逻辑基本跟公平锁一致,最本质的区别是,当当前的锁状态没有被占用时,当前线程可以直接占用,而不需要判断当前队列中是否有等待线程,
Synchronized锁非公平锁，ReentrantLock默认的构造函数是创建的非公平锁，可以通过参数true设为公平锁，但公平锁表现的性能不是很好。
读写锁/独享锁/独占锁/排他锁/共享锁
ReadWriteLock管理一组锁，一个是只读的锁，一个是写锁。
Java并发库中ReetrantReadWriteLock实现了ReadWriteLock接口并添加了可重入的特性。既是排他锁，又是共享锁。读锁，共享锁，写锁：排他锁
public interface ReadWriteLock {
/**
* Returns the lock used for reading.
*
* @return the lock used for reading
*/
Lock readLock();
/**
* Returns the lock used for writing.
*
* @return the lock used for writing
*/
Lock writeLock();
}
独享锁：独享锁也叫排他锁、写锁、独占锁，是指该锁一次只能被一个线程锁持有。如果线程T对数据A加上排他锁后，则其他线程不能再对A加任何类型的锁。获得排他锁的线程既能读数据又能修改数据。JDK中的synchronized和JUC中Lock的实现类就是互斥锁是指该锁一次只能被一个线程所持有。
共享锁：又称为读锁，共享锁是指该锁可被多个线程所持有。如果线程T对数据A加上共享锁后，则其他线程只能对A再加共享锁，不能加排他锁。获得共享锁的线程只能读数据，不能修改数据。
独享锁与共享锁也是通过AQS来实现的，通过实现不同的方法，来实现独享或者共享。
互斥锁
在访问共享资源之前对进行加锁操作，在访问完成之后进行解锁操作。 加锁后，任何其他试图再次加锁的线程会被阻塞，直到当前进程解锁。
如果解锁时有一个以上的线程阻塞，那么所有该锁上的线程都被编程就绪状态， 第一个变为就绪状态的线程又执行加锁操作，那么其他的线程又会进入等待。 在这种方式下，只有一个线程能够访问被互斥锁保护的资源
自旋锁/适应性自旋锁
阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态转换需要耗费处理器时间。如果同步代码中的内容过于简单，状态转换消耗的时间有可能比用户代码执行的时间还要长。
在许多场景中，同步资源的锁定时间很短，为了这一小段时间去切换线程，线程挂起和恢复现场的花费可能会让系统得不偿失。如果物理机器有多个处理器，能够让两个或以上的线程同时并行执行，我们就可以让后面那个请求锁的线程不放弃CPU的执行时间，看看持有锁的线程是否很快就会释放锁。
而为了让当前线程“稍等一下”，我们需让当前线程进行自旋，如果在自旋完成后前面锁同步资源的线程已经释放了锁，那么当前线程就可以不必阻塞而是直接获取同步资源，从而避免了切换线程的开销。这就是自旋锁。
自旋锁本身是有缺点的，它不能代替阻塞。自旋等待虽然避免了线程切换的开销，但它要占有处理器的时间，如果锁被占有的时间很短，自旋等待的效果就会非常好。反之，如果锁被占用的时间很长，那么自旋的线程只会白浪费处理器资源。所以，自旋等待的时间必须要有一定的限度，如果自旋超过了限定次数（默认是10次，可以使用-XX：PreBlockSpin来更改）没有成功获得锁，就应当挂起线程。
自旋锁的实现原理同样也是CAS，AtomicInteger中调用unsafe进行自增操作的源码中的do-while循环就是一个人自旋操作，如果修改数值失败则通过循环来执行自旋，直至修改成功。
[
自旋锁在JDK1.4.2中引入，使用-XX：+UseSpinning来开启。JDK6中变成默认开启，并且引入了自适应的自旋锁（适应性自旋锁）。
自适应意味着自旋的时间（次数）不再固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也是很有可能再次成功，进而它将允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功获得过，那在以后尝试获取这个锁时，将可能省略掉自旋过程，直接阻塞线程，避免浪费处理器资源。
乐观锁/悲观
悲观锁：对于同一个数据的并发操作，悲观锁认为自己在使用数据的时候一定有别的线程来修改数据，因此在获取数据的时候会先加锁，确保数据不会被别的线程修改。Java中，synchronized关键字和Lock的实现类都是悲观锁
public synchronized void testMethod() {
//操作同步资源
}
//需要保证多个线程使用的是同一个锁
Private ReentrantLock lock = new ReentrantLock();
Public void modifyPublicResource() {
try{
lock.lock();
//操作资源
} finally {
lock.unlock();
}
}乐观锁：认为自己在使用数据时不会有别的线程修改数据，所以不会添加锁，只是在更新数据的时候去判断之前有没有别的线程更新了这个数据。如果这个数据没有被更新，当前线程将自己修改的数据成功写入。如果数据已经被其他线程更新，则根据不同的实现方式执行不同的操作（例如报错或者自动重试）。
乐观锁在java中是通过无锁编程来实现的，最长采用的是CAS算法，java原子类中的递增操作就通过CAS自旋实现的。
//需要保证多个线程使用的是同一个
private AtomicInteger atomicInteger = new AtomicInteger();
//执行自增
AtomicInteger.incrementAndGet();分段锁
分段锁其实是一种锁的设计，并不是具体的一种锁，对于ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作。我们以ConcurrentHashMap来说一下分段锁的含义以及设计思想，ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap（JDK7与JDK8中HashMap的实现）的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表；同时又是一个ReentrantLock（Segment继承了ReentrantLock)。当需要put元素的时候，并不是对整个hashmap进行加锁，而是先通过hashcode来知道他要放在那一个分段中，然后对这个分段进行加锁，所以当多线程put的时候，只要不是放在一个分段中，就实现了真正的并行的插入。但是，在统计size的时候，可就是获取hashmap全局信息的时候，就需要获取所有的分段锁才能统计。
分段锁的设计目的是细化锁的粒度，当操作不需要更新整个数组的时候，就仅仅针对数组中的一项进行加锁操作。
偏向锁/轻量级锁/重量级锁
自旋锁中提到的“阻塞或唤醒一个java线程需要操作系统切换CPU状态来完成，这种状态转换需要耗费处理器时间。如果同步代码块中的内容过于简单，状态转换消耗的时间有可能比用户代码执行的时间还要长”。这种方式就是synchronized最初实现同步的方式，这就是JDK6之前synchronized效率低的原因。这种依赖于操作系统Mutex Lock所实现的锁我们称之为“重量级锁”，JDK6中为了减少获得锁的释放锁带来的性能消耗，引入了“偏心锁”和“轻量级锁”
偏向锁：偏向锁是指一段同步代码一直被一个线程锁访问，那么该线程会自动获取锁，降低获取锁的代价。在大多数情况下，锁总是由同一个线程多次获得，不存在多线程竞争，所以出现了偏向锁。其目标就是在只有一个线程执行同步代码块时能够提高性能。当一个线程访问同步代码块并获取锁时，会在Mark Word里存储锁偏向的线程ID。在线程进入和退出同步快时不再通过CAS操作来加锁和解锁，而是检测Mark Word里是否存储着指向当前线程的偏向锁。引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令即可。偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程不会主动释放偏向锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定的状态。撤销偏向锁后恢复到无锁（标志位为“01”）或轻量级锁（标志位为“00”）的状态。偏向锁在JDK6及以后的JVM 里是默认开启的。可以通过JVM参数关闭偏向锁：-XX:-UseBiaseLockingfalse，关闭之后程序会默认进入轻量级锁状态
轻量级锁：是指当锁时偏向锁的时候，被另外的线程锁访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，从而提高性能。在代码进入同步块的时候，如果同步对象锁状态无无锁状态（锁标志位为“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操作和自旋来解决加锁问题，避免线程阻塞和唤醒影响性能。重量级锁是将除了拥有锁的线程以外的线程都阻塞。
死锁/活锁/饥饿
死锁：是指两个或两个以上的进程（或线程）在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。产生死锁的必要条件：
- 互斥条件：所谓互斥就是进程在某一时间内独占资源。
- 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
- 不剥夺条件:进程已获得资源，在末使用完之前，不能强行剥夺。
- 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
活锁：任务或者执行者没有被阻塞，由于某些条件没有满足，导致一直重复尝试，失败，尝试，失败。
活锁和死锁的区别在于，处于活锁的实体是在不断的改变状态，所谓的“活”， 而处于死锁的实体表现为等待；活锁有可能自行解开，死锁则不能。
饥饿：一个或者多个线程因为种种原因无法获得所需要的资源，导致一直无法执行的状态。
联锁
基于Redis的Redisson分布式联锁RedissonMultiLock对象可以将多个RLock对象关联为一个联锁，每个RLock对象实例可以来自于不同的Redisson实例。
RLock lock1 = redissonInstance1.getLock("lock1");
RLock lock2 = redissonInstance2.getLock("lock2");
RLock lock3 = redissonInstance3.getLock("lock3");
RedissonMultiLock lock = new RedissonMultiLock(lock1, lock2, lock3);
// 同时加锁：lock1 lock2 lock3
// 所有的锁都上锁成功才算成功。
lock.lock();
...
lock.unlock();如果负责储存某些分布式锁的某些Redis节点宕机以后，而且这些锁正好处于锁住的状态时，这些锁会出现锁死的状态。为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。默认情况下，看门狗的检查锁的超时时间是30秒钟，也可以通过修改Config.lockWatchdogTimeout来另行指定。另外Redisson还通过加锁的方法提供了leaseTime的参数来指定加锁的时间。超过这个时间后锁便自动解开了。
RedissonMultiLock lock = new RedissonMultiLock(lock1, lock2, lock3);
// 给lock1，lock2，lock3加锁，如果没有手动解开的话，10秒钟后将会自动解开
lock.lock(10, TimeUnit.SECONDS);
// 为加锁等待100秒时间，并在加锁成功10秒钟后自动解开
boolean res = lock.tryLock(100, 10, TimeUnit.SECONDS);
...
lock.unlock();红锁
基于Redis的Redisson红锁RedissonRedLock对象实现了Redlock介绍的加锁算法。该对象也可以用来将多个RLock对象关联为一个红锁，每个RLock对象实例可以来自于不同的Redisson实例。
