深入理解java虚拟机笔记-线程安全与锁优化2
了解过什么是线程安全之后， 紧接着的一个问题就是我们应该如何实现线程安全。 这听起来似乎是一件由代码如何编写来决定的事情， 不应该出现在讲解Java虚拟机的书里。 确实， 如何实现线程安全与代码编写有很大的关系， 但虚拟机提供的同步和锁机制也起到了至关重要的作用。 在本节中， 如何编写代码实现线程安全， 以及虚拟机如何实现同步与锁这两方面都会涉及， 相对而言更偏重后者一些， 只要读者明白了Java虚拟机线程安全措施的原理与运作过程， 自己再去思考代码如何编写就不是一件困难的事情了。
1.互斥同步
互斥同步是一种最常见也是最主要的并发正确性保障手段。 同步是指在多个线程并发访问共享数据时， 保证共享数据在同一个时刻只被一条线程使用。
而互斥是实现同步的一种手段， 临界区（Critical Section） 、 互斥量（Mutex） 和信号量（Semaphore） 都是常见的互斥实现方式。
因此在“互斥同步”这四个字里面， 互斥是因， 同步是果； 互斥是方法， 同步是目的。在Java里面， 最基本的互斥同步手段就是synchronized关键字， 这是一种块结构（BlockStructured） 的同步语法。 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语言中一个重量级的操作， 有经验的程序员都只会在确实必要的情况下才使用这种操作。 而虚拟机本身也会进行一些优化， 譬如在通知操作系统阻塞线程之前加入一段自旋等待过程，以避免频繁地切入核心态之中。 稍后我们会专门介绍Java虚拟机锁优化的措施。
从上面的介绍中我们可以看到synchronized的局限性， 除了synchronized关键字以外， 自JDK 5起， Java类库中新提供了java.util.concurrent包（下文称J.U.C包） ， 其中的java.util.concurrent.locks.Lock接口便成了Java的另一种全新的互斥同步手段。 基于Lock接口， 用户能够以非块结构（Non-Block Structured） 来实现互斥同步， 从而摆脱了语言特性的束缚， 改为在类库层面去实现同步， 这也为日后扩展出不同调度算法、 不同特征、 不同性能、 不同语义的各种锁提供了广阔的空间。 重入锁（ReentrantLock） 是Lock接口最常见的一种实现， 顾名思义， 它与synchronized一样是可重入的。 在基本用法上， ReentrantLock也与synchronized很相似， 只是代码写法上稍有区别而已。 不过ReentrantLock与synchronized相比增加了一些高级功能， 主要有三项： 等待可中断、 可实现公平锁及锁可以绑定多个条件。
等待可中断
是指当持有锁的线程长期不释放锁的时候， 正在等待的线程可以选择放弃等待， 改为处理其他事情。 可中断特性对处理执行时间非常长的同步块很有帮助。
公平锁
是指多个线程在等待同一个锁时， 必须按照申请锁的时间顺序来依次获得锁； 而非公平锁则不保证这一点， 在锁被释放时， 任何一个等待锁的线程都有机会获得锁。 synchronized中的锁是非公平的， ReentrantLock在默认情况下也是非公平的， 但可以通过带布尔值的构造函数要求使用公平锁。 不过一旦使用了公平锁， 将会导致ReentrantLock的性能急剧下降， 会明显影响吞吐量。
锁绑定多个条件：
是指一个ReentrantLock对象可以同时绑定多个Condition对象。 在synchronized中， 锁对象的wait()跟它的notify()或者notifyAll()方法配合可以实现一个隐含的条件， 如果要和多于一个的条件关联的时候， 就不得不额外添加一个锁； 而ReentrantLock则无须这样做， 多次调用newCondition()方法即可。
如果需要使用上述功能， 使用ReentrantLock是一个很好的选择， 那如果是基于性能考虑呢？synchronized对性能的影响， 尤其在JDK 5之前是很显著的， 为此在JDK 6中还专门进行过针对性的优化。 以synchronized和ReentrantLock的性能对比为例， Brian Goetz对这两种锁在JDK 5、 单核处理器及双Xeon处理器环境下做了一组吞吐量对比的实验， 实验结果如图13-1和图13-2所示。
从图13-1和图13-2中可以看出， 多线程环境下synchronized的吞吐量下降得非常严重， 而ReentrantLock则能基本保持在同一个相对稳定的水平上。 但与其说ReentrantLock性能好， 倒不如说当时的synchronized有非常大的优化余地， 后续的技术发展也证明了这一点。 当JDK 6中加入了大量针对synchronized锁的优化措施 之后， 相同的测试中就发现 synchronized与ReentrantLock的性能基本上能够持平。 相信现在阅读本书的读者所开发的程序应该都是使用JDK 6或以上版本来部署的， 所以性能已经不再是选择synchronized或者ReentrantLock的决定因素。
根据上面的讨论， ReentrantLock在功能上是synchronized的超集， 在性能上又至少不会弱于synchronized， 那synchronized修饰符是否应该被直接抛弃， 不再使用了呢？ 当然不是， 基于以下理由， 笔者仍然推荐在synchronized与ReentrantLock都可满足需要时优先使用synchronized：
·synchronized是在Java语法层面的同步， 足够清晰， 也足够简单。 每个Java程序员都熟悉synchronized， 但J.U.C中的Lock接口则并非如此。 因此在只需要基础的同步功能时， 更推荐synchronized。
·Lock应该确保在finally块中释放锁， 否则一旦受同步保护的代码块中抛出异常， 则有可能永远不会释放持有的锁。 而使用synchronized的话则可以由Java虚拟机来确保即使出现异常， 锁也能被自动释放。
·尽管在JDK 5时代ReentrantLock曾经在性能上领先过synchronized， 但这已经是十多年之前的胜利了。 从长远来看， Java虚拟机更容易针对synchronized来进行优化， 因为Java虚拟机可以在线程和对象的元数据中记录synchronized中锁的相关信息， 而使用J.U.C中的Lock的话， Java虚拟机是很难得知具体哪些锁对象是由特定线程锁持有的。
2.非阻塞同步
互斥同步面临的主要问题是进行线程阻塞和唤醒所带来的性能开销， 因此这种同步也被称为阻塞同步（Blocking Synchronization） 。 从解决问题的方式上看， 互斥同步属于一种悲观的并发策略， 其总是认为只要不去做正确的同步措施（例如加锁） ， 那就肯定会出现问题， 无论共享的数据是否真的会出现竞争， 它都会进行加锁（这里讨论的是概念模型， 实际上虚拟机会优化掉很大一部分不必要的加锁） ， 这将会导致用户态到核心态转换、维护锁计数器和检查是否有被阻塞的线程需要被唤醒等开销。
随着硬件指令集的发展， 我们已经有了另外一个选择：
基于冲突检测的乐观并发策略， 通俗地说就是不管风险， 先进行操作， 如果没有其他线程争用共享数据， 那操作就直接成功了； 如果共享的数据的确被争用， 产生了冲突， 那再进行其他的补偿措施， 最常用的补偿措施是不断地重试， 直到出现没有竞争的共享数据为止。 这种乐观并发策略的实现不再需要把线程阻塞挂起， 因此这种同步操作被称为非阻塞同步（Non-Blocking Synchronization） ， 使用这种措施的代码也常被称为无锁（Lock-Free）编程。 为什么笔者说使用乐观并发策略需要“硬件指令集的发展”？ 因为我们必须要求操作和冲突检测这两个步骤具备原子性。 靠什么来保证原子性？ 如果这里再使用互斥同步来保证就完全失去意义了， 所以我们只能靠硬件来实现这件事情， 硬件保证某些从语义上看起来需要多次操作的行为可以只通过一条处理器指令就能完成， 这类指令常用的有：
1.测试并设置（Test-and-Set）
2.获取并增加（Fetch-and-Increment）
3.交换（Swap）
4.比较并交换（Compare-and-Swap， 下文称CAS）
5.加载链接/条件储存（Load-Linked/Store-Conditional， 下文称LL/SC） 。
其中， 前面的三条是20世纪就已经存在于大多数指令集之中的处理器指令， 后面的两条是现代处理器新增的， 而且这两条指令的目的和功能也是类似的。 在IA64、 x86指令集中有用cmpxchg指令完成的CAS功能， 在SPARC-TSO中也有用casa指令实现的， 而在ARM和PowerPC架构下， 则需要使用一对ldrex/strex指令来完成LL/SC的功能。 因为Java里最终暴露出来的是CAS操作， 所以我们以CAS指令为例进行讲解。
CAS指令需要有三个操作数， 分别是内存位置（在Java中可以简单地理解为变量的内存地址， 用V表示） 、 旧的预期值（用A表示） 和准备设置的新值（用B表示） 。 CAS指令执行时， 当且仅当V符合A时， 处理器才会用B更新V的值， 否则它就不执行更新。 但是， 不管是否更新了V的值， 都会返回V的旧值， 上述的处理过程是一个原子操作， 执行期间不会被其他线程中断。
在JDK 5之后， Java类库中才开始使用CAS操作， 该操作由sun.misc.Unsafe类里面的compareAndSwapInt()和compareAndSwapLong()等几个方法包装提供。
使用AtomicInteger代替int后， 程序输出了正确的结果， 这一切都要归功于incrementAndGet()方法的原子性。
incrementAndGet()方法在一个无限循环中， 不断尝试将一个比当前值大一的新值赋值给自己。 如果失败了， 那说明在执行CAS操作的时候， 旧值已经发生改变， 于是再次循环进行下一次操作， 直到设置成功为止。
尽管CAS看起来很美好， 既简单又高效， 但显然这种操作无法涵盖互斥同步的所有使用场景， 并且CAS从语义上来说并不是真正完美的， 它存在一个逻辑漏洞： 如果一个变量V初次读取的时候是A值， 并且在准备赋值的时候检查到它仍然为A值， 那就能说明它的值没有被其他线程改变过了吗？ 这是不能的， 因为如果在这段期间它的值曾经被改成B， 后来又被改回为A， 那CAS操作就会误认为它从来没有被改变过。 这个漏洞称为CAS操作的“ABA问题”。 J.U.C包为了解决这个问题， 提供了一个带有标记的原子引用类AtomicStampedReference， 它可以通过控制变量值的版本来保证CAS的正确性。 不过目前来说这个类处于相当鸡肋的位置， 大部分情况下ABA问题不会影响程序并发的正确性， 如果需要解决ABA问题， 改用传统的互斥同步可能会比原子类更为高效。
3.无同步方案
要保证线程安全， 也并非一定要进行阻塞或非阻塞同步， 同步与线程安全两者没有必然的联系。
同步只是保障存在共享数据争用时正确性的手段， 如果能让一个方法本来就不涉及共享数据， 那它自然就不需要任何同步措施去保证其正确性， 因此会有一些代码天生就是线程安全的， 笔者简单介绍其中的两类。
可重入代码（Reentrant Code） ：
这种代码又称纯代码（Pure Code） ， 是指可以在代码执行的任何时刻中断它， 转而去执行另外一段代码（包括递归调用它本身） ， 而在控制权返回后， 原来的程序不会出现任何错误， 也不会对结果有所影响。 在特指多线程的上下文语境里 ， 我们可以认为可重入代码是线程安全代码的一个真子集， 这意味着相对线程安全来说， 可重入性是更为基础的特性， 它可以保证代码线程安全， 即所有可重入的代码都是线程安全的， 但并非所有的线程安全的代码都是可重入的。
可重入代码有一些共同的特征， 例如， 不依赖全局变量、 存储在堆上的数据和公用的系统资源，用到的状态量都由参数中传入， 不调用非可重入的方法等。 我们可以通过一个比较简单的原则来判断代码是否具备可重入性： 如果一个方法的返回结果是可以预测的， 只要输入了相同的数据， 就都能返回相同的结果， 那它就满足可重入性的要求， 当然也就是线程安全的。
线程本地存储（Thread Local Storage） ：
如果一段代码中所需要的数据必须与其他代码共享， 那就看看这些共享数据的代码是否能保证在同一个线程中执行。 如果能保证， 我们就可以把共享数据的可见范围限制在同一个线程之内， 这样， 无须同步也能保证线程之间不出现数据争用的问题。
符合这种特点的应用并不少见， 大部分使用消费队列的架构模式（如“生产者-消费者”模式） 都会将产品的消费过程限制在一个线程中消费完， 其中最重要的一种应用实例就是经典Web交互模型中的“一个请求对应一个服务器线程”（Thread-per-Request） 的处理方式， 这种处理方式的广泛应用使得很多Web服务端应用都可以使用线程本地存储来解决线程安全问题。
Java语言中， 如果一个变量要被多线程访问， 可以使用volatile关键字将它声明为“易变的”； 如果一个变量只要被某个线程独享， Java中就没有类似C++中__declspec(thread)[7]这样的关键字去修饰， 不过我们还是可以通过java.lang.ThreadLocal类来实现线程本地存储的功能。 每一个线程的Thread对象中都有一个ThreadLocalMap对象， 这个对象存储了一组以ThreadLocal.threadLocalHashCode为键， 以本地线程变量为值的K-V值对， ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口， 每一个ThreadLocal对象都包含了一个独一无二的threadLocalHashCode值， 使用这个值就可以在线程K-V值对中找回对应的本地线程变量。
