多线程-进阶

常见的锁策略

乐观锁和悲观锁
这不是两把具体的锁, 这是两类锁

乐观锁: 预测锁的竞争不是很激烈
悲观锁: 预测锁的竞争会很激烈

乐观和悲观说的都不是绝对的, 唯一的区分就是看预测锁竞争激烈程度的结论, 这两种锁的背后工作是截然不同的,

轻量级锁和重量级锁

轻量级锁加锁解锁开销比较小, 效率更高
重量级锁加锁解锁开销比较大, 效率更低

在大多数情况下,

乐观锁, 是一个轻量级锁(不能完全保证)
悲观锁, 是一个重量级锁(不能完全保证)

自旋锁和挂起等待锁

自旋锁是一种典型的轻量级锁
挂起等待锁是一种典型的重量级锁

自旋锁: 一旦锁释放了,自旋锁能第一时间感知到, 从而有机会获取到锁, 但是会占用大量的系统资源
挂起等待锁: 获取锁的实际可能会迟, 但是它把CPU省下来了

互斥锁和读写锁

互斥锁: 像 synchronized 这样的锁提供加锁和解锁两个操作如果一个线程被加锁了, 另一个线程尝试加锁就会阻塞等待

读写锁: 提供了三个操作:
1, 针对读加锁,
2. 针对写加锁
3. 解锁

这里的读加锁, 写加锁, 基于一个事实:多线程针对同一个变量并发读,这个是没有线程安全的, 也不需要加锁控制, 读写锁就是针对这种情况锁采取的特殊处理

读锁和读锁之间没有互斥
写锁和写锁之间存在互斥
写锁和读锁之间存在互斥

当前代码中, 如果只是读操作, 加读锁就可以了, 如果有写操作就加写锁.
假设当前有一组线程都去读(加读锁), 这些线程是没有锁竞争的, 也没有安全问题, 又快又准.
假设当前有一组线程既有读又有写, 这才会产生锁竞争, 其实在很多实际开发中, 读操作非常高频, 比写操作多很多. 这样用写锁, 就会提高效率.

公平锁锁和非公平锁

那么什么是公平呢?
此处把公平定义为"先来后到"

公平锁: 当一个资源解锁后, 就由等待队列中最早的来上位
非公平锁: 当一个资源解锁后, 所有等待的都一起来竞争, 各凭本事

操作系统和Java中 synchronized 原生都是"非公平锁"
操作系统这里针对加锁的控制, 本身就是依赖线程调度顺序的, 这个调度是随机的, 不会考虑这个线程等了多长时间.
要实现公平锁, 就得在这个基础上, 引入一些额外的东西(引入一个队列, 让这些加锁的线程去排队)

可冲入锁和不可重入锁

可重入锁: 一个线程对一把锁, 连续加锁多次都不会死锁
不可冲入锁: 一个线程对一把锁, 连续加锁两次出现死锁

synchronized

synchronized 既是一个悲观锁, 也是一个乐观锁
synchronized 默认是一个乐观锁, 但是如果发现当前锁竞争比较激烈, 就会变成悲观锁
synchronized 既是一个轻量级锁, 也是一个重量级锁
synchronized默认是一个轻量级锁, 如果发现锁竞争比较激烈, 就会转换成重量级锁
synchronized 这里的轻量级锁是基于自旋锁的方式实现的
synchronized 这里的重量级锁是基于挂起等待锁的方式实现的
synchronized 不是读写锁
synchronized 是非公平锁
synchronized 是可冲入锁

总结: 上面说的6种锁策略, 可以视为"锁的形容词"

CAS

CAS: 全称Compare and swap，字面意思:”比较并交换“

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

比较 A 与 V 是否相等。（比较）
如果比较相等，将 B 写入 V。（交换）
返回操作是否成功。

那么上述的CAS过程, 就是这样一个简单的交换, 有什么特别之处呢?

这里最特别的地方就是, 这整个 CAS 的过程, 并非是通过一段代码来实现的, 而是通过一条CPU指令来完成的, 也就是说CAS是原子的. 这样就可以在一定程度上回避线程安全问题.

这样的话, 咱们得线程安全问题除了加锁外, 就又有了一个新的方向.

总结:CAS 可以理解是 CPU 给咱们提供的一个特殊指令, 通过这个特殊指令, 就可以一定程度的处理线程安全问题.

**CAS 的应用场景 **

实现原子类
Java 标准库中提供的类

		//定义了一个原子的变量count
        AtomicInteger count = new AtomicInteger(0);

下面举一个例子:
通过这个原子的变量, 来实现两个线程对同一个变量的++操作

import java.util.concurrent.atomic.AtomicInteger;

public class ThreadDemo12 {
    public static void main(String[] args) throws InterruptedException {
        // 这些原子类就是基于 CAS 实现了自增自减等操作, 不用加锁也是线程安全的.
        AtomicInteger count = new AtomicInteger(0);

        // 使用原子类来解决线程安全问题
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                // 因为 Java 不支持运算符重载, 所以只能通过普通方法来表示自增自减
                count.getAndIncrement();   // count++
                //count.incrementAndGet();   // ++count
                //count.getAndDecrement();   // count--
                //count.decrementAndGet();   // --count
            }
        });

        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                count.getAndIncrement();   // count++
            }
        });

        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(count);
    }
}

CAS的典型问题: ABA问题

CAS 在运行中的核心, 检查 value 和 oldValue 的值, 如果一致, 就是为没有被修改过, 就进行下一步操作.

那么这里的一致, 可不可能是被修改过, 又还原回来了呢, 这是有可能的

把 value 的值设置为A,
CAS 判定 value 为 A , 此时可能确实 value 始终是A
但是也可能 value 的值本来是 A , 被改成了 B , 又被还原成了A…

那么这如何应对呢?
那就是加版本号(版本号直接增长, 不能降低)

Synchronized 原理
两个线程针对同一个线程加锁, 就会产生阻塞等待.
synchronized 内部其实还有一些优化机制, 目的就是为了让这个锁更加高效, 更好用.

锁升级/锁膨胀

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

synchronized {
}

当代码执行到这个代码块中, 加锁过程, 就可能会经历这几个阶段

进行加锁的时候, 首先会进入偏向锁状态, (并不是真正的加锁, 而只是占个位置, 有需要再真正加锁, 没需要就算了)

这个偏向锁的过程就像是"懒汉模式"中提到的"懒加载"一样, “非必要, 不加锁”.
synchronized 的时候, 并不是真的加锁, 而是线偏向锁状态, 做个标记, (这个过程非常轻量), 如果使用锁的整个过程中, 都没有出现锁竞争, 在 synchronized 执行完之后, 取消偏向即可.
但是, 如果使用过程中, 另一个线程也尝试加锁, 在它加锁之前, 迅速的把偏向锁升级为真正的加锁状态, 另一个线程也就只能阻塞等待了.

这样做的好处就是:如果没有锁冲突, 开销就最低了

当 synchronized 发生锁竞争的时候, 就会从偏向锁, 升级为轻量级锁, 此时, synchronized相当于是通过自旋的方式来进行加锁,

如果要是别人很快就释放锁了, 自旋是很划算的, 但是如果迟迟拿不到锁, 一直自旋, 并不划算.
synchronized自旋不是无休止的自旋, 自旋到一定程度之后, 就会再次升级成重量级锁(挂起等待锁)

重量级锁(挂起等待锁) 则是基于操作系统原生的 API 来加锁了. linux 原生提供了 mutex 一组 API . 操作系统内核提供的加锁功能, 这个锁就会影响到线程的调度了
此时, 如果线程进行了重量级的加锁, 并且发生了锁竞争, 此时线程就会放到阻塞队列中, 暂时不参与 CPU 调度了, 知道锁被释放了, 才有机会被调度到. 并且有机会获取到锁.(一旦当前线程被切换出 CPU 了, 这就是个比较低效的事了)

锁消除

编译器智能的判定, 看当前代码是否需要真的加锁, 如果这个场景不需要加锁, 程序员加锁了, 就自动把锁给消除了.

StringBuffer , 关键方法都带有synchronized
但是在单线程中使用, StringBuffer , 此时就是 synchronized加了也白加, 编辑器会自动把这些加锁操作给干掉.

锁粗化

锁的粒度, synchronized 包含的代码越多, 粒度就越粗, 包含的代码越少, 粒度就越细

通常情况下, 认为锁的粒度细一点比较好, 因为加锁的代码, 是不能并发执行的, 锁的粒度越细, 能并发的代码就越多; 反之就越少, 但是有的情况下, 锁的粒度粗一些, 反而更好.

如果两次加锁之间, 间隙非常小, 这种情况就不如一次大锁直接搞定

JUC(java.util.concurrent) 的常见类

Callable 接口

Callable 是什么?
Callable 是一个 interface . 相当于把线程封装了一个 “返回值”. 方便程序员借助多线程的方式计算结果.
Callable 和 Runnable 相当, 都是描述一个 “任务”. Callable 描述的是带有返回值的任务,Runnable 描述的是不带返回值的任务.
Callable 通常需要搭配 FutureTask 来使用. FutureTask 用来保存 Callable 的返回结果. 因为
Callable 往往是在另一个线程中执行的, 啥时候执行完并不确定.
FutureTask 就可以负责这个等待结果出来的工作.

下面举个例子
使用 Callable 计算1+2+3+…+1000

创建一个匿名内部类, 实现 Callable 接口. Callable 带有泛型参数. 泛型参数表示返回值的类型.
重写 Callable 的 call 方法, 完成累加的过程. 直接通过返回值返回计算结果.
把 callable 实例使用 FutureTask 包装一下.
创建线程, 线程的构造方法传入 FutureTask . 此时新线程就会执行 FutureTask 内部的 Callable 的call 方法, 完成计算. 计算结果就放到了 FutureTask 对象中.
在主线程中调用 futureTask.get() 能够阻塞等待新线程计算完毕. 并获取到 FutureTask 中的结果.

import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.FutureTask;

public class ThreadDemo13 {
    public static void main(String[] args) throws ExecutionException, InterruptedException {
        // 使用 Callable 计算1+2+3+...+1000
        Callable<Integer> callable = new Callable<Integer>() {
            @Override
            public Integer call() throws Exception {
                int sum = 0;
                for (int i = 1; i <= 1000; i++) {
                    sum += i;
                }
                return sum;
            }
        };

        // 想当于一个小票, 使得返回给谁不会出错```
        FutureTask<Integer> futureTask = new FutureTask<>(callable);
        Thread t = new Thread(futureTask);
        t.start();

        // get 方法就是获取结果, get会发生阻塞, 直到Callable 执行完毕, get才阻塞完毕, 才获取结果
        Integer result = futureTask.get();
        System.out.println(result);
        
    }
}

ReentrantLock

ReentrantLock 也是可重入锁. “Reentrant” 这个单词的原意就是 “可重入”
synchronized 是直接基于代码块来加锁解锁的
ReentrantLock 更传统, 使用 lock 和 unlock 方法加锁解锁

ReentrantLock reentrantLock = new ReentrantLock();
        reentrantLock.lock();

        reentrantLock.unlock();

这样就带来一个问题, reentrantLock 可能执行不到
比如说, 这加锁的代码块中, 存在 return, 或者异常, 就可能导致 unlock 执行不到

那么如何解决这个问题呢?
那就是使用把 unlock放到 finely 中

lock.lock(); 
try {  
// working  
} finally {  
lock.unlock()  
}

那这个锁有什么优势呢?

ReentrantLock 提供了公平锁版本的实现

 ReentrantLock reentrantLock = new ReentrantLock(true);

对于 synchronized 来说, 提供的加锁方式就是死等, 只要获取不到锁, 就一直阻塞等待.
而 ReentrantLock 提供了更灵活的等待方式.

        reentrantLock.tryLock();

这个是无参数版本, 能加上锁就加, 不能加上就放弃.

        reentrantLock.tryLock(5, TimeUnit.SECONDS);

这是有参数版本, 制定了超时时间, 加不上锁就等待一会, 如果时间到了也没等到就放弃

ReentrantLock 提供了一个更强大, 更方便的等待通知机制
synchronized 搭配的是 wait, notify , notify 的时候是随机唤醒一个wait 的线程
ReentrantLock 搭配一个Condition 类. 进行唤醒的时候可以唤醒指定的线程

结论: 虽然 ReentrantLock 有一定的优势, 但是在实际开发中大部分还是使用 synchronized.

原子类

原子类内部用的是 CAS 实现，所以性能要比加锁实现 i++ 高很多。原子类有以下几个

AtomicBoolean
AtomicInteger
AtomicIntegerArray
AtomicLong
AtomicReference
AtomicStampedReference

以 AtomicInteger 举例，常见方法有

方法	操作
addAndGet(int delta);	i += delta;
decrementAndGet();	–i;
getAndDecrement();	i–;
incrementAndGet();	++i;
getAndIncrement();	i++;

基于CAS, 确实更高效的解决了线程安全, 但是CAS不能代替锁, CAS适用范围是有限的, 不像锁适用范围那么广

信号量 Semaphore

信号量本质是就是一个 “计数器” ,描述了可用资源的个数

p操作: 申请一个可用资源, 计数器就要 -1;
v操作: 释放一个可用资源, 计数器就要 +1;

p操作如果要是计数器为0了, 继续p操作, 就会阻塞等待

锁可以视为计数器为1的信号量, 二元信号量, 锁是信号量的一种特殊情况

/**
 * @describe
 * @author chenhongfei
 * @version 1.0
 * @date 2023/10/21
 */
package thread;

import java.util.concurrent.Semaphore;

public class ThreadDemo15 {
    public static void main(String[] args) throws InterruptedException {
        Semaphore semaphore = new Semaphore(3);
        semaphore.acquire();
        System.out.println("执行一次p操作");
        semaphore.acquire();
        System.out.println("执行一次p操作");
        semaphore.acquire();
        System.out.println("执行一次p操作");
        semaphore.acquire();
        System.out.println("执行一次p操作");
    }
}

最后一次p操作就阻塞等待了

代码中也是可以Semaphone 来实现类似锁的效果, 来保证线程安全

多线程使用哈希表

HashMap 是线程不安全的
HashTable 是线程安全的(给一些关键方法加了 synchronized)

更推荐使用 ConcurrentHashMap 更优化的线程安全哈希表

ConcurrentHashMap 进行了哪些优化, 比HashTable 好在哪里? 和 HashTable 的区别是啥

1. 最大的优化之处: ConcurrentHashMap 相比于 HashTable 大大缩小了锁冲突的概率. (把一把大锁, 转化为了多把小锁)
HashTable 做法是直接在方法上加 synchronized, 相当于是给 this 加锁,
只要操作哈希表上的任意元素, 都会产生加锁, 也就都可能发生锁冲突

ConcurrentHashMap 做法是, 每个链表有各自的的锁, (不是一起共用一个锁了)
具体来说, 就是使用每个链表的头结点, 作为锁对象, (两个线程针对同一个锁对象进行加锁, 才会产生锁竞争, 才会阻塞等待, 针对不同的对象, 就没有锁竞争了)(JDK1.8 及其以后版本是这样, 在JDK1.7和之前是使用"分段锁")
在这里插入图片描述