1. Java 语言中的线程安全
按照线程安全的 “安全程度” 由强至弱来排序，可以将 Java 语言中各种操作共享的数据分为以下五类：不可变、绝对线程安全、相对线程安全、线程兼容和线程对立。
1.1 不可变
不可变的对象一定是线程安全的，无论是对象的方法实现还是方法的调用者，都不需要再进行任何线程安全保障措施。
Java 语言中，如果多线程共享的数据是一个基本数据类型，那么只要定义时使用 final 关键字修饰他就可以保证它是不可变的，如果共享数据是一个对象类型，由于 Java 语言目前暂时还没有提供值类型的支持，那就需要对象自行保证其行为不会对其状态产生任何影响才行。
例如：java.lang.String 类的对象实例，它是一个典型的不可变对象，用户调用它的 substring()、replace() 和 concat() 这些方法都不会影响它原来的值，只会返回一个新构造的字符串对象。
保证对象行为不影响自己状态的途径有很多种，最简单的一种就是把对象里面带有状态的变量都声明为 final，这样在构造函数结束之后，它就是不可变的，例如下面代码中 java.lang.Integer 的构造函数，它通过将内部状态变量 value 定义为 final 来保障状态不变 ：
private final int value;public Integer(int value) {this.value = value;}
在 Java 类库 API 中符合不可变要求的类型，除了上面提到的 String 之外，常用的还有枚举类型及 java.lang.Number 的部分子类，如 Long 和 Double 等数值包装类型、BigInteger 和 BigDecimal 等大数据类型。但同为 Number 子类型的原子类 AtomicInteger 和 AtomicLong 则是可变的。
1.2 绝对线程安全
Java API 中标注自己是线程安全的类，大多数都不是绝对的线程安全。java.util.Vector 是个线程安全的容器，add()、get()、size() 等方法都是被synchronized修饰的，保证了具备原子性、可见性和有序性。不过，就算是所有方法都被synchronized修饰，那也不意味着调用它的时候就不需要同步手段了。
如下代码，对 Vector 线程安全性的测试 ：
private static Vector<Integer> vector = new Vector<Integer>();public static void main(String[] args) {while (true) {for (int i = 0; i < 10; i++) {vector.add(i);}Thread removeThread = new Thread(new Runnable() {@Overridepublic void run() {for (int i = 0; i < vector.size(); i++) {vector.remove(i);}}};Thread printThread = new Thread(new Runnable() {@Overridepublic void run() {for (int i = 0; i < vector.size(); i++) {System.out.println((vector.get(i)));}}});removeThread.start();printThread.start();while (Thread.activeCount() > 20);}}
运行结果如下：
Exception in thread "Thread-132" java.lang.ArrayIndexOutOfBoundsException:Array index out of range: 17at java.util.Vector.remove(Vector.java:777)at org.fenixsoft.mulithread.VectorTest$1.run(VectorTest.java:21)at java.lang.Thread.run(Thread.java:662)
尽管这里使用到的 Vector 的 get()、remove() 和 size() 方法都是同步的，但是在多线程的环境中，如果不在方法调用端做额外的同步措施，使用这段代码仍然是不安全的。因为如果另一个线程恰好在错误的时间里删除了一个元素，导致序号 i 已经不再可用，再用 i 访问数组就会抛出一个 ArrayIndexOutOfBoundsException 异常。如果要保证这段代码能正确执行下去，我们不得不把 removeThread 和 printThread 的定义改成如下所示：
Thread removeThread = new Thread(new Runnable() {@Overridepublic void run() {synchronized (vector) {for (int i = 0; i < vector.size(); i++) {vector.remove(i);}}}});Thread printThread = new Thread(new Runnable() {@Overridepublic void run() {synchronized (vector) {for (int i = 0; i < vector.size(); i++) {System.out.println((vector.get(i)));}}}});
假如 Vector 一定要做到绝对的线程安全，那就必须在它内部维护一组一致性的快照访问才行，每次对其中元素进行改动都要产生新的快照，这样要付出的时间和空间成本都是非常大的。
1.3 相对线程安全
相对线程安全就是我们通常意义上所讲的线程安全，它需要保证对这个对象单次的操作是线程安全的，我们在调用的时候不需要进行额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。
在 Java 语言中，大部分声称线程安全的类都属于这种类型，例如 Vector、HashTable、Collections 的 synchronizedCollection() 方法包装的集合等。
1.4 线程兼容
线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用。我们平常说一个类不是线程安全的，通常就是指这种情况。Java 类库 API 中大部分的类都是线程兼容的，如与前面的 Vector 和 HashTable 相对应的集合类 ArrayList 和 HashMap 等。
1.5 线程对立
线程对立是指不管调用端是否采取了同步措施，都无法在多线程环境中并发使用代码。由于 Java 语言天生就支持多线程的特性，线程对立这种排斥多线程的代码是很少出现的，而且通常都是有害的，应当尽量避免。
2. 线程安全的实现方法
2.1 互斥同步
互斥同步（Mutual Exclusion & Synchronization）是一种最常见也是最主要的并发正确性保障手段。同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一个线程使用。而互斥是实现同步的一种手段，临界区（Critical Section）、互斥量（Mutex）和信号量（Semaphore）都是常见的互斥实现方式。因此在 “互斥同步” 这四个字里面，互斥是因，同步是果；互斥是方法，同步是目的。
在 Java 里面，最基本的互斥同步手段就是 synchronized 关键字，这是一种块结构（Block Structured）的同步语法。synchronized 关键字经过 Javac 编译之后，会在同步块的前后分别形成 monitorenter 和 monitorexit 这两个字节码指令。这两个字节码指令都需要一个 reference 类型的参数来指明要锁定和解锁的对象。
如果 Java 源码中的 **synchronized** 明确指定了对象参数，那就以这个对象的引用作为 reference；如果没有明确指定，那将根据 **synchronized** 修饰的方法类型（如实例方法或类方法），来决定是取代码所在的对象实例还是取类型对应的 Class 对象来作为线程要持有的锁。
在执行 monitorenter 指令时，首先要去尝试获取对象的锁。如果这个对象没被锁定，或者当前线程已经持有了那个对象的锁，就把锁的计数器的值增加一，而在执行 monitorexit 指令时会将锁计数器的值减一。一旦计数器的值为零，锁随即就被释放了。如果获取对象锁失败，那当前线程就应当被阻塞等待，直到请求锁定的对象被持有它的线程释放为止。
由上面的描述，可得出
synchronized锁的一些特性：
- 被
synchronized修饰的同步块对同一条线程来说是可重入的。这意味着同一线程反复进入同步块也不会出现自己把自己锁死的情况。 - 被
synchronized修饰的同步块在持有锁的线程执行完毕并释放锁之前，会无条件地阻塞后面其他线程的进入。这意味着无法像处理某些数据库中的锁那样，强制已获取锁的线程释放锁；也无法强制正在等待锁的线程中断等待或超时退出。
从执行成本的角度看，synchronized 持有锁是 Java 语言中一个重量级（Heavy-Weight）的操作。主流 Java 虚拟机实现中，Java 的线程是映射到操作系统的原生内核线程之上的，如果要阻塞或唤醒一条线程，则需要操作系统来帮忙完成，这就不可避免地陷入用户态到核心态的转换中，进行这种状态转换需要耗费很多的处理器时间。
实际上，虚拟机本身会对 synchronized 持锁操作进行一些优化，譬如在通知操作系统阻塞线程之前加入一段自旋等待过程，以避免频繁地切入核心态之中（这个问题下面小节再讨论）。
2.2 非阻塞同步
从解决问题的方式上看，互斥同步属于一种悲观的并发策略，其总 是认为只要不去做正确的同步措施（例如加锁），那就肯定会出现问题，无论共享的数据是否真的会 出现竞争，它都会进行加锁（这里讨论的是概念模型，实际上虚拟机会优化掉很大一部分不必要的加 锁），这将会导致用户态到核心态转换、维护锁计数器和检查是否有被阻塞的线程需要被唤醒等开 销。随着硬件指令集的发展，我们已经有了另外一个选择：基于冲突检测的乐观并发策略，通俗地说 就是不管风险，先进行操作，如果没有其他线程争用共享数据，那操作就直接成功了；
为什么笔者说使用乐观并发策略需要“硬件指令集的发展”？因为我们必须要求操作和冲突检测这两个步骤具备原子性 我们只能靠硬件来实现这件事情，这类指令常用的有：
- 测试并设置（Test-and-Set）；
- 获取并增加（Fetch-and-Increment）；
- 交换（Swap）；
- 比较并交换（Compare-and-Swap，下文称CAS）；
- 加载链接/条件储存（Load-Linked/Store-Conditional，下文称LL/SC）。
CAS指令
CAS指令需要有三个操作数，分别是内存位置（在Java中可以简单地理解为变量的内存地址，用V
表示）、旧的预期值（用A表示）和准备设置的新值（用B表示）。CAS指令执行时，当且仅当V符合 A时，处理器才会用B更新V的值，否则它就不执行更新。但是，不管是否更新了V的值，都会返回V的 旧值，上述的处理过程是一个原子操作，执行期间不会被其他线程中断
CAS下的ABA问题
尽管CAS看起来很美好，既简单又高效，但显然这种操作无法涵盖互斥同步的所有使用场景，并且CAS从语义上来说并不是真正完美的，它存在一个逻辑漏洞：如果一个变量V初次读取的时候是A 值，并且在准备赋值的时候检查到它仍然为A值，那就能说明它的值没有被其他线程改变过了吗？这 是不能的，因为如果在这段期间它的值曾经被改成B，后来又被改回为A，那CAS操作就会误认为它从 来没有被改变过。这个漏洞称为CAS操作的“ABA问题”
J.U.C包为了解决这个问题，提供了一个带有标记的原子引用类AtomicStampedReference，它可以通过控制变量值的版本来保证CAS的正确性。不过 目前来说这个类处于相当鸡肋的位置，大部分情况下ABA问题不会影响程序并发的正确性，如果需要 解决ABA问题，改用传统的互斥同步可能会比原子类更为高效。
2.3 无同步方案
要保证线程安全，也并非一定要进行阻塞或非阻塞同步，同步与线程安全两者没有必然的联系。
同步只是保障存在共享数据争用时正确性的手段，如果能让一个方法本来就不涉及共享数据，那它自 然就不需要任何同步措施去保证其正确性，因此会有一些代码天生就是线程安全的，笔者简单介绍其 中的两类：
可重入代码（Reentrant Code）：这种代码又称纯代码（Pure Code）
意味着相对线程安全来说，可重 入性是更为基础的特性，它可以保证代码线程安全，即所有可重入的代码都是线程安全的，但并非所 有的线程安全的代码都是可重入的。
线程本地存储（Thread Local Storage）
如果一段代码中所需要的数据必须与其他代码共享，那就看看这些共享数据的代码是否能保证在同一个线程中执行。如果能保证，我们就可以把共享数据的可 见范围限制在同一个线程之内，这样，无须同步也能保证线程之间不出现数据争用的问题。 符合这种特点的应用并不少见，大部分使用消费队列的架构模式（如“生产者-消费者”模式）都会 将产品的消费过程限制在一个线程中消费完，其中最重要的一种应用实例就是经典Web交互模型中 的“一个请求对应一个服务器线程”（Thread-per-Request）的处理方式，这种处理方式的广泛应用使得 很多Web服务端应用都可以使用线程本地存储来解决线程安全问题
3. 锁优化
3.1 自旋锁与自适应自旋
如果物理机器有一个以上的处理器或者处理器核心，能让两个或以上的线程同时并行执行，我们 就可以让后面请求锁的那个线程“稍等一会”，但不放弃处理器的执行时间，看看持有锁的线程是否很 快就会释放锁。为了让线程等待，我们只须让线程执行一个忙循环（自旋），这项技术就是所谓的自 旋锁
自旋锁：即，当一个线程去竞争共享资源时，该资源已被其他线程占用，这时该线程不会立刻进入挂起阻塞状态，而是通过不断自旋，等待共享资源使用权被持锁线程释放。当然，不可能让一个线程一直自旋等待下去，自旋等待的时间是必须有一定的限度的，如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程。自旋次数的默认值是 10 次，用户也可以使用参数 -XX：PreBlockSpin 来自行更改。
在 JDK 6 中对自旋锁的优化，引入了自适应的自旋。自适应意味着自旋的时间不再是固定的了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定的。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而允许自旋等待持续相对更长的时间，比如持续 100 次忙循环。另一方面，如果对于某个锁，自旋很少成功获得过锁，那在以后要获取这个锁时将有可能直接省略掉自旋过程，以避免浪费处理器资源。
3.2 锁消除
锁消除是指虚拟机即时编译器在运行时，对一些代码要求同步，但是对被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据支持（第11章已经讲解过逃逸 分析技术），如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可 以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须再进行。
锁消除：是指虚拟机即时编译器在运行时，对一些代码要求同步，但是对被检测到不可能存在共享资源竞争的锁进行消除。
锁消除的主要判定依据来源于逃逸分析的数据支持，如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须再进行。
示例如下：（示例 2-1）
public String concatString(String s1, String s2, String s3) {return s1 + s2 + s3;}
由于 String 是一个不可变的类，对字符串的连接操作总是通过生成新的 String 对象来进行的，因此 Javac 编译器会对 String 连接做自动优化。
在 JDK 5 之前，字符串加法会转化为 StringBuffer 对象的连续 append() 操作，在 JDK 5 及以后的版本中，会转化为 StringBuilder 对象的连续 append() 操作。
优化为如下所示：（示例 2-2）
public String concatString(String s1, String s2, String s3) {StringBuffer sb = new StringBuffer();sb.append(s1);sb.append(s2);sb.append(s3);return sb.toString();}
现在大家还认为这段代码没有涉及同步吗？每个 StringBuffer.append() 方法中都有一个同步块，锁就是 sb 对象。虚拟机观察变量 sb，经过逃逸分析后会发现它的动态作用域被限制在 concatString() 方法内部。也就是 sb 的所有引用都永远不会逃逸到 concatString() 方法之外，其他线程无法访问到它，所以这里虽然有锁，但是可以被安全地消除掉。在解释执行时这里仍然会加锁，但在经过服务端编译器的即时编译之后，这段代码就会忽略所有的同步措施而直接执行。
客观地说，既然谈到锁消除与逃逸分析，那虚拟机就不可能是 JDK 5 之前的版本，所以实际上会转化为非线程安全的 StringBuilder 来完成字符串拼接，并不会加锁。但是这也不影响笔者用这个例子证明 Java 对象中同步的普遍性。
3.3 锁粗化
原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变少，即使存在锁竞争，等待锁的线程也能尽可能快地拿到锁。
大多数情况下，上面的原则都是正确的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体之中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。
（示例 2-2）所示连续的 append() 方法就属于这类情况。如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部，以（示例 2-2）为例，就是扩展到第一个 append() 操作之前直至最后一个 append() 操作之后，这样只需要加锁一次就可以了。
总之，如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部。
3.4 轻量级锁
轻量级锁是 JDK 6 时加入的新型锁机制，它名字中的 “轻量级” 是相对于使用操作系统互斥量来实现的传统锁而言的，因此传统的锁机制就被称为 “重量级” 锁。轻量级锁并不是用来代替重量级锁的，它设计的初衷是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。
由于对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到 Java 虚拟机的空间使用效率，Mark Word 被设计成一个非固定的动态数据结构，以便在极小的空间内存储尽量多的信息。它会根据对象的状态复用自己的存储空间。
例如在 32 位的 HotSpot 虚拟机中，对象未被锁定的状态下，Mark Word 的 32 个比特空间里的25 个比特将用于存储对象哈希码，4 个比特用于存储对象分代年龄，2 个比特用于存储锁标志位，还有 1 个比特固定为 0（这表示未进入偏向模式）。
对象除了未被锁定的正常状态外，还有轻量级锁定、重量级锁定、GC 标记、可偏向等几种不同状态，这些状态下对象头的存储内容如下表所示：
在代码即将进入同步块的时候，如果此同步对象没有被锁定（锁标志位为 “01” 状态），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的 Mark Word 的拷贝，这时候线程堆栈与对象头的状态如下图所示：
然后，虚拟机将使用 CAS 操作尝试把对象的 Mark Word 更新为指向 Lock Record 的指针。如果这个更新动作成功了，即代表该线程拥有了这个对象的锁，并且对象 Mark Word 的锁标志位（Mark Word 的最后两个比特）将转变为 “00”，表示此对象处于轻量级锁定状态。这时候线程堆栈与对象头的状态如下图所示：
如果这个更新操作失败了，那就意味着至少存在一条线程与当前线程竞争获取该对象的锁。虚拟机首先会检查对象的 Mark Word 是否指向当前线程的栈帧，如果是，说明当前线程已经拥有了这个对象的锁，那直接进入同步块继续执行就可以了，否则就说明这个锁对象已经被其他线程抢占了。如果出现两条以上的线程争用同一个锁的情况，那轻量级锁就不再有效，必须要膨胀为重量级锁，锁标志的状态值变为 “10”，此时 Mark Word 中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也必须进入阻塞状态。
上面描述的是轻量级锁的加锁过程，它的解锁过程也同样是通过 CAS 操作来进行的，如果对象的 Mark Word 仍然指向线程的锁记录，那就用 CAS 操作把对象当前的 Mark Word 和线程中复制的 Displaced Mark Word 替换回来。假如能够成功替换，那整个同步过程就顺利完成了；如果替换失败，则说明有其他线程尝试过获取该锁，就要在释放锁的同时，唤醒被挂起的线程。
轻量级锁能提升程序同步性能的依据是 “对于绝大部分的锁，在整个同步周期内都是不存在竞争的” 这一经验法则。如果没有竞争，轻量级锁便通过 CAS 操作成功避免了使用互斥量的开销；但如果确实存在锁竞争，除了互斥量的本身开销外，还额外发生了 CAS 操作的开销。因此在有竞争的情况下，轻量级锁反而会比传统的重量级锁更慢。
3.5 偏向锁
偏向锁也是 JDK 6 中引入的一项锁优化措施，它的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。如果说轻量级锁是在无竞争的情况下使用 CAS 操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连 CAS 操作都不去做了。
偏向锁中的 “偏”，就是偏心的 “偏”、偏袒的 “偏”。它的意思是这个锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁一直没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。
假设当前虚拟机启用了偏向锁（启用参数 - XX：+UseBiased Locking，这是自 JDK 6 起 HotSpot 虚拟机的默认值），那么当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设置为 “01”、把偏向模式设置为 “1”，表示进入偏向模式。同时使用 CAS 操作把获取到这个锁的线程的 ID 记录在对象的 Mark Word 之中。如果 CAS 操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如加锁、解锁及对 Mark Word 的更新操作 等）。
一旦出现另外一个线程去尝试获取这个锁的情况，偏向模式就马上宣告结束。根据锁对象目前是否处于被锁定的状态决定是否撤销偏向（偏向模式设置为 “0”），撤销后标志位恢复到未锁定（标志位为 “01”）或轻量级锁定（标志位为 “00”）的状态，后续的同步操作就按照上面介绍的轻量级锁那样去执行。偏向锁、轻量级锁的状态转化及对象 Mark Word 的关系如下图所示：
若有收获，就点个赞吧
0 人点赞
