Java 线程安全与锁的那些事

线程安全

何为线程安全？维基百科上是这样描述的：线程安全是指函数、函数库在多线程环境中被调用时，能够正确地处理多个线程之间的共享变量，使程序功能正确完成。
《Java 并发编程实战》的作者之一 Brain Goetz 认为线程安全是指：当多个线程访问一个对象时，如果不用考虑这些线程在运行环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方法进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那这个对象是线程安全的。

实现线程安全的几种方式

1. 使用 final 关键字定义不可变性

在 Java 中，不可变（Immutable）的对象一定是线程安全的，无论是对象的方法实现还是方法的调用者，都不需要再采取任何的线程安全保障措施。只要一个不可变的对象被正确地构建出来，那其外部的可见状态永远不会改变，永远也不会看到它在多个线程之中处于不一致的状态。

2. 使用 volatile 关键字保证线程间的可见性，但不能保证原子性

volatile 是 Java 虚拟机提供的轻量级同步机制，当一个变量被定义为 volatile 后，它就具有两种特性：

$\color{red}{可见性}$
简单来说是当一个线程修改了被 volatile 修饰的值，新值对于其他线程来说是可以立即得知的，而普通变量不能做到这一点，普通变量的值在线程间传递均需通过主内存来完成。
$\color{red}{禁止指令重排序优化}$
普通的变量仅仅会保证在该方法执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与代码执行顺序一致。指令重排序是 Java 虚拟机所做的一项优化，但是在某些特定情况下会出现问题，比如使用 DCL 实现单例时就要加上 volatile 关键字，否则可能会出现单例失效的情况，代码如下：

 public class Singleton {
     //注意此处的volatile修饰符
     //Java编译器允许处理器乱序执行，会有DCL失效的问题
     //JDK大于等于1.5的版本，具体化了volatile关键字，定义时加上它可以保证执行的顺序（虽然会影响性能）
     //从而单例起效
     private static volatile Singleton instance;
 
     //private的构造函数，只能在本类内部实例化
     private Singleton() {
     }
 
     //通过此静态方法提供全局获取唯一可用对象的实例
     public static Singleton getInstance() {
         if (instance == null) {
             //第一次check，避免不必要的同步
             synchronized (Singleton.class) { //同步
                 if (instance == null) {
                     //第二次check，保证线程安全
                     instance = new Singleton();
                 }
             }
         }
         return instance;
     }
 }

3. 使用 Atomic 原子类

Atomic 原子类位于 java.util.concurrent.atomic 包下面，如下图：

实现同步的原理是把操作委托给 Unsafe 类中相关的 CAS 操作（系统级别支持），下文会具体阐述 CAS，关于 Unsafe 可以参考 Java魔法类：Unsafe应用解析
。

4. 使用 ThreadLocal

每个 Thread 维护着一个 ThreadLocalMap 的引用，而 ThreadLocalMap 是 ThreadLocal 的内部类，ThreadLocalMap 内部有个 Entry 数组，是真正存储数据的地方。总的来说，ThreadLocal 本省并不存储值，只是作为一个 key 来让 Thread 从自身的 ThreadLocalMap 获取对应的 value。从这个角度来看，使用 ThreadLocal 是线程安全的，有关 ThreadLocal 可以查看这篇文章——ThreadLocal 简析。

5. 使用 synchronized 关键字

synchronized 关键字实现线程安全是因为采用了互斥同步，具体说来，synchronized 关键字经过编译后，会在同步块的前后分别形成 monitorenter 和 monitorexit 这两个字节码指令，这两个字节码都需要一个 reference 类型的参数来指明要锁定和解锁的对象。如果 Java 程序中的 synchronized 明确指定了对象参数，那就是这个对象的 reference；如果没有明确指定，那就根据 synchronized 修饰的是实例方法还是类方法，去取对应的对象实例或 Class 对象来作为锁对象，也就是通常所说的对象锁和类锁。

每个对象都有一把隐形的锁，称为内部锁或者 Monitor 锁，Mointor 是线程私有的数据结构，其依赖于底层的操作系统的 Mutex Lock（互斥锁）来实现的线程同步。

自旋锁与自适应自旋 VS 偏向锁 VS 轻量级锁 VS 重量级锁

这四种锁是指锁的状态，专门针对 synchronized 的。

自旋锁与自适应自旋
自旋锁与自适应自旋没有对资源进行锁定，因为挂起与恢复线程的操作都需要耗费大量的资源，因此如果有两个或以上的线程同时并行执行，可以让后面请求锁的线程执行一个忙循环（自旋），这就是自旋锁机制。
自旋等待并不能代替阻塞，其本身虽然避免了线程切换的开销，但是它要占用处理器时间的，如果长时间的等待只会白白浪费处理器资源，因此在自旋到一定次数后(默认是10)就会挂起线程了。
自适应自旋是对自旋的一种优化，如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而允许自旋等待持续相对更长的时间。反之，如果对于某个锁，自旋很少成功获得过，那在以后获取这个锁时将可能省略掉自旋过程，以避免浪费处理器资源。
偏向锁
偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁，降低获取锁的代价。
当一个线程访问同步代码块并获取锁时，会在对象头的 Mark Word 里存储锁偏向的线程ID。在线程进入和退出同步块时不再通过 CAS 操作来加锁和解锁，而是检测 Mark Word 里是否存储着指向当前线程的偏向锁。引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次 CAS 原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令即可。
偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程不会主动释放偏向锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态。撤销偏向锁后恢复到无锁（标志位为“01”）或轻量级锁（标志位为“00”）的状态。
轻量级锁
轻量级锁是指当锁是偏向锁的时候，被另外的线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，从而提高性能。若当前只有一个等待线程，则该线程通过自旋进行等待。但是当自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁升级为重量级锁。
重量级锁
升级为重量级锁时，此时等待锁的线程都会进入阻塞状态。

整体的锁升级流程如下图：

6. 使用锁机制

乐观锁与悲观锁

对于共享数据，悲观锁认为自己在使用数据的时候一定有别的线程来修改数据，因此在获取数据的时候会先加锁，确保数据不会被别的线程修改。在 Java 中 synchronized 关键字和 Lock 的实现类都是悲观锁。

而乐观锁认为自己在使用数据的时候不会有别的线程修改数据，所以不会添加锁，只是在更新数据的时候去判断之前是否有别的线程去修改了数据，如果数据没有被更新，当前线程将自己修改的数据成功写入，如果数据已经被其他线程更新，则根据不同的实现方式执行不同的操作（例如报错或者自动重试）。

乐观锁在 Java 中最常采用的算法就是上面原子类提到的 CAS 算法，CAS 即 Compare And Swap（比较与交换），是一种无锁算法，在不适用锁（没有线程被阻塞）的情况下实现多线程之间的变量同步。CAS 算法如下：

需要读写的内存值 V。
进行比较的 A。
需要写入的新值 B。

当且仅当 V 的值等于 A 时，CAS 通过原子方式用新值 B 更新 V 的值（“比较 + 更新” 整体是一个原子操作），否则不会执行任何操作。一般情况下，“更新” 是一个不断重试的操作。CAS 虽然高效，但是也存在着三大问题：

ABA 问题，如果在内存中的值经历了 A-B-A 的变化，CAS 在进行检查是发现不了值是变更过的。ABA 问题的解决思路就是在变量前面添加版本号，每次更新的时候都把版本号加一，这样变化过程就从 A-B-A 变成了 A1 - B2 - A3。
循环时间长开销大，CAS 操作如果长时间不成功，会导致其一直自旋，给 CPU 带来了非常大的开销。
只能保证一个共享变量的原子操作，对一个共享变量执行操作是，CAS 能够保证原子操作，但是对多个共享变量操作时，CAS 是无法保证操作的原子性的，Java 从 1.5 开始提供了 AtomicReference 类来保证引用对象之间的原子性，可以把多个变量放在一个对象来进行 CAS 操作。

公平锁与非公平锁

公平锁是指多个线程按照申请锁的顺序来获取锁，线程直接进入队列中排队，队列中的第一个线程才能获得锁。公平锁的优点是等待锁的线程不会饿死。缺点是整体吞吐效率相对非公平锁要低，等待队列中除第一个线程以外的所有线程都会阻塞，CPU唤醒阻塞线程的开销比非公平锁大。

非公平锁是多个线程加锁时直接尝试获取锁，获取不到才会到等待队列的队尾等待。但如果此时锁刚好可用，那么这个线程可以无需阻塞直接获取到锁，所以非公平锁有可能出现后申请锁的线程先获取锁的场景。非公平锁的优点是可以减少唤起线程的开销，整体的吞吐效率高，因为线程有几率不阻塞直接获得锁，CPU不必唤醒所有线程。缺点是处于等待队列中的线程可能会饿死，或者等很久才会获得锁。synchronized 属于非公平锁。

可重入锁与非可重入锁

可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁（前提锁对象得是同一个对象或者class），不会因为之前已经获取过还没释放而阻塞。Java 中 ReentrantLock 和synchronized 都是可重入锁，可重入锁的一个优点是可一定程度避免死锁。

独享锁与共享锁

独享锁也叫排他锁，是指该锁一次只能被一个线程所持有。如果线程 T 对数据A加上排它锁后，则其他线程不能再对 A 加任何类型的锁。获得排它锁的线程即能读数据又能修改数据。JDK 中的 synchronized 和 JUC 中 Lock 的实现类就是互斥锁。

共享锁是指该锁可被多个线程所持有。如果线程 T 对数据 A 加上共享锁后，则其他线程只能对 A 再加共享锁，不能加排它锁。获得共享锁的线程只能读数据，不能修改数据。

Lock 与 Synchronized 的区别

Lock 是一个接口，而synchronized是 Java 的关键字，synchronized 是内置的语言实现。
synchonizd 在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而 Lock 在发生异常时，如果没有主动的调用 unlock 去释放锁，则很可能造成死锁现象，因此使用 Lock 时需要及时释放。
Lock 可以让等待锁的线程响应中断，而 synchronized 却不行，使用synchronized 时，等待的线程会一直等待下去，不能够响应中断。
通过 Lock 可以知道有没有成功获取锁，而 synchronized 却无法办到。
Lock 可以提高多个线程进行读操作的效率。

在性能上来说，如果竞争资源不激烈，两者的性能是差不多的，特别是随着虚拟机对 synchronized 的不断优化。

总结

本文主要阐述了几种实现线程安全的方式，在实践中需根据具体场景具体使用。

参考

不可不说的Java“锁”事
《深入理解 Java 虚拟机》
《Java 并发编程实战》