前言

=====

在单线程中不会呈现线程平安问题，而在多线程编程中，有可能会呈现同时拜访同一个 共享、可变资源  的状况，这种资源能够是： 一个变量、一个对象、一个文件等。特地留神两点：

简略的说，如果你的代码在单线程下执行和在多线程下执行永远都能取得一样的后果，那么你的代码就是线程平安的。那么，当进行多线程编程时，咱们又会面临哪些线程平安的要求呢？又是要如何去解决的呢？

1 线程平安个性

1.1 原子性

跟数据库事务的原子性概念差不多，即一个操作（有可能蕴含有多个子操作）要么全副执行（失效），要么全副都不执行（都不失效）。

对于原子性，一个十分经典的例子就是银行转账问题：

1.2 可见性

可见性是指，当多个线程并发访问共享变量时，一个线程对共享变量的批改，其它线程可能立刻看到。可见性问题是好多人疏忽或者了解谬误的一点。

CPU 从主内存中读数据的效率相对来说不高，当初支流的计算机中，都有几级缓存。每个线程读取共享变量时，都会将该变量加载进其对应 CPU 的高速缓存里，批改该变量后，CPU 会立刻更新该缓存，但并不一定会立刻将其写回主内存（实际上写回主内存的工夫不可预期）。此时其它线程（尤其是不在同一个 CPU 上执行的线程）拜访该变量时，从主内存中读到的就是旧的数据，而非第一个线程更新后的数据。

这一点是操作系统或者说是硬件层面的机制，所以很多利用开发人员常常会疏忽。

1.3 有序性

有序性指的是，程序执行的程序依照代码的先后顺序执行。以上面这段代码为例：

从代码程序上看，下面四条语句应该顺次执行，但实际上 JVM 真正在执行这段代码时，并不保障它们肯定齐全依照此程序执行。

处理器为了进步程序整体的执行效率，可能会对代码进行优化，其中的一项优化形式就是调整代码程序，依照更高效的程序执行代码。

讲到这里，有人要焦急了——什么，CPU 不依照我的代码程序执行代码，那怎么保障失去咱们想要的成果呢？实际上，大家大可释怀，CPU 尽管并不保障齐全依照代码程序执行，但它会保障程序最终的执行后果和代码程序执行时的后果统一。

2 线程平安问题

2.1 竞态条件与临界区

线程之间共享堆空间，在编程的时候就要分外留神防止竞态条件。危险在于多个线程同时拜访雷同的资源并进行读写操作。当其中一个线程须要依据某个变量的状态来相应执行某个操作的之前，该变量很可能曾经被其它线程批改。

2.2 死锁

死锁：指两个或两个以上的过程（或线程）在执行过程中，因抢夺资源而造成的一种相互期待的景象，若无外力作用，它们都将无奈推动上来。此时称零碎处于死锁状态或零碎产生了死锁，这些永远在相互期待的过程称为死锁过程。

对于死锁产生的条件：

2.3 活锁

活锁：是指线程 1 能够应用资源，但它很礼貌，让其余线程先应用资源，线程 2 也能够应用资源，但它很绅士，也让其余线程先应用资源。这样你让我，我让你，最初两个线程都无奈应用资源。

对于“死锁与活锁”的比喻：

2.4 饥饿

饥饿：是指如果线程 T1 占用了资源 R，线程 T2 又申请封闭 R，于是 T2 期待。T3 也申请资源 R，当 T1 开释了 R 上的封闭后，零碎首先批准了 T3 的申请，T2 依然期待。而后 T4 又申请封闭 R，当 T3 开释了 R 上的封闭之后，零碎又批准了 T4 的申请 ……，T2 可能永远期待。

也就是，如果一个线程因为 CPU 工夫全副被其余线程抢走而得不到 CPU 运行工夫，这种状态被称之为“饥饿”。而该线程被“饥饿致死”正是因为它得不到 CPU 运行工夫的机会。

对于“饥饿”的比喻：

在 Java 中，上面三个常见的起因会导致线程饥饿，如下：

1. 高优先级线程吞噬所有的低优先级线程的 CPU 工夫

**2. 线程被永恒梗塞在一个期待进入同步块的状态，因为其余线程总是能在它之前继续地对该同步块进行拜访
**

3. 线程在期待一个自身（在其上调用 wait()）也处于永恒期待实现的对象，因为其余线程总是被继续地取得唤醒 **

---

2.5 偏心

---

解决饥饿的计划被称之为“公平性”– 即所有线程均能偏心地取得运行机会。在 Java 中实现公平性计划，须要：

在 Java 中实现公平性，虽 Java 不可能实现 100% 的公平性，仍然能够通过同步构造在线程间实现公平性的进步。

首先来学习一段简略的同步态代码：

如果有多个线程调用 doSynchronized()办法，在第一个取得拜访的线程未实现前，其余线程将始终处于阻塞状态，而且在这种多线程被阻塞的场景下，接下来将是哪个线程取得拜访是没有保障的。

改为 应用锁形式代替同步块，为了进步期待线程的公平性，咱们应用锁形式来代替同步块：

留神到 doSynchronized()不再申明为 synchronized，而是用 lock.lock()和 lock.unlock()来代替。上面是用 Lock 类做的一个实现：

留神到上面对 Lock 的实现，如果存在多线程并发拜访 lock()，这些线程将阻塞在对 lock()办法的拜访上 。另外，如果锁曾经锁上（校对注：这里指的是 isLocked 等于 true 时）， 这些线程将阻塞在 while(isLocked)循环的 wait()调用外面 。要记住的是， 当线程正在期待进入 lock() 时，能够调用 wait()开释其锁实例对应的同步锁，使得其余多个线程能够进入 lock()办法，并调用 wait()办法。

这回看下 doSynchronized()，你会留神到在 lock()和 unlock()之间的正文：在这两个调用之间的代码将运行很长一段时间。进一步构想，这段代码将长时间运行，和进入 lock()并调用 wait()来比拟的话。这意味着大部分工夫用在期待进入锁和进入临界区的过程是用在 wait()的期待中，而不是被阻塞在试图进入 lock()办法中。

在早些时候提到过，同步块不会对期待进入的多个线程谁能取得拜访做任何保障，同样当调用 notify()时，wait()也不会做保障肯定能唤醒线程 。因而这个版本的 Lock 类和 doSynchronized() 那个版本就保障公平性而言，没有任何区别。

但咱们可能扭转这种状况，如下：

上面将下面 Lock 类转变为偏心锁 FairLock。你会留神到新的实现和之前的 Lock 类中的同步和 wait()notify()稍有不同。重点是，每一个调用 lock()的线程都会进入一个队列，当解锁时，只有队列里的第一个线程被容许锁住 FairLock 实例，所有其它的线程都将处于期待状态，直到他们处于队列头部。如下：

首先留神到 lock()办法不在申明为 synchronized，取而代之的是对必须同步的代码，在 synchronized 中进行嵌套。

还需注意到，QueueObject 理论是一个 semaphore。doWait()和 doNotify()办法在 QueueObject 中保留着信号。这样做以防止一个线程在调用 queueObject.doWait()之前被另一个线程调用 unlock()并随之调用 queueObject.doNotify()的线程重入，从而导致信号失落 。queueObject.doWait() 调用搁置在 synchronized(this)块之外，以防止被 monitor 嵌套锁死，所以另外的线程能够解锁，只有当没有线程在 lock 办法的 synchronized(this)块中执行即可。

最初，留神到 queueObject.doWait()在 try – catch 块中是怎么调用的。在 InterruptedException 抛出的状况下，线程得以来到 lock()，并需让它从队列中移除。

3 如何确保线程平安个性

3.1 如何确保原子性

3.1.1 锁和同步

罕用的保障 Java 操作原子性的工具是 锁和同步办法（或者同步代码块）。应用锁，能够保障同一时间只有一个线程能拿到锁，也就保障了同一时间只有一个线程能执行申请锁和开释锁之间的代码。

与锁相似的是同步办法或者同步代码块。应用非动态同步办法时，锁住的是以后实例；应用动态同步办法时，锁住的是该类的 Class 对象；应用动态代码块时，锁住的是 synchronized 关键字前面括号内的对象。上面是同步代码块示例：

无论应用锁还是 synchronized，实质都是一样，通过锁或同步来实现资源的排它性，从而理论指标代码段同一时间只会被一个线程执行 ，进而保障了指标代码段的原子性。 这是一种以就义性能为代价的办法。

3.1.2 CAS（compare and swap）

根底类型变量自增（i++）是一种常被老手误以为是原子操作而理论不是的操作 。Java 中提供了对应的原子操作类来实现该操作，并保障原子性， 其本质是利用了 CPU 级别的 CAS 指令。因为是 CPU 级别的指令，其开销比须要操作系统参加的锁的开销小。AtomicInteger 应用办法如下：

3.2 如何确保可见性

Java 提供了 volatile 关键字来保障可见性。当应用 volatile 润饰某个变量时，它会保障对该变量的批改会立刻被更新到内存中，并且将其它线程缓存中对该变量的缓存设置成有效，因而其它线程须要读取该值时必须从主内存中读取，从而失去最新的值。

volatile 实用场景：volatile 实用于不须要保障原子性，但却须要保障可见性的场景。一种典型的应用场景是用它润饰用于进行线程的状态标记。如下所示：

在这种实现形式下，即便其它线程通过调用 stop()办法将 isRunning 设置为 false，循环也不肯定会立刻完结。能够通过 volatile 关键字，保障 while 循环及时失去 isRunning 最新的状态从而及时进行循环，完结线程。

3.3 如何确保有序性

上文讲过编译器和处理器对指令进行从新排序时，会保障从新排序后的执行后果和代码程序执行的后果统一，所以从新排序过程并不会影响单线程程序的执行，却可能影响多线程程序并发执行的正确性。

除了从利用层面保障指标代码段执行的程序性外，JVM 还通过被称为 happens-before 准则隐式地保障程序性。两个操作的执行程序只有能够通过 happens-before 推导进去，则 JVM 会保障其程序性，反之 JVM 对其程序性不作任何保障，可对其进行任意必要的从新排序以获取高效率。

happens-before 准则（后行产生准则），如下：

4 对于线程平安的几个为什么

1. 平时我的项目中应用锁和 synchronized 比拟多，而很少应用 volatile，难道就没有保障可见性？

**2. 锁和 synchronized 为何能保障可见性？
**

3. 既然锁和 synchronized 即可保障原子性也可保障可见性，为何还须要 volatile？**

---

4. 既然锁和 synchronized 能够保障原子性，为什么还须要 AtomicInteger 这种的类来保障原子操作？

5. 还有没有别的方法保障线程平安？

6.synchronized 即可润饰非动态形式，也可润饰静态方法，还可润饰代码块，有何区别？

**