因为 i 是静态变量,没有经过任何线程安全措施的保护,多个线程会并发修改 i 的值,所以我们认为 i 不是线程安全的,导致这种结果的出现是由于 aThread 和 bThread 中读取的 i 值彼此不可见,所以这是由于 可见性
导致的线程安全问题。
####原子性问题
看起来很普通的一段程序却因为两个线程 aThread
和 bThread
交替执行产生了不同的结果。但是根源不是因为创建了两个线程导致的,多线程只是产生线程安全性的必要条件,最终的根源出现在 i++
这个操作上。
这个操作怎么了?这不就是一个给 i 递增的操作吗?也就是 i++ => i = i + 1,这怎么就会产生问题了?
因为 i++
不是一个 原子性
操作,仔细想一下,i++ 其实有三个步骤,读取 i 的值,执行 i + 1 操作,然后把 i + 1 得出的值重新赋给 i(将结果写入内存)。
当两个线程开始运行后,每个
《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》
【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享
线程都会把 i 的值读入到 CPU 缓存中,然后执行 + 1 操作,再把 + 1 之后的值写入内存。因为线程间都有各自的虚拟机栈和程序计数器,他们彼此之间没有数据交换,所以当 aThread 执行 + 1 操作后,会把数据写入到内存,同时 bThread 执行 + 1 操作后,也会把数据写入到内存,因为 CPU 时间片的执行周期是不确定的,所以会出现当 aThread 还没有把数据写入内存时,bThread 就会读取内存中的数据,然后执行 + 1操作,再写回内存,从而覆盖 i 的值,导致 aThread 所做的努力白费。
为什么上面的线程切换会出现问题呢?
我们先来考虑一下正常情况下(即不会出现线程安全性问题的情况下)两条线程的执行顺序
可以看到,当 aThread 在执行完整个 i++ 的操作后,操作系统对线程进行切换,由 aThread -> bThread,这是最理想的操作,一旦操作系统在任意 读取/增加/写入
阶段产生线程切换,都会产生线程安全问题。例如如下图所示
最开始的时候,内存中 i = 0,aThread 读取内存中的值并把它读取到自己的寄存器中,执行 +1 操作,此时发生线程切换,bThread 开始执行,读取内存中的值并把它读取到自己的寄存器中,此时发生线程切换,线程切换至 aThread 开始运行,aThread 把自己寄存器的值写回到内存中,此时又发生线程切换,由 aThread -> bThread,线程 bThread 把自己寄存器的值 +1 然后写回内存,写完后内存中的值不是 2 ,而是 1, 内存中的 i 值被覆盖了。
我们上面提到 原子性
这个概念,那么什么是原子性呢?
并发编程的原子性操作是完全独立于任何其他进程运行的操作,原子操作多用于现代操作系统和并行处理系统中。
原子操作通常在内核中使用,因为内核是操作系统的主要组件。但是,大多数计算机硬件,编译器和库也提供原子性操作。
在加载和存储中,计算机硬件对存储器字进行读取和写入。为了对值进行匹配、增加或者减小操作,一般通过原子操作进行。在原子操作期间,处理器可以在同一数据传输期间完成读取和写入。 这样,其他输入/输出机制或处理器无法执行存储器读取或写入任务,直到原子操作完成为止。
简单来讲,就是原子操作要么全部执行,要么全部不执行。数据库事务的原子性也是基于这个概念演进的。
有序性问题
在并发编程中还有带来让人非常头疼的 有序性
问题,有序性顾名思义就是顺序性,在计算机中指的就是指令的先后执行顺序。一个非常显而易见的例子就是 JVM 中的类加载
这是一个 JVM 加载类的过程图,也称为类的生命周期,类从加载到 JVM 到卸载一共会经历五个阶段 加载、连接、初始化、使用、卸载。这五个过程的执行顺序是一定的,但是在连接阶段,也会分为三个过程,即 验证、准备、解析 阶段,这三个阶段的执行顺序不是确定的,通常交叉进行,在一个阶段的执行过程中会激活另一个阶段。
有序性问题一般是编译器带来的,编译器有的时候确实是 好心办坏事,它为了优化系统性能,往往更换指令的执行顺序。
活跃性问题
多线程还会带来活跃性
问题,如何定义活跃性问题呢?活跃性问题关注的是 某件事情是否会发生。
如果一组线程中的每个线程都在等待一个事件,而这个事件只能由该组中的另一个线程触发,这种情况会导致死锁。
简单一点来表述一下,就是每个线程都在等待其他线程释放资源,而其他资源也在等待每个线程释放资源,这样没有线程抢先释放自己的资源,这种情况会产生死锁,所有线程都会无限的等待下去。
换句话说,死锁线程集合中的每个线程都在等待另一个死锁线程占有的资源。但是由于所有线程都不能运行,它们之中任何一个资源都无法释放资源,所以没有一个线程可以被唤醒。
如果说死锁很痴情
的话,那么活锁
用一则成语来表示就是 弄巧成拙
。
某些情况下,当线程意识到它不能获取所需要的下一个锁时,就会尝试礼貌的释放已经获得的锁,然后等待非常短的时间再次尝试获取。可以想像一下这个场景:当两个人在狭路相逢的时候,都想给对方让路,相同的步调会导致双方都无法前进。
现在假想有一对并行的线程用到了两个资源。它们分别尝试获取另一个锁失败后,两个线程都会释放自己持有的锁,再次进行尝试,这个过程会一直进行重复。很明显,这个过程中没有线程阻塞,但是线程仍然不会向下执行,这种状况我们称之为 活锁(livelock)
。
如果我们期望的事情一直不会发生,就会产生活跃性问题,比如单线程中的无限循环
while(true){…}
for(;😉{}
在多线程中,比如 aThread 和 bThread 都需要某种资源,aThread 一直占用资源不释放,bThread 一直得不到执行,就会造成活跃性问题,bThread 线程会产生饥饿
,我们后面会说。
性能问题
与活跃性问题密切相关的是 性能
问题,如果说活跃性问题关注的是最终的结果,那么性能问题关注的就是造成结果的过程,性能问题有很多方面:比如服务时间过长,吞吐率过低,资源消耗过高,在多线程中这样的问题同样存在。
在多线程中,有一个非常重要的性能因素那就是我们上面提到的 线程切换
,也称为 上下文切换(Context Switch)
,这种操作开销很大。
在计算机世界中,老外都喜欢用 context 上下文这个词,这个词涵盖的内容很多,包括上下文切换的资源,寄存器的状态、程序计数器等。context switch 一般指的就是这些上下文切换的资源、寄存器状态、程序计数器的变化等。
在上下文切换中,会保存和恢复上下文,丢失局部性,把大量的时间消耗在线程切换上而不是线程运行上。
为什么线程切换会开销如此之大呢?线程间的切换会涉及到以下几个步骤
将 CPU 从一个线程切换到另一线程涉及挂起当前线程,保存其状态,例如寄存器,然后恢复到要切换的线程的状态,加载新的程序计数器,此时线程切换实际上就已经完成了;此时,CPU 不在执行线程切换代码,进而执行新的和线程关联的代码。
引起线程切换的几种方式
线程间的切换一般是操作系统层面需要考虑的问题,那么引起线程上下文切换有哪几种方式呢?或者说线程切换有哪几种诱因呢?主要有下面几种引起上下文切换的方式
- 当前正在执行的任务完成,系统的 CPU 正常调度下一个需要运行的线程
- 当前正在执行的任务遇到 I/O 等阻塞操作,线程调度器挂起此任务,继续调度下一个任务。
- 多个任务并发抢占锁资源,当前任务没有获得锁资源,被线程调度器挂起,继续调度下一个任务。
- 用户的代码挂起当前任务,比如线程执行 sleep 方法,让出CPU。
- 使用硬件中断的方式引起上下文切换
线程安全性
在 Java 中,要实现线程安全性,必须要正确的使用线程和锁,但是这些只是满足线程安全的一种方式,要编写正确无误的线程安全的代码,其核心就是对状态访问操作进行管理。最重要的就是最 共享(Shared)
的 和 可变(Mutable)
的状态。只有共享和可变的变量才会出现问题,私有变量不会出现问题,参考程序计数器
。
对象的状态可以理解为存储在实例变量或者静态变量中的数据,共享意味着某个变量可以被多个线程同时访问、可变意味着变量在生命周期内会发生变化。一个变量是否是线程安全的,取决于它是否被多个线程访问。要使变量能够被安全访问,必须通过同步机制来对变量进行修饰。
如果不采用同步机制的话,那么就要避免多线程对共享变量的访问,主要有下面两种方式
- 不要在多线程之间共享变量
- 将共享变量置为不可变的
我们说了这么多次线程安全性,那么什么是线程安全性呢?
什么是线程安全性
根据上面的探讨,我们可以得出一个简单的定义:当多个线程访问某个类时,这个类始终都能表现出正确的行为,那么就称这个类是线程安全的。
单线程就是一个线程数量为 1 的多线程,单线程一定是线程安全的。读取某个变量的值不会产生安全性问题,因为不管读取多少次,这个变量的值都不会被修改。
原子性
我们上面提到了原子性的概念,你可以把原子性操作想象成为一个不可分割
的整体,它的结果只有两种,要么全部执行,要么全部回滚。你可以把原子性认为是 婚姻关系
的一种,男人和女人只会产生两种结果,好好的
和 说散就散
,一般男人的一生都可以把他看成是原子性的一种,当然我们不排除时间管理(线程切换)
的个例,我们知道线程切换必然会伴随着安全性问题,男人要出去浪也会造成两种结果,这两种结果分别对应安全性的两个结果:线程安全(好好的)和线程不安全(说散就散)。
竞态条件
有了上面的线程切换的功底,那么竞态条件也就好定义了,它指的就是两个或多个线程同时对一共享数据进行修改,从而影响程序运行的正确性时,这种就被称为竞态条件(race condition) ,线程切换是导致竞态条件出现的诱导因素,我们通过一个示例来说明,来看一段代码
public class RaceCondition {
private Signleton single = null;
public Signleton newSingleton(){
if(single == null){
single = new Signleton();
}
return single;
}
}
在上面的代码中,涉及到一个竞态条件,那就是判断 single
的时候,如果 single 判断为空,此时发生了线程切换,另外一个线程执行,判断 single 的时候,也是空,执行 new 操作,然后线程切换回之前的线程,再执行 new 操作,那么内存中就会有两个 Singleton 对象。
加锁机制
在 Java 中,有很多种方式来对共享和可变的资源进行加锁和保护。Java 提供一种内置的机制对资源进行保护:synchronized
关键字,它有三种保护机制
- 对方法进行加锁,确保多个线程中只有一个线程执行方法;
- 对某个对象实例(在我们上面的探讨中,变量可以使用对象来替换)进行加锁,确保多个线程中只有一个线程对对象实例进行访问;
- 对类对象进行加锁,确保多个线程只有一个线程能够访问类中的资源。
synchronized 关键字对资源进行保护的代码块俗称 同步代码块(Synchronized Block)
,例如
synchronized(lock){
// 线程安全的代码
}
每个 Java 对象都可以用做一个实现同步的锁,这些锁被称为 内置锁(Instrinsic Lock)
或者 监视器锁(Monitor Lock)
。线程在进入同步代码之前会自动获得锁,并且在退出同步代码时自动释放锁,而无论是通过正常执行路径退出还是通过异常路径退出,获得内置锁的唯一途径就是进入这个由锁保护的同步代码块或方法。
synchronized 的另一种隐含的语义就是 互斥
,互斥意味着独占
,最多只有一个线程持有锁,当线程 A 尝试获得一个由线程 B 持有的锁时,线程 A 必须等待或者阻塞,直到线程 B 释放这个锁,如果线程 B 不释放锁的话,那么线程 A 将会一直等待下去。
线程 A 获得线程 B 持有的锁时,线程 A 必须等待或者阻塞,但是获取锁的线程 B 可以重入,重入的意思可以用一段代码表示
public class Retreent {
public synchronized void doSomething(){
doSomethingElse();
System.out.println(“doSomething…”);
}
public synchronized void doSomethingElse(){
System.out.println(“doSomethingElse…”);
}
获取 doSomething() 方法锁的线程可以执行 doSomethingElse() 方法,执行完毕后可以重新执行 doSomething() 方法中的内容。锁重入也支持子类和父类之间的重入,具体的我们后面会进行介绍。
volatile
是一种轻量级的 synchronized
,也就是一种轻量级的加锁方式,volatile 通过保证共享变量的可见性来从侧面对对象进行加锁。可见性的意思就是当一个线程修改一个共享变量时,另外一个线程能够 看见
这个修改的值。volatile 的执行成本要比 synchronized
低很多,因为 volatile 不会引起线程的上下文切换。
关于 volatile 的具体实现,我们后面会说。
我们还可以使用原子类
来保证线程安全,原子类其实就是 rt.jar
下面以 atomic
开头的类
这个修改的值。volatile 的执行成本要比 synchronized
低很多,因为 volatile 不会引起线程的上下文切换。
[外链图片转存中…(img-MFyo3MUW-1640593779664)]
关于 volatile 的具体实现,我们后面会说。
我们还可以使用原子类
来保证线程安全,原子类其实就是 rt.jar
下面以 atomic
开头的类