JUC—线程安全概述

什么是线程安全

Brian Goetz在《Java 并发编程实战》说到：当多个线程同时访同一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果；那就称这个对象是线程安全的

线程安全的分类

按照线程安全的安全程度由强至弱来排序，我们可以将 Java语言中各种操作共享的数据分为以下五类:不可变、绝对线程安全、相对线程安全、线程兼容和线程对立

1、不可变

不变 ( Immutable)的对象一定是线程安全的，无论是对象的方法实现还是方法的调用者，不需要再进行任何线程安全保障措施；就是说只要一个不可变的对象被正确地构建出来(即没有发生 this 引用逃逸)，那其外部的可见状态永远都不会改变，永远都不会看到它在多个线程之中处于不一致的状态。“不可变”带来的安全性是最直接、最纯粹的。

Java 语言中，如果多线程共享的数据是一个基本数据类型，那么只要在定义时使用final关键字修饰它就可以保证它是不可变的。

如果共享数据是一个对象，由于 Java 语言目前暂时还没有提供值类型的支持，那就需要对象自行保证其行为不会对其状态产生任何影响才行。

保证对象行为不影响自己状态的途径有很多种，最简单的一种就是把对象里面带有状态的变量都声明为 final，这样在构造函数结束之后，它就是不可变的。

在 Java类库 API中符合不可变要求的类型，除了上面提到的 String之外，常用的还有枚举类型及java.lang.Number 的部分子类，如Long和 Double等数值包装类型，BigInteger 和 BigDecimal 等大数据类型。

2、绝对线程安全

在 Java API 中标注自己是线程安全的类，大多数都不是绝对的线程安全。尽管这里使用到的 Vector的 get()、remove()和 size()方法都是同步的，但是在多线程的环境中，如果不在方法调用端做额外的同步措施，使用这段代码仍然是不安全的。因为如果另一个线程恰好在错误的时间里删除了一个元素，导致序号i已经不再可用再用i访问数组就会抛出一个 ArraylndexOutoBoundsException 异常。

假如 Vector一定要做到绝对的线程安全，那就必须在它内部维护一组一致性的快照访问才行，每次对其中元素进行改动都要产生新的快照，这样要付出的时间和空间成本都是非常大的。

3、相对线程安全

它需要保证对这个对象单次的操作是线程安全的，我们在调用的时候不需要进行额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。

在 Java中，大部分声称线程安全的类都属于这种类型，例如 Vector、HashTable、Collections 的 synchronizedCollection0)方法包装的集合等。

4、线程兼容

指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用。

我们平常说一个类不是线程安全的，通常就是指这种情况。Java 类库 API 中大部分的类都是线程兼容的，比如前面的 Vector和HashTable 相对应的集合类 ArrayList 和HashMap等

5、线程对立

线程对立是指不管调用端是否采取了同步措施，都无法在多线程环境中并发使用代码。

由于 Java 语言天生就支持多线程的特性，线程对立这种排斥多线程的代码是很少出现的而且通常都是有害的，应当尽量避免。

一个线程对立的例子是 Thread 类的suspend() 和resume()方法。如果有两个线程同时持有一个线程对象，一个尝试去中断线程，一个尝试去恢复线程。在并发进行的情况下无论调用时是否进行了同步，目标线都存在死锁风险；假如suspend() 中断的线程就是即将要执行 resume()的那个线程，那就肯定要产生死锁了。也正是这个原因，suspend()和resume()方法都已经被声明废弃了。常见的线程对立的操作还有 System.setIn()、Sytem.setOut() 和 System. runFinalizersOnExit() 等

线程安全的实现方法

1、互斥同步

互斥同步(Mutual Exclusion & Synchronization)是一种最常见也是最主要的并发正确性保障手段。

同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一条(或者是一些，当使用信号量的时候)线程使用。

而互斥是实现同步的一种手段，临界区(Critical Section)、互斥量(Mutex)和信号量(Semaphore) 都是常见的互斥实现方式。

因此在“互斥同步”这四个字里面，互斥是因，同步是果;互斥是方法，同步是目的。

synchronized

在 Java 里面，最基本的互斥同步手段就是 synchronized关键字，这是一种块结构(Block Structured)的同步语法。synchronized 关键字经过Javac 编译之后，会在同步块的前后分别形成 monitorenter 和 monitorexit 这两个字节码指令。这两个字节码指令都需要一个reference 类型的参数来指明要锁定和解锁的对象。

如果 Java源码中的 synchronized 明确指定了对象参数，那就以这个对象的引用作为 reference ;如果没有明确指定，那将根据synchronized 修饰的方法类型(如实例方法或类方法)，来决定是取代码所在的对象实例还是类型对应的 Class 对象来作为线程要持有的锁。

在执行 monitorenter 指令时，首先要去尝试获取对象的锁。如果这个对象没被锁定，或者当前线程已经持有了那个对象的锁，就把锁的计数器的值增加一，而在执行 monitorexit 指令时会将锁计数器的值减一。一旦计数器的值为零,锁随即就被释放了。如果获取对象锁失败，那当前线程就应当被阻塞等待，直到请求锁完的对象被持有它的线程释放为止。

从 monitorenter 和 monitorexit 的行为描述我们可以得出两个关于 synchronized 的直接推论，这是使用它时需特别注意的:

1、被 synchronized 修饰的同步块对同一条线程来说是可重入的。这意味着同一线程反复进人同步块也不会出现自己把自己锁死的情况。

2、被 synchronized 修饰的同步块在持有锁的线程执行完毕并释放锁之前，会无条件地阻塞后面其他线程的进入。这意味着无法像处理某些数据库中的锁那样，强制已获取锁的线程释放锁，也无法强制正在等待锁的线程中断等待或超时退出。

从执行成本的角度看，持有锁是一个重量级 ( Heavy-Weight) 的操作。

在主流 Java 虚拟机实现中，Java 的线程是映射到操作系统的原生内核线程之上的，如果要阻塞或唤醒一条线程，则需要操作系统来帮忙完成，这就不可避免地陷人用户态到核心态的转换中，进行这种状态转换需要耗费很多的处理器时间。尤其是对于代码特别简单的同步块(譬如被 synchronized 修饰的 getter()或setter()方法)，状态转换消耗的时间甚至会比用户代码本身执行的时间还要长。

所以 synchronized 是 Java语言中一个重量级的操作，有经验的程序员都只会在确实必要的情况下才使用这种操作。

而虚拟机本身也会进行一些优化，譬如在通知操作系统阻塞线程之前加人一段自旋等待过程以避免频繁地切入核心态之中。

ReentrantLock

除了 synchronized 关键字以外自JDK 5起，Java类库中新提供了 JUC包，其中的 java.util.concurrent.locks.Lock 接口便成了 Java 的另一种全新的互斥同步手段。

基于Lock 接口，用户能够以非块结构(Non-Block Structured)来实现互斥同步，从而摆脱了语言特性的束缚，改为在类库层面去实现同步。

重入锁(ReentrantLock)是 Lock 接口最常见的一种实现，顾名思义，它与 synchronized一样是可重入的。

在基本用法上，ReentrantLock 也与 synchronized 很相似，只是代码写法稍有区别。

不过、ReentrantLock与 synchronized相比增加了三项高级功能：

等待可中断：是指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，处理别的事情，
公平锁：多个线程在等待同一个锁的时候必须按照申请所得顺序一次获取锁，但是非公平锁则不保证这一点，在做锁被释放的时候，任何等待锁的线程都有机会抢占到锁， synchronized 、 reentrantLock 默认都是非公平的。
多个条件变量：一个 ReentrantLock 对象可以同时绑定多个 Condition对象；在synchronized中，锁对象的wait()跟它的notify() 或者notifyAll()方法配合可必实现一个隐含的条件，如果要和多于一个的条件关联的时候，就不得不额外添加一个锁；而ReentrantLock则无须这样做，多次调用newCondition()方法即可。

优先使用 synchronized的原因：

1、synchronized 是在 Java 语法层面的同步，足够清晰，也足够简单。每个 Java 程序员都熟悉 synchronized，但J.U.C 中的 Lock 接口则并非如此。因此在只需要基础的同步功能时，更推荐 synchronized。

2、 Lock应该确保在 finally块中释放锁，否则一旦受同步保护的代码块中抛出异常，则有可能永远不会释放持有的锁。这一点必须由程序员自己来保证，而使用synchronized 的话则可以由 Java 虚拟机来确保即使出现异常，锁也能被自动释放。

2、非阻塞同步

互斥同步面临的主要问题——线程阻塞和唤醒所带来的性能开销，因此这种同步也被称为阻塞同步 (Blocking Synchronization)。

从解决问题的方式上看，互斥同步属于一种悲观的并发策略，其总是认为只要不去做正确的同步措施 (例如加锁)，那就肯定会出现问题。无论共享的数据据否真的会出现竞争，它都会进行加锁。这将会导致用户态转为核心态，维护锁的计数器和检查是否有被阻塞的线程需要被唤醒等开销。

现在有了更好的选择：基于冲突检测的乐观并发策略，就是指：直接进行操作，如果没有其他线程争用共享数据，那操作就直接成功了；如果共享的数据的确被争用，产生了冲突，那再进行其他的补偿措施，最常用的补偿措施是不断地重试，直到出现设有竞争的共享数据为止。

这种乐观并发策略的实现不再需要把线程阻塞挂起，因此这种同步操作被称为非阻塞同步( Non-Blocking Synchronization)，使用这种措施的代码也常被称为无锁 (Lock-Free)编程。

但是上述的过程说的就是：必须要求操作和冲突检测这两个步骤具备原子性。

靠什么来保证原子性

如果这里再使用互斥同步来保证就完全失去意义了，所以我们只能靠硬件来实现这件事情，硬件保证某些从语义上看起来需要多次操作的行为可以只通过一条处理器指令就能完成，这类指令常用的有:

测试并设置(Test-and-Set);
获取并增加(Fetch-and-Increment);
交换(Swap);
比较并交换(Compare-and-Swap，下文称 CAS);
加载链接/条件储存(Load-Linked/Store-Conditional，下文称 LL/SC)。

Java 里最终暴露出来的是 CAS 操作，CAS 指令需要有三个操作数：分别是内存位置(可以简单地理解为变量的内存地址，用 V 表示)、旧的预期值(用 A 表示)和准备设置的新值 (用 B 表示)。

CAS ：

原理

CAS 指令执行时，当且仅当 V 符合 A 时，处理器才会用B 更新V的值，否则它就不执行更新。但是，不管是否更新了 V 的值，都会返回V 的旧值，上述的处理过程是一个原子操作，执行期间不会被其他线程中断。

Java类库中才开始使用 CAS 操作，该操作由 sun.misc.Unsafe类里面的 compareAndSwapInt()和compareAndSwapLong()等几个方法包装提供。

不过由于 Unsae类在设计上就规定了只有启动类加载器(Bootstrap ClassLoader) 加载的 Class 才能访问它)，因此在 JDK9之前只有 Java 类库可使用CAS，比如 JUC 包里面的原子类。其中的 compareAndSet()和 getAndlnctement()等方法都使用了 Unsafe 类的 CAS 操作来实现。而如果用户程序也有使用 CAS 操作的需求，那要么就采用反射手段突破 Unsnfe 的访问限制，要么就只能通过Java类库 API间接使用它。

比如说：incrementAndGet() 方法在一个无限循环中，不断尝试将一个比当前值大 1的新值赋值给自己。如果失败了，那说明在执行 CAS 操作的时候，旧值已经发生改变，于是再次循环进行下一次操作，直到设置成功为止。

优点

CAS 看起来很美好，既简单又高效

弊端：

这种操作无法涵盖互斥同步的所有使用场景，并且 CAS 从语义上来说并不是真正完美的，它存在一个逻辑漏洞:如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然为 A值，那就能说明它的值没有被其他线程改变过了吗?这是不能的，因为如果在这段期间它的值曾经被改成B，后来又被改回为 A，那 CAS 操作就会误认为它从来没有被改变过。这个漏洞称为 CAS操作的ABA 问题。

J.U.C 包为了解决这个问题，提供了一个带有标记的原子引用类AtomicStampedReference，它可以通过控制变量值的版本来保证 CAS 的正确性。不过目前来说这个类处于相当鸡肋的位置，大部分情况下 ABA 问题不会影响程序并发的正确性，如果需要解决 ABA 问题，改用传统的互斥同步可能会比原子类更为高效。

3、无同步方案

要保证线程安全，也并非一定要进行阻塞或非阻塞同步，同步与线程安全两者没有必然的联系。

同步只是保障存在共享数据争用时正确性的手段，如果能让一个方法本来就不涉及共享数据，那它自然不需要任何同步措施去进行保证正确性。

因此一些代码天生就是线程安全的，有如下两类。

可重人代码：这种代码又称纯代码( Pure Code)，是指可以在代码执行的任何时刻中断它，转而去执行另外一段代码(包括递归调用它本身)，而在控制权返回后，原来的程序不会出现任何错误，也不会对结果有所影响。

在特指多线程的上下文语境里(不涉及信号量等因素)，我们可以认为可重入代码是线程安全代码的一个真子集，这意味着相对线程安全来说，可重入性是更为基础的特性，它可以保证代码线程安全，即所有可重入的代码都是线程安全的，但反之不然。

可重人代码有一些共同的特征：例如，不依赖全局变量、存储在堆上的数据和公用的系统资源，用到的状态量都由参数中传入，不调用非可重人的方法等。

我们可以通过一个比较简单的原则来判断代码是否具备可重人性：如果一个方法的返回结果是可以预测的，只要输人了相同的数据，就都能返回相同的结果，那它就满足可重人性的要求，当然也就是线程安全的。
线程本地存储( Thread Local Storage)😗*如果一段代码中所需要的数据必须与其他代码共享，那就看看这些共享数据的代码是否能保证在同一个线程中执行。如果能保证，我们就可以把共享数据的可见范围限制在同一个线程之内，**这样，无须同步也能保证线程之间不出现数据争用的问题。

符合这种特点的应用并不少见，大部分使用消费队列的架构模式 (如生产者 - 消费者模式)都会将产品的消费过程限制在一个线程中消费完；

其中最重要的一种应用实例就是经典 Web 交互模型中的一个请求对应一个服务器线程(Thread-per-Request)的处理方式，这种处理方式的广泛应用使得很多 Web 服务端应用都可以使用线程本地存储来解决线程安全问题。

Java 语言中，如果一个变量要被多线程访问，可以使用 volatile 关键字将它声明为易变的;如果一个变量只要被某个线程独享，可以通过java.lang.ThreadLocal 类来实现线程本地存储的功能。每一个线程的 Thread 对象中都有一个 ThreadLocalMap 对象，这个对象存储了一组以 ThreadLocal.threadLocalHashCode 为键，以本地线程变量为值的 K-V 键值对，ThreadLoca对象就是当前线程的 ThreadLocalMap 的访问入口，每一个 ThreadLocal对象都包含了一个独一无二的 threadLocalHashCode 值，使用这个值就可以在线程 K-V 值对中找回对应的本地线程变量。