提到线程安全，可能大家的第一反应是要确保接口对共享变量的操作要具体原子性。实际上，在多线程编程中我们需要同时关注可见性、顺序性和原子性问题。本篇文章将从这三个问题出发，结合实例详解 volatile 如何保证可见性及一定程序上保证顺序性，同时例讲 synchronized 如何同时保证可见性和原子性，最后对比 volatile 和 synchronized 的适用场景。
多线程编程中的三个核心概念
原子性
这一点，跟数据库事务的原子性概念差不多，即一个操作 （有可能包含有多个子操作） 要么全部执行 （生效），要么全部都不执行 （都不生效） 。
关于原子性，一个非常经典的例子就是银行转账问题：比如 A 和 B 同时向 C 转账 10 万元。如果转账操作不具有原子性，A 在向 C 转账时，读取了 C 的余额为 20 万，然后加上转账的 10 万，计算出此时应该有 30 万，但还未来及将 30 万写回 C 的账户，此时 B 的转账请求过来了，B 发现 C 的余额为 20 万，然后将其加 10 万并写回。然后 A 的转账操作继续——将 30 万写回 C 的余额。这种情况下 C 的最终余额为 30 万，而非预期的 40 万。
可见性
可见性是指，当多个线程并发访问共享变量时，一个线程对共享变量的修改，其它线程能够立即看到。可见性问题是好多人忽略或者理解错误的一点。
CPU 从主内存中读数据的效率相对来说不高，现在主流的计算机中，都有几级缓存。每个线程读取共享变量时，都会将该变量加载进其对应 CPU 的高速缓存里，修改该变量后，CPU 会立即更新该缓存，但并不一定会立即将其写回主内存 （实际上写回主内存的时间不可预期） 。此时其它线程 （尤其是不在同一个 CPU 上执行的线程） 访问该变量时，从主内存中读到的就是旧的数据，而非第一个线程更新后的数据。
这一点是操作系统或者说是硬件层面的机制，所以很多应用开发人员经常会忽略。
顺序性
顺序性指的是，程序执行的顺序按照代码的先后顺序执行。
以下面这段代码为例
|
1
2
3
4
|
boolean started = false; // 语句 1
long counter = 0L; // 语句 2
counter = 1; // 语句 3
started = true; // 语句 4
|
从代码顺序上看，上面四条语句应该依次执行，但实际上 JVM 真正在执行这段代码时，并不保证它们一定完全按照此顺序执行。
处理器为了提高程序整体的执行效率，可能会对代码进行优化，其中的一项优化方式就是调整代码顺序，按照更高效的顺序执行代码。
讲到这里，有人要着急了——什么，CPU 不按照我的代码顺序执行代码，那怎么保证得到我们想要的效果呢？实际上，大家大可放心，CPU 虽然并不保证完全按照代码顺序执行，但它会保证程序最终的执行结果和代码顺序执行时的结果一致。
Java 如何解决多线程并发问题
Java 如何保证原子性
锁和同步
常用的保证 Java 操作原子性的工具是锁和同步方法 （或者同步代码块） 。使用锁，可以保证同一时间只有一个线程能拿到锁，也就保证了同一时间只有一个线程能执行申请锁和释放锁之间的代码。
|
1
2
3
4
5
6
7
8
9
|
public void testLock () {
lock.lock();
try{
int j = i;
i = j + 1;
} finally {
lock.unlock();
}
}
|
与锁类似的是同步方法或者同步代码块。使用非静态同步方法时，锁住的是当前实例；使用静态同步方法时，锁住的是该类的 Class 对象；使用静态代码块时，锁住的是 synchronized 关键字后面括号内的对象。下面是同步代码块示例
|
1
2
3
4
5
6
|
public void testLock () {
synchronized (anyObject){
int j = i;
i = j + 1;
}
}
|
无论使用锁还是 synchronized，本质都是一样，通过锁来实现资源的排它性，从而实际目标代码段同一时间只会被一个线程执行，进而保证了目标代码段的原子性。这是一种以牺牲性能为代价的方法。
CAS（compare and swap）
基础类型变量自增 （i++） 是一种常被新手误以为是原子操作而实际不是的操作。 Java 中提供了对应的原子操作类来实现该操作，并保证原子性，其本质是利用了 CPU 级别的 CAS 指令。由于是 CPU 级别的指令，其开销比需要操作系统参与的锁的开销小。 AtomicInteger 使用方法如下。
|
1
2
3
4
5
6
7
8
|
AtomicInteger atomicInteger = new AtomicInteger();
for(int b = 0; b < numThreads; b++) {
new Thread(() -> {
for(int a = 0; a < iteration; a++) {
atomicInteger.incrementAndGet();
}
}).start();
}
|
Java 如何保证可见性
Java 提供了 volatile 关键字来保证可见性。当使用 volatile 修饰某个变量时，它会保证对该变量的修改会立即被更新到内存中，并且将其它缓存中对该变量的缓存设置成无效，因此其它线程需要读取该值时必须从主内存中读取，从而得到最新的值。
Java 如何保证顺序性
上文讲过编译器和处理器对指令进行重新排序时，会保证重新排序后的执行结果和代码顺序执行的结果一致，所以重新排序过程并不会影响单线程程序的执行，却可能影响多线程程序并发执行的正确性。
Java 中可通过 volatile 在一定程序上保证顺序性，另外还可以通过 synchronized 和锁来保证顺序性。
synchronized 和锁保证顺序性的原理和保证原子性一样，都是通过保证同一时间只会有一个线程执行目标代码段来实现的。
除了从应用层面保证目标代码段执行的顺序性外，JVM 还通过被称为 happens-before 原则隐式地保证顺序性。两个操作的执行顺序只要可以通过 happens-before 推导出来，则 JVM 会保证其顺序性，反之 JVM 对其顺序性不作任何保证，可对其进行任意必要的重新排序以获取高效率。
happens-before 原则 （先行发生原则）
- 传递规则：如果操作 1 在操作 2 前面，而操作 2 在操作 3 前面，则操作 1 肯定会在操作 3 前发生。该规则说明了 happens-before 原则具有传递性
- 锁定规则：一个 unlock 操作肯定会在后面对同一个锁的 lock 操作前发生。这个很好理解，锁只有被释放了才会被再次获取
- volatile 变量规则：对一个被 volatile 修饰的写操作先发生于后面对该变量的读操作
- 程序次序规则：一个线程内，按照代码顺序执行
- 线程启动规则：Thread 对象的 start() 方法先发生于此线程的其它动作
- 线程终结原则：线程的终止检测后发生于线程中其它的所有操作
- 线程中断规则： 对线程 interrupt() 方法的调用先发生于对该中断异常的获取
- 对象终结规则：一个对象构造先于它的 finalize 发生
volatile 适用场景
volatile 适用于不需要保证原子性，但却需要保证可见性的场景。一种典型的使用场景是用它修饰用于停止线程的状态标记。如下所示
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
boolean isRunning = false;
public void start () {
new Thread( () -> {
while(isRunning) {
someOperation();
}
}).start();
}
public void stop () {
isRunning = false;
}
|
在这种实现方式下，即使其它线程通过调用 stop() 方法将 isRunning 设置为 false，循环也不一定会立即结束。可以通过 volatile 关键字，保证 while 循环及时得到 isRunning 最新的状态从而及时停止循环，结束线程。
线程安全十万个为什么
问：平时项目中使用锁和 synchronized 比较多，而很少使用 volatile，难道就没有保证可见性？
答：锁和 synchronized 即可以保证原子性，也可以保证可见性。都是通过保证同一时间只有一个线程执行目标代码段来实现的。
问：锁和 synchronized 为何能保证可见性？
答：根据 JDK 7 的 Java doc 中对 concurrent 包的说明，一个线程的写结果保证对另外线程的读操作可见，只要该写操作可以由 happen-before 原则推断出在读操作之前发生。
The results of a write by one thread are guaranteed to be visible to a read by another thread only if the write operation happens-before the read operation. The synchronized and volatile constructs, as well as the Thread.start() and Thread.join() methods, can form happens-before relationships.
问：既然锁和 synchronized 即可保证原子性也可保证可见性，为何还需要 volatile？
答：synchronized 和锁需要通过操作系统来仲裁谁获得锁，开销比较高，而 volatile 开销小很多。因此在只需要保证可见性的条件下，使用 volatile 的性能要比使用锁和 synchronized 高得多。
问：既然锁和 synchronized 可以保证原子性，为什么还需要 AtomicInteger 这种的类来保证原子操作？
答：锁和 synchronized 需要通过操作系统来仲裁谁获得锁，开销比较高，而 AtomicInteger 是通过 CPU 级的 CAS 操作来保证原子性，开销比较小。所以使用 AtomicInteger 的目的还是为了提高性能。
问：还有没有别的办法保证线程安全
答：有。尽可能避免引起非线程安全的条件——共享变量。如果能从设计上避免共享变量的使用，即可避免非线程安全的发生，也就无须通过锁或者 synchronized 以及 volatile 解决原子性、可见性和顺序性的问题。
问：synchronized 即可修饰非静态方式，也可修饰静态方法，还可修饰代码块，有何区别
答：synchronized 修饰非静态同步方法时，锁住的是当前实例；synchronized 修饰静态同步方法时，锁住的是该类的 Class 对象；synchronized 修饰静态代码块时，锁住的是 synchronized 关键字后面括号内的对象。