一、💛
锁策略——接上一篇
6.分为可重入锁，不可重入锁
如果一个线程，针对一把锁，连续加锁两次，会出现死锁，就是不可重入锁，不会出现死锁，就是可重入锁。
如果一个线程，针对一把锁，连续加锁两次，如果产生了死锁，就是不可重入锁😄
public class Demo5 { public static void main(String[] args) { Thread t=new Thread(new Runnable() { int count=0; @Override public 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() { @Override public 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() { @Override public 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+1 oldValue=value; //假如修改了就恢复了原来的样子 } return oldValue;}
假如这种情况，刚开始设置value=0,
CAS是一个指令，这个指令本身是不能够拆分的。
是否可能会出现，两个线程，同时在两个cpu上？微观上并行的方式来执行，CAS本身是一个单个的指令，这里其实包含了访问操作，当多个cpu尝试访问内存的时候，本质也是会存在先后顺序的。
就算同时执行到CAS指令，也一定有一个线程的CAS先访问到内存，另一个后访问到内存
为啥CAS访问内存会有先后呢？
多个CPU在操作同一个资源，也会涉及到锁竞争（指令级别的锁），是比我们平时说的synchronized代码级别的锁要轻量很多（cpu内部实现的机制）
