JAVAEE初阶相关内容第十一弹--多线程（进阶）-CSDN博客

本文链接：https://blog.csdn.net/weixin_47285608/article/details/132776014

一、常见的锁策略

接下来进行学习的内容不仅仅局限于java，任何和“锁”相关的话题，都会涉及到。

1乐观锁VS悲观锁

站在锁冲突概率的预测角度

1.1乐观锁

假设数据一般情况下不会产生并发冲突，所以在数据进行提交更新的时候，才会正式对数据是否产生并发冲突进行检测，如果发现并发冲突了，则让返回用户错误信息，让用户决定如何去做。

1.2悲观锁

总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。

2.轻量级锁VS重量级锁

2.1轻量级锁

加锁解锁开销较小，效率更高

2.2重量级锁

开锁解锁开销较大，效率更低

站在加锁操作的开销角度

3.自旋锁VS挂起等待锁

3.1自旋锁

典型的轻量级锁，更大几率获取到锁，加锁速度快

3.2挂起等待锁

典型的重量级锁，“傻等”，被动的等待，省下来CPU去做别的工作，加锁的时间比较长。

4.互斥锁VS读写锁

4.1互斥锁

互斥锁：就是前面用过的像synchronized这样的锁，提供加锁和解锁两个操作。如果一个线程加锁了，另一个线程也尝试加锁，就会阻塞等待。

4.2读写锁

提供三种操作：（1）针对读加锁。（2）针对写加锁。（3）解锁

基于一个事实：多线程针对同一个变量并发读，这个时候是没有线程安全问题的，也不需要加锁控制。（读写锁就是针对这种情况采取的特殊的处理）

读锁和读锁之间没有互斥。写锁和写锁之间存在互斥。写锁和读锁之间存在互斥。（当前代码中，如果只是读操作，加读锁即可，如果有写操作，加写锁。）

5.公平锁VS非公平锁

5.1公平锁

这里的公平定义为：先来后到。B比C先来的，当A释放锁后，B就能先于C获取到锁。

5.2非公平锁

不遵守先来后到，B和C都有可能获取到锁。

OS内部的线程调度就可视为是随机的，如果不做任何额外的限制，锁就是非公平的，如果要想实现公平锁，就需要额外的数据结构，来记录线程们的先后顺序。

公平锁和非公平锁之间没有好坏之分，关键还得看适用场景。

6.可重入锁VS不可重入锁

6.1可重入锁

一个线程针对一把锁，连续加锁多次不会死锁。

6.2不可重入锁

一个线程针对一把锁，连续加锁两次，出现死锁。

7.关于synchronized

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

synchronized默认是乐观锁，但是如果发现当前锁竞争比较激烈，就会变成悲观锁。

（2）synchronized既是轻量级锁，也是重量级锁。

synchronized默认是轻量级锁，如果发现当前锁竞争比较激烈的话，就会变成重量级锁。

（3）synchronizaed这里的轻量级锁，是基于自旋锁的方式实现的。synchronized这里的重量级锁是基于挂起等待锁的方式实现的。

（4）synchronized不是读写锁。

（5）synchronized是非公平锁。

（6）synchrnized是可重入锁。

上述谈到的六种锁策略可以视为是“锁的形容词”

二、CAS

全称：Compare and swap 比较和交换

1.CAS涉及的下操作：

我们设内存中的原始数据V，旧的预期值A，需要修改的新值B

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

2.如果比较相等。将B写入V（交换）

3.返回操作是否成功

此处特别的是，上述的CAS的过程并不是通过一段代码实现的，而是通过一条CPU指令完成的。也就是说CAS操作是原子的，就可以在一定程度上回避线程安全问题，所以说我们解决线程安全问题除了加锁之外就又有了一个新的方向。

CAS可以理解为是CPU给咱们提供的一个特殊的指令，通过这个指令，就可在一定程度上处理线程安全问题。

2.CAS的应用场景

2.1实现原子类

JAVA标准库中提供的类

AtomicInteger count = new AtomicInteger(0);

伪代码

使用原子类来解决线程安全问题代码实现：

创建两个线程，t1和t2,在前面的学习中，当两个线程不加锁的时候就会出现bug，所以采用了加锁策略，这里使用原子类来实现不需要加锁也可以达到预期的效果：

public class ThreadD28 {
    public static void main(String[] args) throws InterruptedException {
        AtomicInteger count = new AtomicInteger(0);
        //使用原子类来解决线程安全问题
        Thread t1 = new Thread(() ->{
            for (int i = 0; i < 50000; i++) {
                //因为java不支持运算符重载，所以只能使用普通方法来表示自增自减
                count.getAndIncrement();
            }
        });
        Thread t2 = new Thread(() ->{
            for (int i = 0; i < 50000; i++) {
                count.getAndIncrement();
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(count.get());
    }
}

运行结果：

2.2实现自旋锁

伪代码

3.CAS中的ABA问题

CAS在运行中的核心，检查value和oldValue是否一致，如果一致就视为value没有被修改过，所以进行下一步的交换操作是没问题的。但是需要注意的是，这里的一致，可能是改过但是还原回来的。【买手机，可能是新机也有可能是翻新机，被销售商回收了，经过一些翻新的操作，将外壳换掉，重新包装】

下面看一个取钱的例子（概率极低！！）

以上情况发生的概率极低，但是这种问题一旦出现的话就是容易解决的，提前防患于未然是更好的选择。针对当前的问题，采取的方案就是加上一个版本号。想象成初始的版本号是1，每次修改的版本号都+1，然后进行CAS的时候，就不是以金额为准了，而是以版本号为基准，此时版本号要是没变就一定没发生改变（版本号只能增长，不能降低）

三、Synchronized原理

两个线程针对同一个对象加锁，就会产生阻塞等待。

synchronized内部还有一些优化机制，存在的目的是了让这个锁更高效更好用。

1.锁升级/锁膨胀

1.1无锁

1.2偏向锁

在进行加锁的时候，首先要进入到偏向锁的状态。偏向锁并不是真正的加锁，而是占个位置，有需要才会进行加锁，没需要就不必加。相当于“懒汉模式”中提到的懒加载一样。偏向锁的状态，做个标记（这个过程是非常轻量的）如果使用锁的过程中，没有出现锁竞争在synchronized执行完之后，解除偏向锁即可，但是如果使用过程中，另一个线程也尝试加锁，这个时候就会迅速的将偏向锁升级称为真正的加锁状态，另外的一个线程也只能阻塞等待了。

1.3轻量级锁

当synchronized发生锁竞争的时候，就会从偏向锁升级为轻量级锁，此时，synchronized相当于通过自旋的方式来进行加锁的（就类似于上述的CAS中的伪代码）

1.4重量级锁

如果要是很快别人就释放了锁，自旋还是划算的，但是如果迟迟拿不到锁，一直自旋是不划算的，synchronized自旋不是无休止的，自旋到一定程度，就会在再次升级成为重量级锁（挂起等待锁）。这个锁则是基于操作系统的原生API来进行加锁的，linux原生提供了mutex一组API，操作系统内核提供的加锁功能，这个锁会影响到线程的调度。此时如果线程进行了重量级的加锁，并且发生了锁竞争，此时线程会被放在阻塞队列中，不参与CPU的调度。然后直到锁被释放，这个线程才有机会被调度到，并且有机会获取到锁。