.png){kind=small}
Java语言中的线程安全
我们[1]可以将Java语言中各种操作共享的数
据分为以下五类：不可变、绝对线程安全、相对线程安全、线程兼容和线程对立。
不可变
Java语言中，如果多线程共享的数据是一个基本数据类型，那么只要在定义时使用final关键字修饰
它就可以保证它是不可变的。如果共享数据是一个对象，由于Java语言目前暂时还没有提供值类型的
支持，那就需要对象自行保证其行为不会对其状态产生任何影响才行。如果读者没想明白这句话所指
的意思，不妨类比java.lang.String类的对象实例，它是一个典型的不可变对象，用户调用它的
substring()、replace()和concat()这些方法都不会影响它原来的值，只会返回一个新构造的字符串对象。
保证对象行为不影响自己状态的途径有很多种，最简单的一种就是把对象里面带有状态的变量都
声明为final，这样在构造函数结束之后，它就是不可变的。
绝对线程安全
在Java API中标注自己是线程安全的类，大多数都不是绝对的线程安全。如果说java.util.Vector是一个线程安全的容器，相信所有的Java程序员对此都不会有异议，因为它
的add()、get()和size()等方法都是被synchronized修饰的，尽管这样效率不高，但保证了具备原子性、
可见性和有序性。不过，即使它所有的方法都被修饰成synchronized，也不意味着调用它的时候就永远
都不再需要同步手段了。
运行结果如下：
Exception in thread "Thread-132" java.lang.ArrayIndexOutOfBoundsException:
Array index out of range: 17
at 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异常。
必须加入同步保证Vector访问的线程安全性
假如Vector一定要做到绝对的线程安全，那就必须在它内部维护一组一致性的快照访问才行，每次
对其中元素进行改动都要产生新的快照，这样要付出的时间和空间成本都是非常大的。
相对线程安全
相对线程安全就是我们通常意义上所讲的线程安全，它需要保证对这个对象单次的操作是线程安
全的，我们在调用的时候不需要进行额外的保障措施，但是对于一些特定顺序的连续调用，就可能需
要在调用端使用额外的同步手段来保证调用的正确性。
在Java语言中，大部分声称线程安全的类都属于这种类型，例如Vector、HashTable、Collections的
synchronizedCollection()方法包装的集合等。
线程兼容
线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对
象在并发环境中可以安全地使用。我们平常说一个类不是线程安全的，通常就是指这种情况。Java类
库API中大部分的类都是线程兼容的，如与前面的Vector和HashTable相对应的集合类ArrayList和HashMap等。
线程对立
线程对立是指不管调用端是否采取了同步措施，都无法在多线程环境中并发使用代码。由于Java
语言天生就支持多线程的特性，线程对立这种排斥多线程的代码是很少出现的，而且通常都是有害
的，应当尽量避免。
线程安全的实现方法
互斥同步
互斥同步（Mutual Exclusion & Synchronization）是一种最常见也是最主要的并发正确性保障手
段。同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一条（或者是一些，
当使用信号量的时候）线程使用。而互斥是实现同步的一种手段，临界区（Critical Section）、互斥量
（Mutex）和信号量（Semaphore）都是常见的互斥实现方式。因此在“互斥同步”这四个字里面，互斥
是因，同步是果；互斥是方法，同步是目的。
在Java里面，最基本的互斥同步手段就是synchronized关键字，这是一种块结构（Block
Structured）的同步语法。synchronized关键字经过Javac编译之后，会在同步块的前后分别形成
monitorenter和monitorexit这两个字节码指令。这两个字节码指令都需要一个reference类型的参数来指明
要锁定和解锁的对象。如果Java源码中的synchronized明确指定了对象参数，那就以这个对象的引用作
为reference；如果没有明确指定，那将根据synchronized修饰的方法类型（如实例方法或类方法），来
决定是取代码所在的对象实例还是取类型对应的Class对象来作为线程要持有的锁。
根据《Java虚拟机规范》的要求，在执行monitorenter指令时，首先要去尝试获取对象的锁。如果
这个对象没被锁定，或者当前线程已经持有了那个对象的锁，就把锁的计数器的值增加一，而在执行
monitorexit指令时会将锁计数器的值减一。一旦计数器的值为零，锁随即就被释放了。如果获取对象
锁失败，那当前线程就应当被阻塞等待，直到请求锁定的对象被持有它的线程释放为止。
从功能上看，根据以上《Java虚拟机规范》对monitorenter和monitorexit的行为描述，我们可以得出
两个关于synchronized的直接推论，这是使用它时需特别注意的：
·被synchronized修饰的同步块对同一条线程来说是可重入的。这意味着同一线程反复进入同步块
也不会出现自己把自己锁死的情况。
·被synchronized修饰的同步块在持有锁的线程执行完毕并释放锁之前，会无条件地阻塞后面其他
线程的进入。这意味着无法像处理某些数据库中的锁那样，强制已获取锁的线程释放锁；也无法强制
正在等待锁的线程中断等待或超时退出。
从执行成本的角度看，持有锁是一个重量级（Heavy-Weight）的操作。在第10章中我们知道了在
主流Java虚拟机实现中，Java的线程是映射到操作系统的原生内核线程之上的，如果要阻塞或唤醒一条
线程，则需要操作系统来帮忙完成，这就不可避免地陷入用户态到核心态的转换中，进行这种状态转
换需要耗费很多的处理器时间。尤其是对于代码特别简单的同步块（譬如被synchronized修饰的getter()或setter()方法），状态转换消耗的时间甚至会比用户代码本身执行的时间还要长。因此才说，
synchronized是Java语言中一个重量级的操作，有经验的程序员都只会在确实必要的情况下才使用这种
操作。而虚拟机本身也会进行一些优化，譬如在通知操作系统阻塞线程之前加入一段自旋等待过程，
以避免频繁地切入核心态之中。
从上面的介绍中我们可以看到synchronized的局限性，除了synchronized关键字以外，自JDK 5起
（实现了JSR 166 [1]），Java类库中新提供了java.util.concurrent包（下文称J.U.C包），其中的
java.util.concurrent.locks.Lock接口便成了Java的另一种全新的互斥同步手段。基于Lock接口，用户能够
以非块结构（Non-Block Structured）来实现互斥同步，从而摆脱了语言特性的束缚，改为在类库层面
去实现同步，这也为日后扩展出不同调度算法、不同特征、不同性能、不同语义的各种锁提供了广阔
的空间。
重入锁（ReentrantLock）是Lock接口最常见的一种实现[2]，顾名思义，它与synchronized一样是可
重入[3]的。在基本用法上，ReentrantLock也与synchronized很相似，只是代码写法上稍有区别而已。不
过，ReentrantLock与synchronized相比增加了一些高级功能，主要有以下三项：等待可中断、可实现公
平锁及锁可以绑定多个条件。
·等待可中断：是指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改
为处理其他事情。可中断特性对处理执行时间非常长的同步块很有帮助。（依靠cas实现的）
·公平锁：是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平
锁则不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized中的锁是非
公平的，ReentrantLock在默认情况下也是非公平的，但可以通过带布尔值的构造函数要求使用公平
锁。不过一旦使用了公平锁，将会导致ReentrantLock的性能急剧下降，会明显影响吞吐量。
·锁绑定多个条件：是指一个ReentrantLock对象可以同时绑定多个Condition对象。在synchronized
中，锁对象的wait()跟它的notify()或者notifyAll()方法配合可以实现一个隐含的条件，如果要和多于一
个的条件关联的时候，就不得不额外添加一个锁；而ReentrantLock则无须这样做，多次调用
newCondition()方法即可。
ReentrantLock在功能上是synchronized的超集，在性能上又至少不会弱于
synchronized，那synchronized修饰符是否应该被直接抛弃，不再使用了呢？当然不是，基于以下理
由，笔者仍然推荐在synchronized与ReentrantLock都可满足需要时优先使用synchronized：
·synchronized是在Java语法层面的同步，足够清晰，也足够简单。每个Java程序员都熟悉
synchronized，但J.U.C中的Lock接口则并非如此。因此在只需要基础的同步功能时，更推荐
synchronized。
·Lock应该确保在finally块中释放锁，否则一旦受同步保护的代码块中抛出异常，则有可能永远不
会释放持有的锁。这一点必须由程序员自己来保证，而使用synchronized的话则可以由Java虚拟机来确
保即使出现异常，锁也能被自动释放。（比如synchronized代码反编译后，每种异常分支都有moniter exit的命令）
·尽管在JDK 5时代ReentrantLock曾经在性能上领先过synchronized，但这已经是十多年之前的胜利
了。从长远来看，Java虚拟机更容易针对synchronized来进行优化，因为Java虚拟机可以在线程和对象
的元数据中记录synchronized中锁的相关信息，而使用J.U.C中的Lock的话，Java虚拟机是很难得知具体
哪些锁对象是由特定线程锁持有的。
非阻塞同步
互斥同步面临的主要问题是进行线程阻塞和唤醒所带来的性能开销，因此这种同步也被称为阻塞
同步（Blocking Synchronization）。从解决问题的方式上看，互斥同步属于一种悲观的并发策略，其总
是认为只要不去做正确的同步措施（例如加锁），那就肯定会出现问题，无论共享的数据是否真的会
出现竞争，它都会进行加锁（这里讨论的是概念模型，实际上虚拟机会优化掉很大一部分不必要的加
锁），这将会导致用户态到核心态转换、维护锁计数器和检查是否有被阻塞的线程需要被唤醒等开
销。随着硬件指令集的发展，我们已经有了另外一个选择：基于冲突检测的乐观并发策略，通俗地说
就是不管风险，先进行操作，如果没有其他线程争用共享数据，那操作就直接成功了；如果共享的数
据的确被争用，产生了冲突，那再进行其他的补偿措施，最常用的补偿措施是不断地重试，直到出现
没有竞争的共享数据为止。这种乐观并发策略的实现不再需要把线程阻塞挂起，因此这种同步操作被
称为非阻塞同步（Non-Blocking Synchronization），使用这种措施的代码也常被称为无锁（Lock-Free）
编程。
为什么笔者说使用乐观并发策略需要“硬件指令集的发展”？因为我们必须要求操作和冲突检测这
两个步骤具备原子性。靠什么来保证原子性？如果这里再使用互斥同步来保证就完全失去意义了，所
以我们只能靠硬件来实现这件事情，硬件保证某些从语义上看起来需要多次操作的行为可以只通过一
条处理器指令就能完成，这类指令常用的有：
·测试并设置（Test-and-Set）；
·获取并增加（Fetch-and-Increment）；
·交换（Swap）；
·比较并交换（Compare-and-Swap，下文称CAS）；
·加载链接/条件储存（Load-Linked/Store-Conditional，下文称LL/SC）。
CAS指令需要有三个操作数，分别是内存位置（在Java中可以简单地理解为变量的内存地址，用V
表示）、旧的预期值（用A表示）和准备设置的新值（用B表示）。CAS指令执行时，当且仅当V符合
A时，处理器才会用B更新V的值，否则它就不执行更新。但是，不管是否更新了V的值，都会返回V的
旧值，上述的处理过程是一个原子操作，执行期间不会被其他线程中断。
在JDK 5之后，Java类库中才开始使用CAS操作，该操作由sun.misc.Unsafe类里面的
compareAndSwapInt()和compareAndSwapLong()等几个方法包装提供。HotSpot虚拟机在内部对这些方
法做了特殊处理，即时编译出来的结果就是一条平台相关的处理器CAS指令，没有方法调用的过程，
或者可以认为是无条件内联进去了[5]。不过由于Unsafe类在设计上就不是提供给用户程序调用的类
（Unsafe::getUnsafe()的代码中限制了只有启动类加载器（Bootstrap ClassLoader）加载的Class才能访问
它），因此在JDK 9之前只有Java类库可以使用CAS，譬如J.U.C包里面的整数原子类，其中的
compareAndSet()和getAndIncrement()等方法都使用了Unsafe类的CAS操作来实现。而如果用户程序也有
使用CAS操作的需求，那要么就采用反射手段突破Unsafe的访问限制，要么就只能通过Java类库API来
间接使用它。直到JDK 9之后，Java类库才在VarHandle类里开放了面向用户程序使用的CAS操作。
尽管CAS看起来很美好，既简单又高效，但显然这种操作无法涵盖互斥同步的所有使用场景，并
且CAS从语义上来说并不是真正完美的，它存在一个逻辑漏洞：如果一个变量V初次读取的时候是A
值，并且在准备赋值的时候检查到它仍然为A值，那就能说明它的值没有被其他线程改变过了吗？这
是不能的，因为如果在这段期间它的值曾经被改成B，后来又被改回为A，那CAS操作就会误认为它从
来没有被改变过。这个漏洞称为CAS操作的“ABA问题”。J.U.C包为了解决这个问题，提供了一个带有标记的原子引用类AtomicStampedReference，它可以通过控制变量值的版本来保证CAS的正确性。不过
目前来说这个类处于相当鸡肋的位置，大部分情况下ABA问题不会影响程序并发的正确性，如果需要
解决ABA问题，改用传统的互斥同步可能会比原子类更为高效。