多线程锁相关

针对java提供的锁synchronized判别

（1）synchronized 即是一个悲观锁，也是乐观锁

注：synchronized默认是乐观锁，竞争变激烈后就会变成悲观锁

（2）synchronized即是轻量级锁，也是一个重量级锁

注：synchronized默认是轻量级锁，如果当前锁竞争比较激烈，就会转换成重量级锁

（3）synchronized这里轻量级锁，是基于自旋锁的方式实现的。

synchronized这里的重量级锁，是基于挂起等待锁的方式实现的

（4）synchronized不是读写锁

（5）synchronized不是公平锁

（6）synchronized是可重入锁

2、CAS

2.1、CAS解析

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

翻译有点直白，不过确实是这样的

解释CAS：原数据为 V 预期值A 需要修改值B

（1）比较A 与 V 是否相等（比较）

（2）如果比较相等，将B 写入 V（交换），如果不等的话就是直接到（3）

（3）返回操作成功

这里文字解释还是有点模糊不清

来写我们这里拿图来解释寄存器与内存的关系

此处最特别的地方，上述这个CAS的过程，并非是通过一段代码实现的，而是通过一条CPU指令实现的，也就是说该操作是一个“原子”（CAS是原子）

原子就可以在一定程度上回避线程安全问题，咱们解决线程安全问题除了加锁之外又有了一个新的路子

总述：CAS可以理解为CPU给我们提供了一个特殊指令，通过这个指令，就可以一定程度的解决线程安全问题

（这里写一个伪代码来解释CAS）

伪代码：就是假的，不能运行编译的，用来帮助我们来断思路的

2.2、CAS的应用场景

2.2.1、实现原子类

java标准库里提供的类AtomicInteger

AtomicInteger count=new AtomicInteger(0);

不要感觉陌生，这里就和创建一个包装类一样，直接赋值，后面的传参就是赋值

说了CAS是一个“原子” 那如何证明呢，之前的博客中有提及到锁synchronized可以解决多线程安全问题，这里也用代码尝试一下

public class Test {
    public static void main(String[] args) throws InterruptedException {
        //这些原子类 就是基于 CAS实现了 自增 自减等操作， 此时进行这类操作，也是线程安全的
        AtomicInteger count=new AtomicInteger(0);
        //使用原子类 来解决线程安全问题
        Thread t1=new Thread(()->{
            for (int i = 0; i < 5000; i++) {
                //java中不支持运算重载 ，所以只能使用普通的方法表示自增自减
                count.getAndIncrement();   //解释 count++
               /* count.incrementAndGet();   //解释 ++count
                count.getAndDecrement();  //解释 count--
                count.decrementAndGet();   //解释 --count*/
            }
        });
        Thread t2=new Thread(()->{
            for (int i = 0; i < 5000; i++) {
                count.getAndIncrement();
            }
        });
        t1.start();
        t2.start();
        t1.join();  //等待
        t2.join();
        System.out.println(count);  //直接解决线程安全问题 不会影响多线程加的结果
    }
}

我们知道如果两个线程都执行++操作，在线程不安全的情况下不会得到一个准确的数值，当前可以。

之所以有这个代码出现，不仅仅是证明CAS可以保证线程安全，还有就是java中不支持运算重载，所以中用普通的方法来表示加加或者减减（前或者后）

伪代码解释一下CAS的精妙之处

上图的（3）没有截上，这里补充一下

到这里是不是友友想问既然一条CPU指令就实现了，精妙还安全为啥还要锁来维护线程安全

CAS属于“特殊方法” ->只能特定场景使用，没有那么通用（共享访问一个量可以，例如解决++在线程的安全问题）。

synchronized 属于“通用方法” ->各种场景，都能使用。

2.2.2、实现自旋锁

伪代码解释：

2.2.3、CAS相关ABA问题

CAS在运行中的核心，检查value 和 oldValue 是否一致，如果一致就任务value没有被修改过，进行交换操作是没有问题的。（这个真的，下面解释的问题和这个有点点冲突）

要知道线程操作是很快的

value值一致有两种可能

value=A；

一种是真没有修改过 value =A;

第二种就是改了但是又改回来了。 value=A -> value=B -> value=A

ABA问题家人看见的你出远门的时候好好的，中途可能生病了，但是回家的时候好了但是在你不说的情况下，家人认为你一直是好的。（基本就是这样一个情况）

但是ABA仍然算是个缺陷，极端情况下，也可能会造成影响（实际中概率很低）

以取钱为例，去取款机上取钱这种

许某账户余额有1000块，准备取500元

当按下取款机一瞬间，机器卡了许某就想着多按几下，能不能快点出来，这时候就会产bug重复扣款，考虑使用CAS方式扣款（图解）

当然能看出来，上面这种情况概率还是很低的。

主要是要满足两个条件（1）恰好许某按了很多下，产生扣款操作（2）刚刚好非常极限的时间有人转账一样的金额

概率很低，但是不代表不会有，还是要考虑的，因为此时只是一种现实的情况，但是此情况一旦出现，不好解决吧，提前准备是最好的。

解决当前问题的就是加一个版本号（就是标记），每次修改时，版本号都会更新+1，然后CAS不是以金额为基准，以版本号为基准，版本号就是无限加（版本号没有改变就代表什么都没有发生）

3、Synchronized原理

使用原理前面提及过：保证线程执行安全，如果两个线程加锁同一个对象，就会产生阻塞。

synchronized不仅仅是我们看到的，内部还有很多操作。

3.1、锁升级/锁膨胀

锁要经历的4个过程无锁、偏向锁、轻量级锁、重量级锁

（1）无锁

（2）偏向锁

加锁的时候，首先会进入到偏向锁状态，偏向锁，并不是真正的加锁，而只是占个位置，有需要了在真加锁，没有需要就算了。（其实看的出还是很优质的，毕竟加锁是要有开销的）

举个例子解释偏向锁：该两个小孩买了一个夜光球，小孩A先看见就在旁边看（尚未加锁），过了一会小孩B来了，孩子都喜欢独一份的，小孩A立马将夜光球抱到怀里（加锁），这就是偏向锁（有偏向性，只是没有遇到竞争者，一旦遇到立刻加锁）

偏向锁又是怎么做到：为了降低冲突，减少开销。

这里synchronized等待也不是凭空等待，有偏向性，做个标记（这个过程很轻量）

<1> 如果整个使用锁的过程中没有出现锁竞争synchronized执行完后，取消偏向锁即可（清楚标记）

<2> 如果另一个线程也尝试加锁，在它加锁之前，迅速就标记的偏向锁升级为真正的加锁状态

（3）轻量级锁

synchronized发生锁竞争的时候，会从偏向锁，升级到轻量锁，此时，synchronized通过自选的方式来加锁，也是自旋锁（与刚才CAS伪代码一样思路）

（4）重量级锁

自旋锁不能一直自旋不是嘛，CPU是资源开销的，自旋次数多了就不划算了，自旋到一定程度会自己停的，再次升级为重量级锁（挂起等待锁）

重量级锁就不像前面的锁一样了，很保险，是基于操作系统的原生API来进行加锁，linux原生提供了mutex一组API，操作系统内核提供加锁功能，这个锁会影响到线程的调度，如果此时线程进行到了重量级锁，发生锁竞争就只能等了，该线程也就被放阻塞队列中，直到锁被释放，线程才有机会被调度，并且有机会获取锁，（注：是有机会，不是直接就获取）线程一旦被切出CPU就会变的低效

关于锁升级就是以上内容，有升级是不是就降级，当前还没有，到了重量级锁就在这个位置了，JVM只有锁升级；要想降级也只有等该线程执行完，锁释放了，从新有一个对象获取锁，开始重复刚刚加锁的过程(偏向锁，轻量级锁，重量级锁)