前言:本文的主要内容是讨论个人在多线程编程带来的安全问题的表现、原因以及对应的解决方法。
我们都知道多线程的并发执行能够提高程序的执行效率,它好比你拥有了“孙悟空”的七十二变,能够在同一时刻做多件事情,完成任务的时间自然就减少了。
假如有一根很长很长的绳子,我们需要把它剪成若干段定长的小绳子,一个人剪需要花很长的时间,但如果另一个人在绳子的另一端同时裁剪呢?剪绳子花费的时间瞬间就少了一半。同样道理,还可以有一个人在中间帮忙剪(不影响首尾两个人的情况下,甚至4个人…
在这种情况下,它们看似做的事情都是在剪同一根绳子,但本质上是因为绳子足够长,他们之间不会相互影响,可以看作是做不同的工作,因此能够大大提供工作效率。(下图同理)
然而,程序的并发执行并不完全如想象的那般美好,当某个工作只适合一个人独自完成时,另一个人的加入反而会降低效率,甚至导致工作“搞砸了”。例如:同样是“剪绳子”工作,此时的绳子剩下 5cm 长,需要剪的小绳子长度为 3cm,如果此时有两个人分别在两头剪(相当于两个不同线程),他们两个人都“十分勤奋”,只是埋头工作而不观察外界的情况,那结果显而易见,这根大绳子最终会变成 3段 “不合格”的小绳。
这种情况就是典型的多线程带来的安全问题,它可能导致程序发生不可预估的错误。
先说结论,导致多线程不安全有以下原因:
如果一个属性被多个线程共享,在某个时刻一个线程对该属性进行修改操作,若该修改操作未完成,此时另一个线程也对这个属性进行修改操作,这时可能会使属性的值超出预期结果,造成线程不安全的问题。
在多线程编程中,原子性是指不可分割的最小操作。若多个线程对同一个属性进行非原子性的修改操作时,就可能引发多线程不安全问题。
例如有以下代码:t1 和 t2 线程同时对一个静态成员变量 num 进行修改,修改规则为:每个线程都对 num变量 进行50000次自增操作。在主线程中等待 t1和t2 线程自增完成输出 num变量的值。
public class Demo {
public static int num;
public static void main(String[] args) {
Thread t1 = new Thread(() -> {
while (num < 10000) {
num++;
}
});
t1.start();
Thread t2 = new Thread(() -> {
while (num < 10000) {
num++;
}
});
t2.start();
try {
t1.join();
t2.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(num);
}
}
在我们的潜意识中程序输出的结果应该是 10w,但是当我们实际运行这段代码会发现一个奇怪的地方:程序每次输出的结果可能并不相同,并且总是小于 10w。(如下图)
我们可以看到,在上述的代码中,两个线程代码执行的主要逻辑其实就一条语句,即对 num 进行自增操作,按道理它就是一个“原子性”的操作,那么程序的输出结果为什么总小于 10w 呢?
原因是 num的自增语句在操作系统的实现中会被拆分为以下 3个指令:
由于线程是“抢占”式执行的,因此在两个线程的并发执行过程中,可能出现以下若干种指令的执行情况:
可以预见的情况:当且仅当 t1和t2 线程严格地轮流进行自增操作时,num才能进行真正有效的自增,出现的其他的若干种时,都会使 num 比预期的结果小 1,因此当多个线程对共享数据进行非原子的修改操作可能会出现多线程安全问题。
可见性是指当一个线程对一个共享的数据进行修改操作后,其他线程能够及时感知。
例如有以下代码:在Demo类中有一个静态成员变量 num,在main方法中有两个线程 t1和t2,t1线程对 num变量赋值,t2线程对 num变量的值进行判断,若 num变量的值不为0,则 t2线程结束循环。
public class Demo22 {
public static int num;
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
Scanner in = new Scanner(System.in);
System.out.println("请输入一个数为 num 变量赋值");
num = in.nextInt();
System.out.println("赋值成功,num = " + num);
});
Thread t2 = new Thread(() -> {
while (num == 0) {
}
System.out.println("t2线程执行结束 !");
});
t2.start();
t1.start();
}
}
运行以上代码可以发现 t2线程并没有退出循环,程序一直处于运行的状态。
造成上述结果的原因是:操作系统通过 load 指令将 num变量的值从内存加载到寄存器中,再通过比较指令将 num与 0 进行对比,由于当前 t2线程的执行逻辑较为简单,所以执行循环的速度非常快,如果每次进行循环都要从内存读取 num的值就会大大降低程序的执行效率。因此,编译器采用了一个“大胆的策略”,即只从内存中读取一个 num的值,后续的比较操作便直接从寄存器中取值。这样造成的内存属性已被修改,而其他线程感知不到的情况就是因为“内存可见性”引起的线程安全问题。
指令重排序是指在某些情况下,编译器在保证“代码总体逻辑不变”的情况下对CPU指令集的执行顺序进行了调整(优化),在单线程的情况下,这种调整不会对程序的结果造成影响,但在多线程的情况下可能会造成线程安全问题。
在Java中,锁可以理解成是能够将某种资源私有化的一种物品,其中锁又可分为乐观锁和悲观锁 或 公平锁和非公平锁。
在多线程的运行环境中,只要涉及到修改操作的地方,都有可能引发线程不安全的问题,而解决线程不安全问题常用的策略就是利用 synchronized 关键字 给修改操作“加锁”(不公平锁)。
那么怎么理解加锁呢?举几个简单的例子:
1.我们平时在上厕所时,都会习惯性地把门给锁上,在你还没出来之前,后面排队的人都无法进入厕所,这样就能保证厕所的正常有序使用。在这里锁门的操作很明显是一个“加锁”操作,而当我们从厕所出来,开门的过程相当于“释放锁”。
2.在一个热闹的商场中,到了饭点各个餐厅都几乎处于满座的状态,因此我们需要选择想去的餐厅并到前台取一张带有序号的小票,当叫到我们手上的“排队序号”时,我们就可以凭借手上的小票进入餐厅吃饭,并且后面来的顾客必须在我们进入之后才能依次进入餐厅就餐。在这个过程中,我们获取小票相当于为我们进入餐厅这个行为进行“加锁”,当我们凭借小票进入餐厅后,小票失效的过程就相当于“释放锁”。
在多线程环境中,对于共享数据的修改操作,利用 synchronized 加锁的方式主要有两种:
语法格式如下:
// 1. 为代码块加锁
synchronized (加锁的对象) {
// 相关的代码逻辑 & 修改操作
}
// 2. 为类的普通方法加锁
public synchronized void method() {
// 相关的代码逻辑 & 修改操作
}
何时加锁?何时释放锁?
当程序进入‘{’ 包裹的代码块 或 执行 synchronized修饰的方法时加锁。当程序出 ‘}’ 或 执行完方法时释放锁。
什么是有效加锁?
当且仅当多个线程对同一把锁产生锁竞争的时候才能成功进行加锁。
如何理解“同一把锁”?
同一把锁就同一个对象,产生锁竞争的关键在于是不是同一个对象,而不关注对象的类型(可以为Object类、Lock类或String类等 ),这个对象可以是某个类的实例 或 某个类的Class对象。
当多个线程竞争 synchronized关键字加的同一把锁会发生什么?
最先得到锁的线程拿到锁后继续执行代码,其余的线程进入“阻塞等待”的状态,直到第一个线程释放锁后,其余线程同时“公平”地争夺这把锁(不存在先来后到的情况)。
由原子性引起的多线程安全问题可以通过 synchronized加锁来解决,在上面的示例中,为两个线程的自增操作加锁,即让自增的过程由抢占式的并发执行变为轮流自增的串行执行就可保证程序的正确性。
修改代码示例如下:
public static void main(String[] args) {
Thread t1 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
synchronized (Thread.class) {
num++;
}
}
});
t1.start();
Thread t2 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
synchronized (Thread.class) {
num++;
}
}
});
t2.start();
try {
t1.join();
t2.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(num);
}
先说结论,synchronized的特性有:
互斥是产生锁竞争的关键因素,当多个线程都尝试获取一把锁时,拿到锁的线程继续执行代码,其他线程进入阻塞等待状态,直到锁被释放时才由操作系统唤醒。
synchronized刷新内存的工作过程如下:
因此使用 synchronized 可以保证内存可见性。
使用 synchronized 关键字加的锁是可重入锁,即当某个线程获得锁后,在代码的执行阶段又尝试获取同一把锁,能够成功获取,不会造成“死锁”的现象。
那么什么是死锁呢?
假设一个程序中有两个线程,并且每个线程分别获得了 1 把不同的锁,它们在释放锁前都尝试获取对方的锁,然而因为它们各自都未释放锁,因此两个线程都进入阻塞等待的状态,造成了死锁的现象。
代码示例如下:
public static void main(String[] args) {
Object lock1 = new Object();
Object lock2 = new Object();
Thread t1 = new Thread(() -> {
synchronized (lock1) {
System.out.println("t1线程成功获取 lock1");
synchronized (lock2) {
System.out.println("t1线程成功获取 lock2");
}
}
System.out.println("线程t1结束 !");
});
Thread t2 = new Thread(() -> {
synchronized (lock2) {
System.out.println("t2线程成功获取 lock2");
synchronized (lock1) {
System.out.println("t1线程成功获取 lock1");
}
}
System.out.println("线程t2结束 !");
});
t1.start();
t2.start();
}
程序的运行结果如下:(可以发现程序并没有正常退出,出现“卡死”的情况)
产生死锁的四个必要条件:
volatile关键字用来修饰一个成员变量,它能够保证内存可见性和禁止指令重排序。即用 volatile 修饰的成员变量在每次被线程访问时,都强制从共享内存中重新读取该成员变量的值;当成员变量发生变化时,会强制线程将变化值回写到共享内存。这样在任何时刻,两个不同的线程总是看到某个成员变量的同一个值。
注意:volatile可以保证内存可见性,不保证原子性。
在上面的示例中,要保证程序运行的正确性只需用 volatile修饰对应的成员变量皆可。(代码如下)
public volatile static int num;
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
Scanner in = new Scanner(System.in);
System.out.println("请输入一个数为 num 变量赋值");
num = in.nextInt();
System.out.println("赋值成功,num = " + num);
});
Thread t2 = new Thread(() -> {
while (num == 0) {
}
System.out.println("t2线程执行结束 !");
});
t2.start();
t1.start();
}
以上就是本篇文章的全部内容了,如果这篇文章对你有些许帮助,你的点赞、收藏和评论就是对我最大的支持。
另外,文章可能存在许多不足之处,也希望你可以给我一点小小的建议,我会努力检查并改进。