目录
一、线程安全
1.1 经典线程不安全案例:
线程安全是多线程中最核心的部分,因此线程安全也是难点和面试的考点,可以说只要写多线程代码,基本上都会涉及到。下面我就举一个经典的线程不安全案例,友友们来观察一下线程不安全。(注意要把自增的次数写大一点,因为如果次数太小,线程 2 还没启动线程 1 就已经运行结束了,所以看不到线程不安全的情况)。
public class Main {
private static int count = 0;
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
//对 count 变量进行自增 5w次
for (int i = 0; i < 50000; i++) {
count++;
}
});
Thread t2 = new Thread(() -> {
//对 count 变量进行自增 5w次
for (int i = 0; i < 50000; i++) {
count++;
}
});
t1.start();
t2.start();
t1.join();
t2.join();
// 预期值为 10w
System.out.println(count);
}
}
案例的预期值应为 10w。
案例的结果如下:
如果友友们,把这个案例自己拿起来跑,会发现每次的运行的结果都有差异,不符合我们的预期,显然出现了线程不安全的问题。
1.2 线程安全的概念:
线程安全的确切定义是复杂的,但我们可以这样认为:如果在多线程环境下代码运行的结果是符合我们预期的,即在单线程环境应该的结果,则说这个程序是线程安全的。
1.3 线程不安全的原因:
1.3.1 案例刨析:
如果我们将上述的案例部分改为下面红色方框(可以解决问题,但不是一种好的方法,因为这样写就无法利用到多线程的优势,更优的方法在下面的 synchronized 中会详细介绍),那么运行的结果就符合我们的预期了。
其实就是把多线程并发执行改为串行执行。 那么我们就可以确定是因为多线程才导致出现这个现象。上面不安全案例的执行过程大致如下:()中的数字表示执行顺序。如果对工作内存和主内存不了解的话,在下面的 Java 内存模型中有解释。
之所以会出现少加 5 的情况是因为,两个线程在进行抢占式执行。
那么为什么多线程会出现这种现象呢?
线程调度是随机的,这是线程安全问题的罪魁祸首,随机调度使⼀个程序在多线程环境下,执行顺序存在很多的变数。程序猿必须保证在任意执行顺序下,代码都能正常工作。
1.3.2 线程不安全的名词解释:
• 原子性:
• 什么是原子性?
我们把⼀段代码想象成⼀个房间,每个线程就是要进入这个房间的人。如果没有任何机制保证,A进入房间之后,还没有出来,B 是不是也可以进入房间,打断 A 在房间里的隐私。这个就是不具备原子性。一条 Java 语句不一定是原子的,也不一定只是一条指令。比如我们刚才看到 count++,其实是由三步操作组成的:(1)从内存把数据读到 CPU。(2)进行数据更新。(3)把数据写回到 CPU。
• 不保证原子性会给多线程带来什么问题?
如果一个线程正在对一个变量操作,中途其他线程插入进来了,如果这个操作被打断了,结果就可能是错误的。(这点也和线程的抢占式调度密切相关。如果线程不是 "抢占" 的,就算没有原子性,也问题不大)。
• 可见性:
可见性指,一个线程对共享变量值的修改,能够及时地被其他线程看到。
• 指令重排序:
什么是代码重排序,假如:一段代码是这样的:(1)去前台取下 U 盘。(2)去教室写 10 分钟作业。(3)去前台取下快递。
如果是在单线程情况下,JVM、CPU指令集会对其进行优化,比如,按 1->3->2的方式执行,也是没问题,可以少跑一次前台。这种叫做指令重排序。
编译器对于指令重排序的前提是 "保持逻辑不发生变化"。这⼀点在单线程环境下比较容易判断,但是在多线程环境下就没那么容易了,多线程的代码执行复杂程度更高,编译器很难在编译阶段对代码的执行效果进行预测,因此激进的重排序很容易导致优化后的逻辑和之前不等价。重排序是一个比较复杂的话题,涉及到 CPU 以及编译器的一些底层工作原理,此处不做过多讨论。
1.3.3 Java 内存模型 (JMM):
Java 虚拟机规范中定义了 Java 内存模型。目的是屏蔽掉各种硬件和操作系统的内存访问差异,以实现让 Java 程序在各种平台下都能达到一致的并发效果。
• 线程之间的共享变量存在主内存(Main Memory)
• 每一个线程都有自己的 "工作内存" (Working Memory)
• 当线程要读取一个共享变量的时候,会先把变量从主内存拷贝到工作内存,再从工作内存读取数据。
• 当线程要修改一个共享变量的时候,也会先修改工作内存中的副本,再同步回主内存。
由于每个线程有自己的工作内存,这些工作内存中的内容相当于同一个共享变量的 "副本"。此时修改线程 1 的工作内存中的值,线程 2 的工作内存不一定会及时变化。
此时引入了两个问题:
• 为啥要整这么多内存?
实际并没有这么多 "内存"。这只是 Java 规范中的一个术语,是属于 "抽象" 的叫法。所谓的 "主内存" 才是真正硬件角度的 "内存"。而所谓的 "工作内存",则是指 CPU 的寄存器和高速缓存。
• 为啥要这么麻烦的拷来拷去?
因为 CPU 访问自身寄存器的速度以及高速缓存的速度,远远超过访问内存的速度(快了 3 - 4 个数量级,也就是几千倍,上万倍)。
那么接下来问题又来了,既然访问寄存器速度这么快,还要内存干啥?
答案就是一个字:贵。
1.3.4 解决线程不安全问题:
下面这几点是线程不安全问题的原因,友友们一定要记住。
1. 线程在系统中是随机调度的,抢占式执行的。(线程不安全的罪魁祸首,万恶之源)。
2. 当前代码中,多个线程同时修改同一个变量。
3. 线程针对变量的修改操作,不是“原子”的。
4. 内存可见性问题,引起的线程不安全。
5. 指令重排序,引起的线程不安全。
我们从原因入手,解决问题。
原因 1:我们无法干预,这是操作系统自己分配的,我们干预不了。
原因 2:是一个切入点,但是在 Java 中,这样的做法不是很普适(因为当前代码,就是要多线程修改同一个变量),只是针对一些特定场景是可以的。
原因 3:这是解决线程安全问题,最普适的方案。我们就从原因 3 入手。
我们可以通过一些操作,把上述一系列 “非原子” 的操作,打包成一个 “原子” 操作。就是下面要介绍的 synchronized 加锁操作。
下面给出的案例大家看看就行,关于 synchronized 后续会详细介绍。
public class Main {
private static int count = 0;
public static void main(String[] args) throws InterruptedException {
Object lock = new Object();
Thread t1 = new Thread(() -> {
//对 count 变量进行自增 5w次
for (int i = 0; i < 50000; i++) {
synchronized(lock){
count++;
}
}
});
Thread t2 = new Thread(() -> {
//对 count 变量进行自增 5w次
for (int i = 0; i < 50000; i++) {
synchronized(lock){
count++;
}
}
});
t1.start();
t1.join();
t2.start();
t2.join();
// 预期值为 10w
System.out.println(count);
}
}
案例结果:可以看到符合我们的预期值,说明线程不安全问题被成功解决。
二、synchronized 关键字
大家一定要去多练习一下 synchronized 的读法,和拼写。因为面试的时候,说出来要让面试官听得懂。注意:这是个 Java 的关键字。(注意不是方法,里面的功能是 JVM 内部实现的)。
利用 synchronized 我们就可以把花括号里面的非原子操作,打包成原子。从而不允许别的线程 “插队”。
2.1 synchronized 的特性:
2.1.1 互斥:
synchronized 会起到互斥效果,某个线程执行到某个对象的 synchronized 中时,其他线程如果也执行到同⼀个对象 synchronized 就会阻塞等待。
• 加锁:t1 加上锁之后,t2 也尝试进行加锁,就会阻塞等待(系统内核控制),在 Java 中就能看到 BLOCKED状态,进入 synchronized 修饰的代码块,相当于加锁。
• 解锁:直到 t1 解锁之后,t2 才有可能(可能还有别的线程也在等待)拿到锁,退出synchronized 修饰的代码块,相当于解锁。
synchronized 用的锁是存在 Java 对象头里的。
• 理解"阻塞等待":
针对每一把锁,操作系统内部都维护了一个等待队列。当这个锁被某个线程占有的时候,其他线程尝试进行加锁,就加不上了,就会阻塞等待,⼀直等到之前的线程解锁之后,由操作系统唤醒一个新的线程,再来获取到这个锁。
注意:
• 上一个线程解锁之后,下一个线程并不是立即就能获取到锁,而是要靠操作系统来 "唤醒"。这也就 是操作系统线程调度的一部分工作。
• 假设有 A B C 三个线程,线程 A 先获取到锁,然后 B 尝试获取锁,然后 C 再尝试获取锁,此时 B 和 C 都在阻塞队列中排队等待,但是当 A 释放锁之后,虽然 B 比 C 先来的,但是 B 不⼀定就能获取到锁,而是是和 C 重新竞争,并不遵守先来后到的规则。
synchronized的底层是使用操作系统的 mutex lock实现的。
2.1.2 可重入:
synchronized 同步块(花括号里面内容)对同一条线程来说是可重入的,不会出现自己把自己锁死的情况。
• 理解 "把自己锁死":
⼀个线程没有释放锁,然后又尝试再次对同一对象加锁。按照之前对于锁的设定,第二次加锁的时候,就会阻塞等待,直到第一次的锁被释放,才能获取到第二个锁,但是释放第⼀个锁也是由该线程来完成,结果这个线程已经躺平了,啥都不想干了,也就无法进行解锁操作。这时候就会死锁。
这样的锁称为:不可重入锁
Java 中的 synchronized 是可重入锁,因此没有上面的问题。
案例如下:
public class demo1 {
public static void main(String[] args) {
Object lock = new Object();
Thread t = new Thread(() -> {
synchronized(lock){
synchronized(lock){
System.out.println("hello t");
}
}
System.out.println("t.end");
});
t.start();
}
}
案列结果演示如下:
那么 synchronized 是如何完成可重入锁的这种机制呢?
在可重入锁的内部,包含了 "线程持有者" 和 "计数器" 两个信息。
• 如果某个线程加锁的时候,发现锁已经被人占用,但是恰好占用的正是自己,那么仍然可以继续获取到锁,并让计数器自增。
• 解锁的时候计数器递减为 0 的时候,才真正释放锁。(才能被别的线程获取到)
2.2 synchronized 使用示例:
在 Java 中任何一个对象都可以作为加锁的对象(Java 中特定独立的设定,其他语言中C++,Go,Python....)都是只有极少数特定的对象可以用来加锁。
synchronized 后面带上()里面就是写的 “锁对象”。
注意:
锁对象的用途,有且只有一个,就是用来区分两个线程是否是针对同一个对象加锁。如果是,就会出现锁竞争 / 锁冲突 / 互斥,就会引起阻塞等待。如果不是,就不会出现锁竞争,也就不会阻塞等待。和对象具体是啥类型,和它里面有啥属性,有啥方法,接下来是否要操作这个对象.....统统没有任何关系,不要自己脑补出其他的功能。
2.2.1 修饰代码块:
明确指定锁哪个对象。
• 锁任意对象:
我们前面所写的都是这种写法。
public class SynchronizedDemo {
private Object locker = new Object();
public void method() {
synchronized (locker) {
}
}
}
• 锁当前对象:
public class SynchronizedDemo {
public void method() {
synchronized (this) {
}
}
}
2.2.2 直接修饰普通方法:
当加锁的生命周期和方法的生命周期,是一样的,这个时候,就可以直接把 synchronized 写到方法上。(可以和 public 位置互换)这个写法就相当于是一进入方法就针对 this 加锁。
锁的 SynchronizedDemo 对象 。
public class SynchronizedDemo {
public synchronized void methond() {
}
}
上面的这两种写法等价。
2.2.3 修饰静态方法:
锁的 SynchronizedDemo 类的对象(一个类可以有多个对象,但是只有一个类对象)
public class SynchronizedDemo {
public synchronized static void method() {
}
}
如果我们要把 synchronized 放到方法里面,但是 static 里面不能使用 this。如果使用会出现如下错误。
解决方法:我们可以利用反射来拿到类对象。
例如:
public class SynchronizedDemo {
public static void method() {
synchronized (Counter.class){
}
}
}
到这相信友友们就能理解上面利用 synchronized 解决线程不安全问题。
我们重点要理解,synchronized 锁的是什么。两个线程竞争同一把锁,才会产生阻塞等待。两个线程分别尝试获取两把不同的锁,不会产生竞争。
2.3 Java 标准库中的线程安全类:
Java 标准库中很多都是线程不安全的。这些类可能会涉及到多线程修改共享数据,又没有任何加锁措施。
例如:ArrayList、LinkedList、HashMap、TreeMap、HashSet、TreeSet、StringBuilder等。
但是还有一些是线程安全的,使用了一些锁机制来控制。
Vector(不推荐使用) 、HashTable (不推荐使用) 、ConcurrentHashMap 、 StringBuffer等。
还有的虽然没有加锁,但是不涉及 "修改",仍然是线程安全的。例如:String。
结语:
其实写博客不仅仅是为了教大家,同时这也有利于我巩固知识点,和做一个学习的总结,由于作者水平有限,对文章有任何问题还请指出,非常感谢。如果大家有所收获的话还请不要吝啬你们的点赞收藏和关注,这可以激励我写出更加优秀的文章。