可重入锁，不可重入锁，死锁的多种情况，以及产生的原因，如何解决，synchronized采用的锁策略（渣女圣经）自适应的底层，锁清除，锁粗化，CAS的部分应用

 一、💛

锁策略——接上一篇

6.分为可重入锁，不可重入锁

如果一个线程，针对一把锁，连续加锁两次，会出现死锁，就是不可重入锁，不会出现死锁，就是可重入锁。

如果一个线程，针对一把锁，连续加锁两次，如果产生了死锁，就是不可重入锁😄

public class Demo5 {public static void main(String[] args) {Thread t=new Thread(new Runnable() {int count=0;@Overridepublic synchronized void run() {    //加了一层锁synchronized (this){            //加了第二次锁count++;}System.out.println(count);}});t.start();}
}

那么我们来解释一下什么叫做死锁呢？

public synchronized void run() {    //加了一层锁
                synchronized (this){            //加了第二次锁
                    count++;
                }

这个代码中，调用方法先针对this加锁，此时假设加锁成功了，接下来到往下执行代码块中的this来进行加锁，此时就会出现锁竞争，this已经处于锁状态了，此时该线程就会阻塞～一直阻塞到锁被释放，才能有机会拿到锁。

这也是死锁第一个体现：this这个锁必须要run执行完毕，才能释放，但是要想执行完事，这个第二次加锁就应该加上，方法才可以执行，但是第二次想加上第一个就应该放锁，所以由于this锁没法释放，代码就卡在这里了，因此线程数量就僵住了。

还好synchronized是可重入锁，JVM帮我们承担了很多的任务

这里卡死就很不科学的一种情况，第二次尝试加锁的时候，该线程已经有了这个锁的权限了～～这个时候，不应该加锁失败，不应该进行阻塞等待的～

不可重入锁：这把锁不会保存，哪个线程加上的锁，只要他当前处于加锁状态之后，收到了‘加锁的请求’，就会拒绝当前加锁，而不管当下线程是哪个，就会产生死锁。 🌝

可重入锁：会让这个锁保存，是哪个线程加的锁，后续收到加锁请求之后，就会先对比一下，看看加锁的线程是不是当前持有自己这把锁的线程～～这个时候就可以灵活判定了。

那么该如何对比捏🌚

synchronized(this){synchronized(this){synchronized(this){
······->执行到这个代码，出了这个代码，刚才加上的锁，是否要释放？}       如果最里面的释放了锁，意味着最外面的synchronized和中间的synchronized后
}           续的代码部分就没有处在锁的保护之中了

真正要在这个地方释放锁，如加锁N层遇到了 } , JVM如何知道是最后一个呢，整一个整型变量，记录当前这个线程加了几次锁，每遇到一个加锁操作，计数器+1，每遇到一个解锁操作，就-1，当计数器减为0时，才真正执行释放锁操作，其他时候时不释放的。这一个思想就叫做‘引用计数’🐲🐲🐲（脑力+10000，人类进化不带我）

注补充：静态方法是针对类加锁，普通方法是针对this加锁

---

二、💙

死锁的详细介绍：两次加锁，都是同一个线程

死锁的三种典型情况；

1.一个线程，一把锁，但是不可入锁，该线程针对这个锁联系加两次就会出现死锁。

2.两个锁，两个锁，这两个县层先分别获取一把锁，然后再尝试分别获取对方的锁（

比如我拿了酱油要炫饺子，小杨拿醋，我让他把醋先给我，然后我一起给你，小杨一拍桌子，凭啥先给你，你多个啥？），如下图，双方陷入死循环中

 

public class Demo5 {public static Object  locker1=new Object();public static Object  locker2=new Object();public static void main(String[] args) {Thread t1=new Thread(new Runnable() {@Overridepublic synchronized void run() {synchronized (locker1) {           //给1加锁System.out.println("s1.start");try {Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();}synchronized (locker2) {    //没有放弃1的锁System.out.println("s2.over");}}}});t1.start();Thread t2=new Thread(new Runnable() {@Overridepublic synchronized void run() {synchronized (locker2) {         //給2加锁System.out.println("t2.start");try {Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();}synchronized (locker1) {     //没有放弃2的锁System.out.println("t1.over");}}}});t2.start();}
}

3.N个线程，M把锁：

（哲学家就餐问题）

---

 三、💜

如何应该避免死锁呢？先明确死锁产生的原因，死锁的必要条件（缺一不可）

1.互斥使用：一个线程获取到一把锁之后，别的线程不能获取到这个锁。（实际使用的锁，一般都是互斥的锁的基本特性）

2.不可抢占：锁只能被持有者主动释放，而不能是其他线程直接抢走（也是锁的基本特性）

3.请求和保持：这一个线程尝试获取多把锁，在获取第二把时候，会保持对第一把的获取状态（取决于代码结构）比如刚才写的，我只要让他获取完第一把再释放，在获取第二把，这样不发生冲突，但是可能会影响需求。

4.循环等待：t1尝试获取locker2,需要t2执行完释放locker2,t2尝试获取locker1,需要t1执行完毕，释放locker1(取决于代码结构）

我们的解决方式趋向于解决第四种（打破循环等待，如何具体实现解决死锁，实际方法有很多）

首先就是银行家算法（杀牛刀了属于，复杂，没必要会）

简单有效方法：针对锁进行编号，且规定加锁的顺序，只要线程加锁的顺讯，都严格执行上述顺序，就没有循环等待。

如下：

一般面试我们主动点：  问到死锁捡着了，细细的答，给他讲，让他觉得你是理解的

1.什么是死锁。           

2.死锁的几个典型场景

3.死锁产生的必要条件

4.如何解决死锁的问题

 

---

四、 ❤️

synchronized具体采用了哪些锁策略呢？

1.既是悲观锁，又是乐观锁

2.既是重量级锁，又是轻量级锁

3.重量级锁部分是基于多系统互斥锁实现的，轻量级锁部分是基于自旋锁实现的

4.synchronized是非公平锁（不会遵守先来后到，锁释放之后，哪个线程拿到锁个凭本事

5.synchronized是可重入锁（内部会记录哪个线程拿到了锁，记录引用计数）

6.synchronized不是读写锁

synchronized-内部实现策略（自适应）

讲解一下自适应：代码中写了一个synchhronized之后，可能产生一系列自适应的过程，锁升级（锁膨胀）

无锁->偏向锁->轻量级锁->重量级锁

偏向锁，不是真的加锁，而只是做了一个标记，如果有别的线程来竞争锁，才会真的加锁，如果没有别的线程竞争，就自始至终都不加锁了（渣女心态，没人来追你，我就钓鱼，你要是被追了，我先给你个身份，让别人别靠近你。）——当然加锁本身也有一定消耗

偏向锁在没人竞争的时候就是一个简单的（轻量的）标记，如果有别的线程来尝试加锁，就立即把偏向锁升级成真正加锁，让别人阻塞等待（能不加锁就不加锁）

轻量级锁-synchronized通过自旋锁的方式实现轻量级锁——这边把锁占据了，另一个线程按照自旋的方式（这个锁操作比较耗cpu,如果能够快速拿到锁，多耗点也不亏），来反复查询当前的锁状态是不是被释放，但是后续，如果竞争这把锁的线程越来越多了（锁冲突更加激烈了），从轻量锁，升级到重量级锁～随着竞争激烈，即使前一个线程释放锁，也不一定能够拿到锁，何时能拿到，时间可能比较久了会

 💖💖💖💖💖💖💖💖💖💖💖💖💖💖💖💖💖💖💖💖💖💖💖💖💖💖💖💖

锁清除：编译器，会智能的判断，当前这个代码，是否有必要加锁，如果你写了加锁，但实际没必要加锁，就会自动清除锁

如：单个线程使用StringBuffer编译器进行优化，是保证优化之后的逻辑和之前的逻辑是一致的，这样就会让代码优化变的保守起来～～咱们猿们也不能指望编译器优化，来提升代码效率，自己也要有作用，判断何时加锁，也是咱们非常重要的工作。

锁粗化：

关于锁的粒度，锁中操作包含代码多：锁粒就大

//1号       全写的是伪代码
和2号比较明显是2号的粒度更大
for(
synchronized(this){count++}
}//2号
synchronized(this){
for{
count++}
}

锁粒大，锁粒小各有好处：

锁粒小，并发程度会更高，效率也会更快

锁粒大，是因为加锁本身就有开销。（如同打电话，打一次就行，老打电话也不好）

上述的都是基本面试题

---

五、💚

CAS全称（Compare and swap) 字面意思：比较并且交换

能够比较和交换，某个寄存器中的值和内存中的值，看是否相等，如果相等就把另一个寄存器中的值和内存进行交换

boolean CAS(address,expectValue,swapValue){if(&address==expectValue){         //这个&相当于C语言中的*，看他两个是否相等&address=swapValue;             //相等就换值return true;                 
}return false;

此处严格的说是，adress内存的值和swapValue寄存器里的值，进行交换，但是一般我们重点关注的是内存中的值，寄存器往往作为保存临时数据的方式，这里的值是啥，很多时候我们选择是忽略的。

这一段逻辑是通过一条cpu指令完成的（原子的，或者说确保原子性）给我们编写线程安全代码，打开了新的世界。

CAS的使用

1.实现原子类：多线程针对一个count++,在java库中，已经提供了一组原子类

java.util.concurrent(并发的意思）.atomic

AtomicInteger,AtomicLong,提供了自增/自减/自增任意值，自减任意值··，这些操作可以基于CAS按照无锁编程的方式来实现。

如：for(int i=0;i<5000;i++){

count.getAndIncrement();                         //count++

count.incrementAndGet();                        //++count

count.getAndDecrement();                      //count--

count.decrementAndGet()                      //--count

}

import java.util.concurrent.atomic.AtomicInteger;public class Demo6 {public  static AtomicInteger count=new AtomicInteger(0);    //这个类的初值呗public static void main(String[] args) throws InterruptedException {Thread t1=new Thread(()->{for (int i=0;i<500;i++){count.getAndIncrement();}});Thread t2=new Thread(()->{for (int i=0;i<500;i++){count.getAndIncrement();}});t1.start();t2.start();t1.join();            //注意要等待两个线程都结束再开始调用t2.join();System.out.println(count);}
}

上述原子类就是基于CAS完成的

当两个线程并发的线程执行++的时候，如果加限制，意味着这两个++是串行的，能计算正确的，有时候者两个++操作是穿插的，这个时候是会出现问题的

加锁保证线程安全：通过锁，强制避免出现穿插～～

原子类/CAS保证线程安全，借助CAS来识别当前是否出现穿插的情况，如果没有穿插，此时直接修改就是安全的，如果出现了穿插，就会重新读取内存中最新的值，再次尝试修改。

部分源码合起来的意思就是 

public int getAndIncrement(){int oldValue=value;       //先储存值，防止别的线程偷摸修改之后，无法恢复到之前的值while(CAS(Value,oldValue,OldValue+1)!=true){  //检查是否线程被别的偷摸修改了//上面的代码是Value是否等于oldValue,假如等于就把Value赋值OldValue+1oldValue=value;                        //假如修改了就恢复了原来的样子}return oldValue;}

 

假如这种情况，刚开始设置value=0, 

CAS是一个指令，这个指令本身是不能够拆分的。

是否可能会出现，两个线程，同时在两个cpu上？微观上并行的方式来执行，CAS本身是一个单个的指令，这里其实包含了访问操作，当多个cpu尝试访问内存的时候，本质也是会存在先后顺序的。

就算同时执行到CAS指令，也一定有一个线程的CAS先访问到内存，另一个后访问到内存

为啥CAS访问内存会有先后呢？

多个CPU在操作同一个资源，也会涉及到锁竞争（指令级别的锁），是比我们平时说的synchronized代码级别的锁要轻量很多（cpu内部实现的机制）