目录
🐑今日良言:追星赶月莫停留,平芜尽处是春山
🐂一、锁策略
锁策略是实现锁的时候,考虑出现锁竞争了该怎么办
乐观锁:预测锁竞争不是很激烈(这里做的工作相对更少)悲观锁:预测锁竞争很激烈(这里做的工作相对更多)悲观和乐观唯一的区分:主要是看预测锁竞争激烈程度的结论
重量级锁:加锁机制重度依赖了OS提供mutex(互斥锁)大量的用户态和内核态切换 很容易引发线程的调度轻量级锁:加锁机制尽可能不使用mutex,而是尽量在用户态用代码完成,实在搞不定了.再使用mutex少量的内核态和用户态切换 不太容易引发线程调度轻量级锁加锁解锁开销比较小,效率更高.重量级锁加锁解锁开销比较大,效率更低.
自旋锁:是一种典型的轻量级锁挂起等待锁:是一种典型的重量级锁自旋锁:获取锁失败,立即再次尝试获取锁,无线循环,一旦锁被释放,能第一时间感知到,从而获取到锁. 第一次获取锁失败,第二次尝试获取锁将在极短的时间内到来.相较于挂起等待锁:优点:没有释放CPU资源,一旦锁被释放,第一时间就能获取到,更高效,在锁持有时间比较短的场景中非常有用.缺点:如果锁的持有时间较长,就会浪费CPU资源.挂起等待锁:没有申请到锁的时候,线程被挂起,加入到阻塞队列中等待,当锁被释放后,有机会获取到锁.
互斥锁:就是synchronized这样的锁,提供了加锁解锁两个操作,如果一个线程加锁了,另一个线程也尝试加锁,就会阻塞等待读写锁:提供了针对读加锁 针对写加锁 解锁 三种操作.读加锁和读加锁之间,不互斥读加锁和写加锁之间,互斥写加锁和写加锁之间,互斥注:只要涉及到"互斥",就会产生线程的挂起等待.一旦挂起等待,再次唤醒就不知道隔了多久了.因此,尽可能减少"互斥"的机会,就是提高效率的重要途径.读写锁适用于"频繁读 不频繁写"的场景中.
假设有三个线程A B C. A先尝试获取锁,获取成功.B尝试获取锁,获取失败,阻塞等待.C最后尝试获取锁,获取失败,阻塞等待,当线程A释放锁以后,会发生什么呢?公平锁:遵循"先来后到".B比C先尝试加锁,当A释放锁之后,B就能比C先获取到锁非公平锁:不遵循"先来后到".B和C都可能获取到锁.举个例子:你和你的兄弟们一起追一个女生,当女生和自己的对象分手后,先追女生的男生先上位,这就是公平锁.如果是女生不按照先后顺序,挑一个自己顺眼的,就是非公平锁注:操作系统内部的线程调度可以视为是随机的,如果不做任何额外的限制,锁就是非公平锁如果要实现公平锁,就需要依赖额外的数据结构,来记录线程们的先后顺序.公平锁和非公平锁没有好坏之分,关键还是看适用场景
可重入锁:一个线程针对一把锁加锁两次,不出现死锁.不可重入锁:一个线程针对一把锁加锁两次,出现死锁.
🐼二、CAS
1.什么是CAS?
CAS全称: compare and swap. 根据字面意思理解为"比较并交换"
一个CAS涉及到以下操作:
假设内存中的原数据是V,旧的预期值是A,需要修改的新值是B
1).先比较A和V是否相等(比较)
2).如果比较相等,就将B写入V(交换)
3).返回操作是否成功
在上述交换过程中,大多数情况下并不关心B后续的情况,更关心的是V这个变量的情况
这里说是交换,其实可以近似理解成:赋值
此处最特别的地方是:上述这个CAS过程并非是通过一段代码实现的,而是通过一条CPU指令完成的,这说明CAS操作是原子的!!!!!
CAS可以理解成是CPU提供的一个特殊指令,通过这个指令可以一定程度上处理线程安全问题.
CAS的伪代码:
boolean CAS(value, oldValue, swapValue) {
if (value == oldValue) {
value = swapValue;
return true;
}
return false;
}2.CAS的应用场景
CAS的应用场景主要有两个:
1).实现原子类
java标准库提供了java.util.concurrent.atomic包,里面的类都是基于CAS的方式实现的,其中最典型的就是AtomicInteger类,其中的getAndIncrement相当于i++操作
通过下面一个练习来理解原子类:
两个线程增加同一个变量
public class Exercise { public static void main(String[] args) throws InterruptedException { AtomicInteger integer = new AtomicInteger(0); Thread t1 = new Thread(() -> { for (int i = 0; i < 50000; i++) { integer.getAndIncrement();// 相当于i++操作 } }); Thread t2 = new Thread(() -> { for (int i = 0; i < 50000; i++) { integer.getAndIncrement();// 相当于i++操作 } }); t1.start(); t2.start(); // 为了让主线程等待t1线程和t2线程执行完毕 t1.join(); t2.join(); System.out.println(integer); } }运行结果:
2).实现自旋锁
通过下面的伪代码理解:
public class SpinLock { private Thread owner = null; public void lock(){ // 通过 CAS 看当前锁是否被某个线程持有. // 如果这个锁已经被别的线程持有, 那么就自旋等待. // 如果这个锁没有被别的线程持有, 那么就把 owner 设为当前尝试加锁的线程. while(!CAS(this.owner, null, Thread.currentThread())){ } } public void unlock (){ this.owner = null; } }
3.ABA问题
CAS运行的核心:检查value与oldValue是否一致.如果一致,就视为value中途没有被修改过,所以进行下一步交换操作是没问题的.
但是,这里的一致,可能是value没有被修改过,也有可能是value被修改过又改回来了.
把value的值设为A的话,CAS判定value为A,此时value的值可能始终为A,也可能是value本来是A,被修改为了B,最后又还原成了A.
这就是CAS的典型问题:ABA问题
通过下面的实例来进一步理解ABA问题
假设 张三 有 100 存款 . 张三 想从 ATM 取 50 块钱 . 取款机创建了两个线程 , 并发的来执行 -50操作 .我们期望一个线程执行 -50 成功 , 另一个线程 -50 失败 .如果使用 CAS 的方式来完成这个扣款过程就可能出现问题 .正常的过程1) 存款 100. 线程 1 获取到当前存款值为 100, 期望更新为 50; 线程 2 获取到当前存款值为 100, 期望更新为 50.2) 线程 1 执行扣款成功 , 存款被改成 50. 线程 2 阻塞等待中 .3) 轮到线程 2 执行了 , 发现当前存款为 50, 和之前读到的 100 不相同 , 执行失败 .
异常的过程1) 存款 100. 线程 1 获取到当前存款值为 100, 期望更新为 50; 线程 2 获取到当前存款值为 100, 期望更新为 50.2) 线程 1 执行扣款成功 , 存款被改成 50. 线程 2 阻塞等待中 .3) 在线程 2 执行之前 ,张三 的朋友正好给张三转账 50, 账户余额变成 100 !!4) 轮到线程 2 执行了 , 发现当前存款为 100, 和之前读到的 100 相同 , 再次执行扣款操作这个时候 , 扣款操作被执行了两次 !!!
解决ABA问题的方法:给要修改的值,引入版本号
引入版本号后,解决刚才转账异常的情况:假设 张三 有 100 存款 . 张三 想从 ATM 取 50 块钱 . 取款机创建了两个线程 , 并发的来执行 -50操作 .我们期望一个线程执行 -50 成功 , 另一个线程 -50 失败 .为了解决 ABA 问题 , 给余额搭配一个版本号 , 初始设为 1.1) 存款 100. 线程 1 获取到 存款值为 100, 版本号为 1, 期望更新为 50; 线程 2 获取到存款值为 100,版本号为 1, 期望更新为 50.2) 线程 1 执行扣款成功 , 存款被改成 50, 版本号改为 2. 线程 2 阻塞等待中 .3) 在线程 2 执行之前 , 张三 的朋友正好给滑稽转账 50, 账户余额变成 100, 版本号变成 3.4) 轮到线程 2 执行了 , 发现当前存款为 100, 和之前读到的 100 相同 , 但是当前版本号为 3, 之前读到的版本号为 1, 版本小于当前版本 , 认为操作失败 .
🐭三、Synchronized
1).synchronized既是一个悲观锁,也是一个乐观锁
synchronized默认是乐观锁,但是如果发现锁竞争激烈,就会变成悲观锁
2).synchronized既是一个轻量级锁,也是一个重量级锁
synchronized默认是轻量级锁,但是如果发现锁竞争激烈,就会变成重量级锁
3).synchronized这里的轻量级锁,是基于自旋锁的方式实现的.
synchronized这里的重量级锁,是基于挂起等待锁的方式实现的.
4).synchronized 不是读写锁
5).synchronized 是非公平锁
6).synchronized 是可重入锁
synchronized内部有一些优化机制,存在的目的就是为了让这个锁更高效更好用.
1.加锁工作过程(锁升级/锁膨胀)
jvm将synchronized 锁分为:无锁 偏向锁 轻量级锁 重量级锁 状态,会根据情况,进行依次升级.
1).偏向锁
第一个尝试加锁的线程,优先进入偏向锁状态.偏向锁不是真的"加锁",而是做个偏向锁标记,记录这个锁属于哪个线程.
如果整个使用锁的过程中,没有出现锁竞争,在synchronized执行完之后,取消偏向锁即可
如果整个使用锁的过程中.另一个线程也尝试加锁,那么在它加锁之前,迅速的把偏向锁状态升级为加锁状态,另一个线程只能阻塞等待了.
2).轻量级锁
随着其它线程进入竞争,偏向锁状态被消除,进入轻量级锁状态(自适应的自旋锁)
此处的轻量级锁就是通过CAS来实现的.
自旋操作是一直让CPU空转,比较浪费CPU资源,因此,此处的自旋不会一直持续进行,而是达到一定的时间/重试次数,就不在自旋了,也就是所谓的"自适应".
3).重量级锁
如果竞争进一步激烈,自旋不能快速获取到锁,就会升级为重量级锁
此处的重量级锁就是指用到内核提供的mutex
2.锁消除
编译器+JVM智能的判定:当前的代码是否真的需要加锁,如果这个场景不需要加锁,程序猿加了,就自动的把锁消除.
3.锁粗化
一段逻辑中如果出现多次加锁解锁,编译器+JVM会自动进行锁的粗化.
锁的粒度:synchronized包含的代码越多,粒度就越粗,包含的代码越少,粒度就越细.
通常情况下,锁的粒度细一点比较好.
加锁的部分代码,是不能并发执行的,锁的粒度越细,能并发执行的代码就越多,反之越少.
但是,有的情况下,锁的粒度粗一些反而好,例如:两次加锁解锁之间间隙非常小,这种情况不如直接使用一次大锁搞定.
🐇四、JUC
JUC（java.util.concurrent），这是Java并发包，放了很多并发编程（多线程）相关的组件。
1、Callable
类似于 Runnable 。
Runnable 用来描述一个任务，描述的任务没有返回值。
Callable 也是用来描述一个任务，描述的任务有返回值。
如果需要使用一个线程单独的计算出某个结果来，此时使用 Callable 是比较合适的。
代码如下：
package com.example.demo;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.FutureTask;
/**
* @author 26568
* @date 2024-05-12 11:04
*/
public class JUCTest {
public static void main(String[] args) throws ExecutionException, InterruptedException {
Callable<Integer> callable = new Callable<Integer>() {
// 相当于 Runnable 的 run 方法，run 方法的返回值是 void
// 此处的 call 方法的返回值是 泛型参数
@Override
public Integer call() throws Exception {
return 10;
}
};
// 未来的待执行的一个任务
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 = "+result);
}
}
2、ReentrantLock
这也是一种锁，也是可重入的。
synchronized 是直接基于代码块的方式来加锁解锁的。
ReentrantLock 更传统，使用了 lock 和 unlock 方法加锁和解锁。
ReentrantLock 基本代码如下：
上述这种写法可能会导致 unlock 执行不到：如果 lock 和 unlock 方法之间存在 return 或者异常都可能导致 unlock 执行不到，因此，为了确保 unlock 一定执行到，需要使用 finally 。
ReentrantLock 的优点主要有以下几点：
1、ReentrantLock 提供了公平锁版本的实现。
2、ReentrantLock 提供了更灵活的等待方式：tryLock
对于 synchronized 来说，提供的加锁操作是“死等”，如果获取不到锁就一直阻塞等待。
无参数版本表示，能加锁就加，加不上就放弃。
有参数版本表示，指定了超时时间，加不上锁会等待一段时间，如果时间到了也没加上，就放弃。
3、ReentrantLock 提供了一个更强大、更方便的等待通知机制。
synchronized 搭配的事 notify ，notify 是随机唤醒一个 wait 的线程。
ReentrantLock 搭配一个 Condition 类，可以指定线程唤醒。
3、Semaphore（信号量）
在操作系统中也有信号量概念，但和此处的信号量并不是一个东西，此处的信号量是 Java 把操作系统原生的信号量封装了一下。
信号量的本质就是一个计数器，描述了“可用资源的个数”。信号量提供了两个操作：
P操作：申请一个可用资源，计数器 -1
V操作：释放一个可用资源，计数器 +1
P操作要是计数器为 0 了，继续 P操作，就会出现阻塞等待的情况。
锁可以视为视为是计数器为 1 的信号量，二元信号量。
4、CountDownLatch
主要用来协调多个线程之间的执行顺序，让一个或多个线程等待其他线程完成特定任务后再继续执行。CountDownLatch 通过一个计数器实现这一功能。
计数器的初始值由构造方法确定，表示需要等待的任务数量，每当一个任务完成时，就会调用 countDown() 方法会使计数器 -1，其它线程通过 await() 方法阻塞等待，直到计数器减为0，此时，这些阻塞等待的线程会被唤醒继续执行。
举例：
如果应用程序在启动时，需要初始化多个服务，主线程可以使用 CountDownLatch 等待所有初始化任务完成后再进行下一步操作。每个初始化任务在完成时减少计数器，当所有任务都完成，计数器归零，主线程继续执行操作。
总结来说，CountDownLatch 的核心作用是实现线程间的同步，确保某些关键代码或流程在特定条件满足后（即计数器减为0）才会被执行。
以上就是这篇博客的主要内容，如有帮助，可否点一手关注，期待后续内容
227
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
