class ThreadDemo {
static class Counter {
public int count = 0;
void increase() {
count++;
}
}
public static void main(String[] args) throws InterruptedException {
final Counter counter = new Counter();
Thread t1 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
counter.increase();
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
counter.increase();
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(counter.count);
}
}
多次执行的结果:
两个线程各 加了 50000 次, 但最终结果都不是我们预期的 100000, 并且相差甚远。
操作系统调度线程是随机的(抢占式),正因为这样的随机性,就可能导致程序的执行出现一些 bug。
如果多线程环境下代码运行的结果是符合我们预期的,即在单线程环境应该的结果,则说这个程序是线程安全的,否则就是线程不安全的。
线程是抢占式执行,线程间的调度就充满随机性。
这是线程不安全的万恶之源,但是我们无可奈何,无法解决。
多个线程针对同一变量进行了修改操作,假如说多个线程针对不同变量进行修改则没事,多个线程针对相同变量进行读取也没事。
上面的线程不安全的代码中, 涉及到多个线程针对 counter.count 变量进行修改.
此时这个 counter.count 是一个多个线程都能访问到的 “共享数据”
counter.count 这个变量就是在堆上. 因此可以被多个线程共享访问.
针对变量的操作不是原子的,通过加锁操作,可以把多个操作打包成一个原子操作。
一条 java 语句不一定是原子的,也不一定只是一条指令
比如上面的 count++,其实是由三步操作组成的:
(1)从内存把数据 count 读到 CPU
(2)进行数据更新 count = count + 1
(3)把更新后的数据 count 写回到 内存
所以说导致上面那段代码线程不安全的原因就是:
只要 t2 是在 t1 线程 save 之前读的, t2 的自增就会覆盖 t1 的自增, 那么两次加 1 的效果都相当于只加了 1 次.
所以上面的代码的执行结果 在 5w ~ 10w,并且大多数是靠近 5w 的。
(小于 5w 的是非常少见的, 这种情况就是 t2 线程覆盖了 t1 线程的多次 自增操作, 也就是说 t2 线程的 load 与 save 之间跨度很大的情况.)
解决:加锁 ! 打包成原子操作。
最常见的加锁方式就是 使用 synchronized
class ThreadDemo {
static class Counter {
public int count = 0;
synchronized void increase() {
count++;
}
}
public static void main(String[] args) throws InterruptedException {
final Counter counter = new Counter();
Thread t1 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
counter.increase();
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
counter.increase();
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(counter.count);
}
}
在自增之前加锁,自增之后再解锁。
当一个线程加锁成功时,其他线程再尝试加锁就会阻塞,直到占用锁的线程将锁释放。
那这样不就是串行执行了嘛?那多线程又有什么用 ?
实际开发中,一个线程要执行的任务很多,可能只有其中的很少一部分会涉及到线程安全问题,才需要加锁,而其他地方都能并发执行。
注意:
加锁,是要明确指出对哪个对象进行加锁的,如果两个线程对同一个锁对象进行加锁才会产生锁竞争(阻塞等待),如果对不同的对象进行加锁,那么不会产生锁竞争(阻塞等待)。
上面代码中 synchronized 加在方法上,那么就是对 Counter 对象加锁,对应到代码中就是两个线程就是对 counter 这个实例对象加锁。
可见性指, 一个线程对共享变量值的修改,能够及时地被其他线程看到.
Java 内存模型 (JMM): Java虚拟机规范中定义了Java内存模型.
目的是屏蔽掉各种硬件和操作系统的内存访问差异,以实现让Java程序在各种平台下都能达到一致的并发效果.
实际并没有这么多 “内存”. 这只是 Java 规范中的一个术语, 是属于 “抽象” 的叫法.
所谓的 “主内存” 才是真正硬件角度的 “内存”. 而所谓的 “工作内存”, 则是指 CPU 的寄存器和高速缓存.
由于每个线程有自己的工作内存, 这些工作内存中的内容相当于同一个共享变量的 “副本”. 此时修改线程 1 的工作内存中的值, 线程 2 的工作内存不一定会及时变化.
举一个栗子:
针对同一个变量:
一个线程进行循环读取操作,另一个线程在某个时机进行了修改操作。
比如某个代码中要连续 10 次读取某个变量的值, 如果 10 次都从内存读, 速度是很慢的比寄存器慢 3-4 个数量级.
但是如果只是第一次从内存读, 读到的结果缓存到 CPU 的某个寄存器中, 那么后 9 次读数据就不必直接访问
内存了. 效率就大大提高了. (编译器优化的结果)
解决:
使用 synchronized
synchronized 不仅能保证原子性,同时能保证内存可见性,
被 synchronized 修饰的代码,编译器不会轻易优化。
使用 volatile 关键字
volatile 和原子性无关,但是能保证内存可见性,禁止编译器优化,每次都要从内存中读取变量。
什么是指令重排序?
举个栗子:
一段代码是这样的:
1. 去前台取下 U 盘
2. 去教室写 10 分钟作业
3. 去前台取下快递
如果是在单线程情况下,JVM、CPU指令集会对其进行优化,比如,按 1->3->2的方式执行,也是没问题,可以少跑一次前台,提高效率。这种叫做指令重排序。
编译器对于指令重排序的前提是 “保持逻辑不发生变化”.
这一点在单线程环境下比较容易判断, 但是在多线程环境下就没那么容易了,
多线程的代码执行复杂程度更高, 编译器很难在编译阶段对代码的执行效果进行预测,
因此激进的重排序很容易导致优化后的逻辑和之前不等价.
解决:
使用 volatile 关键字
volatile 除了能保证内存可见性之外还能防止指令重排序。
好啦! 以上就是对 线程安全 问题的讲解,希望能帮到你 !
评论区欢迎指正 !