【有书共读】《深入理解java虚拟机》读书笔记052
第五部分：高效并发
§2 - 线程安全与锁优化
Author：Sirice
线程安全
当多个线程访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方法进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那么这个对象是线程安全的。
Java语言中的线程安全
这里讨论的线程安全，就限定于多个线程之间存在共享数据访问的这个前提。
按照线程安全的“安全程度”由强到弱排序，可以把Java中各个操作共享的数据分为以下5类：
- 不可变
不可变（Immutable）的对象一定是线程安全的。
如果共享数据是一个基本数据类型，定义时使用final关键字修饰可保证它不可变。
如果共享数据是一个对象，那就需要保证对象的行为不会对其状态产生任何影响才行。其中最简单的是把对象中带有状态的变量都声明为final，这样在构造函数结束后，它就是不可变的。
Java API中符合不可变要求的类型：java.lang.String/java.lang.Number部分子类等。
- 绝对线程安全
绝对线程安全满足线程安全的定义。Java API中标注自己是线程安全的类，大多数时候都不是绝对的线程安全。
package com.jvm.thread;
import java.util.Vector;
public class VectorTest {
private static Vector<Integer> vector = new Vector<>();
public static void main(String[] args) throws InterruptedException {
while (true) {
for(int i = 0; i < 10; i++){
vector.add(i);
}
Thread removeThread = new Thread(new Runnable() {
public void run() {
for(int i = 0; i < vector.size(); i++){
vector.remove(i);
}
}
});
Thread printThread = new Thread(new Runnable() {
public void run() {
for(int i = 0; i < vector.size(); i++){
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println(vector.get(i));
}
}
});
removeThread.start();
printThread.start();
}
}
} 运行将发生java.lang.ArrayIndexOutOfBoundsException异常。尽管Vector的get()/remove()和size()方法都是同步的，但是在多线程环境中，如果不在方法调用端做额外的同步措施，使用这段代码仍然是不安全的。
package com.jvm.thread;
import java.util.Vector;
/**
* 加入同步以保证Vector访问的线程安全
* @author xl69628
*
*/
public class VectorTest {
private static Vector<Integer> vector = new Vector<>();
public static void main(String[] args) throws InterruptedException {
while (true) {
for(int i = 0; i < 10; i++){
vector.add(i);
}
Thread removeThread = new Thread(new Runnable() {
public void run() {
synchronized (vector) {
for(int i = 0; i < vector.size(); i++){
vector.remove(i);
}
}
}
});
Thread printThread = new Thread(new Runnable() {
public void run() {
synchronized (vector) {
for(int i = 0; i < vector.size(); i++){
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(vector.get(i));
}
}
}
});
removeThread.start();
printThread.start();
}
}
} -
相对线程安全
相对线程安全就是我们通常意义上所讲的线程安全，它需要保证对这个对象单独的操作时线程安全的，我们在调用时不需要做额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确定。
Java中，大部分线程安全类都属于这种类型，Vector/HashTable/Collections的synchronizedCollection()方法包装的集合等。
-
线程兼容
线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中安全使用。Java API中大部分类都是线程兼容的。
-
线程对立
是指不管调用端是否采取了同步措施，都无法在多线程环境中并发使用的代码。通常是有害的，应当尽量避免。
一个线程对立的例子是Thread类的suspend()和resume()方法，如果两个线程同时持有一个线程对象，一个尝试去中断线程，另一个尝试去恢复线程，如果并发进行的话，无论调用是否进行了同步，目标线程都是存在死锁风险的，如果suspend()中断的线程就是即将要执行resume()的那个线程，那就肯定要产生死锁了。正是因为此原因，此两方法已被JDK废弃了。
线程安全的实现方法
代码编写如何实现线程安全和虚拟机如何实现同步与锁这两者都会涉及。
- 互斥同步
互斥同步（Mutual Exclusion & Synchronization）是常见的一种并发正确性保障手段。同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一个（或者是一些，使用信号量的时候）线程使用。而互斥是实现同步的一种手段，临界区（Critical Section）、互斥量（MuTex）和信号量（Semaphore）都是主要的互斥实现方式。因此，在这四个字里面，互斥是因，同步是果；互斥是方法，同步是目的。
在Java中，最基本的互斥同步手段是synchronized关键字，synchronized关键字经过编译后，会在同步代码块的前后分别形成monitorenter和monitorexit这两个字节码指令，这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象。如果程序中synchronized指明了对象参数，那就是这个对象的reference；如果没有指明，那就根据synchronized修饰的是实例方法还是类方法，去取对应的对象实例或Class对象来作为锁对象。
虚拟机规范要求，在执行monitorenter指令时，首先尝试获取对象的锁。如果对象没有被锁定或者当前线程已经拥有了那么对象的锁，把锁的计数器加1，执行monitorexit时，将锁计数减1，当锁计数器为0时，锁被释放。如果获取对象锁失败，当前线程将阻塞等待。
虚拟机对monitorenter和monitorexit行为描述中，注意两点：synchronized同步块对同一条线程来说是可重入的，不会出现自己把自己锁死的问题；同步块在已进入线程执行完之前，会阻塞后面其他线程的进入。
还可以使用java.util.concurrent（以下称JUC）包中的重入锁（ReentrantLock）来实现同步。相比synchronized，ReentrantLock增加了一些高级功能，主要以下3项：等待可中断、可实现公平锁，以及锁可以绑定多个条件。
等待可中断：当持有的锁的线程长期不释放锁时，正在等待的线程可以选择放弃等待，改为处理其他事情，对处理执行时间长的同步块很有帮助。
公平锁：多个线程等待同一锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平锁不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized中的锁是非公平的，ReentrantLock默认也是非公平，但可以通过构造函数要求使用公平锁。
绑定多个条件：一个ReentrantLock对象可以同时绑定多个Condition对象，而synchronized中，锁对象的wait()和notify()或notifyAll()可以实现一个隐含的条件，如果要和多于一个的条件关联时，就不得不额外添加一个锁，而ReentrantLock则无须这样，只要多次调用newCondition()即可。
- 非阻塞同步
互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也称为阻塞同步（Blocking Synchronized）。处理问题方式上，互斥同步属于一种悲观的并发策略，总是认为只要不去做正确的同步措施（例如加锁），那肯定会出现问题，无论共享数据是否真的出现竞争，它都要进行加锁（这里讨论的是概念模型，实际上虚拟机会优化很大一部分不必要的加锁）、用户态核心态转换、维护锁计数器和检查是否有阻塞的线程需要等待唤醒等操作。
随着硬件指令集的发展，有了另外一种选择：基于冲突检测的乐观并发策略，就是先进性操作，如果没有其他线程争用共享数据，那操作就成功了；如果共享数据有争，产生了冲突，那就再采取其他的补偿措施（最常见的补偿措施就是不断地重试，直到成功为止），这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步称为非阻塞同步（Non-Blocking Synchronization）。
我们需要操作和冲突检测这两个步骤具备原子性，只能靠硬件来完成，硬件保证一个从语义上看起来需要多次操作的行为只通过一条处理器指令就能完成，这类执行常用的有：
测试并设置（Test and Set）。
获取并增加（Fetch and Increment）。
交换（Swap）。
比较并交换（Compare and Swap，以下称CAS）。
加载链接/条件存储（Load Linked/Store Conditional，以下称LL/SC）。
- 无同步方案
要保证线程安全，并不是一定就要进行同步，两者并没有因果关系。同步只是保证共享数据争用时正确性的手段，如果一个方法本来就不涉及共享数据，自然就无须任何同步措施去保证正确定。因此会有一些代码天生就是线程安全的。两类：
可重入代码（Reentrant Code）：这种代码也叫纯代码（Pure Code），可以在代码执行的任何时刻中断它，转而去执行另外一断代码（包括递归调用它本身），而在控制权返回后，原来的程序不会出现任何错误。所有可重入代码都是线程安全的。可重入代码有一些共同特征，例如不依赖存储在堆上的数据和公用的系统资源、用到的状态量都是由参数中传入、不调用非可重入的方法等。判断代码具备可重入的简单原则：如果一个方法，它的返回结果是可以预测的，只要输入了相同的数据，就都能返回相同的结果，就满足可重入性的要求，当然也是线程安全的。
线程本地存储（Thread Local Storage）：如果一段代码中所需要的数据必须与其他代码共享，那就看这些共享数据的代码是否能保证在同一个线程中执行？如能，就把共享数据的可见性范围限制在同一个线程之内，这样，就无须同步也能保证线程之前不出现数据争用问题。
符合这种特点的应用：大部分使用消费队列的架构模式（如“生产者-消费者”模式）都会讲消费过程尽量在一个线程中消费完；经典Web交互模型中的“一个请求对应一个服务线程”（Thread-per-Request）的处理方式，这种处理方式的广泛应用使得很多Web服务端应用都可以使用线程本地存储来解决线程安全问题。
Java中，如果一个变量要被多个线程访问，可以使用volatile关键字声明它为“易变的”；如果一个变量被某个线程独享，可以通过java.lang.ThreadLocal类来实现线程本地存储的功能。每一个线程的Thread对象中都有一个ThreadLcoalMap对象，该对象存储了一组易ThreadLocal.threadLocalHashCode为键，以本地线程变量为值得K-V键值对，ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口，每一个ThreadLocal对象都包含了一个独一无二的threadLocalHashCode值，使用这个值就可以在线程K-V键值对中找回对应的本地线程变量。
锁优化
自旋锁与自适应自旋
在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得如果物理机器上有一个以上的处理器，我们可以让后面申请锁的那个线程“稍等一下”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，只需让线程执行一个忙循环（自旋），就项技术就是所谓的自旋锁。
自旋等待不能代替阻塞，且先不说对处理器量的要求，自旋等待本身虽然避免了线程切换的开销，但它要占用处理器的时间，因此，如果锁被占用的时间短，自旋等待效果好，反之，自旋的线程只会白白消耗处理器资源，而不做任何有用工作，带来性能上的浪费。因此，自旋等待的时间必须要有一定的限度，如果自旋超过了限定的次数仍然没有获得锁，就应当使用传统的方式挂起线程。自旋次数的默认值是10次，用户可以使用参数 -XX:PerBlockSpin 来修改。
JDK1.6引入了自适应的自旋锁。自旋的时间是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就认为这次自旋也很可能成功，进而它将允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功获得，在以后获得这个锁时将可能省略自旋过程，以避免浪费处理器资源。有了自适应自旋，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越准确，虚拟机就变得越来越“聪明”了。
锁消除
是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除主要判定依据来源于逃逸分析的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去，从而被其他线程访问到，那就可以把它们当做栈上数据对待，认为它们是线程私有的，同步加锁自然无须进行。
许多同步措施并不是程序员自己加入的，同步的代码在Java程序中的普遍程度也许超过我们的想象。
由于String是一个不可变类，对字符串的连接操作总是通过生成新的String对象来进行，因此Javac编译器会对String连接做自动优化。在JDK1.5前，会转换为StringBuffer对象的append()操作，在JDK1.5及以后版本，会转换为StringBuilder对象的连续append()操作。上段代码可能会变成下面的样子。
每个StringBuilder.append()中都有一个同步块，锁是sb对象。虚拟机观察变量sb，很快就会发现它的动态作用域被限制在concatString()的内部。也就是sb的所有引用永远不会“逃逸”到concatString()外，其他线程无法访问到它，所以虽然这里有锁，但是可以被安全地消除掉，在即时编译后，这段代码会忽略所有的同步而直接执行。
锁粗化
大部分情况下，我们在编写代码时，总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域才进行同步，如果存在锁竞争，那等待锁的线程也可能尽快拿到锁。
但是如果一系列的连续操作都是对同一对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。
上段代码连续的append()就属于这种情况。如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部，以上段代码为例，就是扩展到第一个append()之前直至最后一个append()之后，这样只需要加锁一次就可以了。
轻量级锁
轻量级锁是JDK1.6中加入的新型锁机制。轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统重量级锁使用操作系统互斥量产生的性能消耗。
轻量级锁提升程序性能的依据是“对于绝大多数的锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量的开销，但如果存在锁竞争，除了互斥量的开销外，还额外发生了CAS操作，因此在有竞争的情况下，轻量级锁比传统锁更慢。
偏向锁
偏向锁是JDK1.6引入的锁优化，目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。如果说轻量级锁是在无竞争的情况下使用CAS操作消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不做了。
这个锁会偏向于第一个获得它的线程，如果接下来的执行过程中，该锁没有被其他线程获取，则持有偏向锁的线程将永远不需要再进行同步。
偏向锁可以提高带有同步但无竞争的程序性能。它同样是一个带有效益权衡（Trade Off）性质的优化，它对程序运行不一定有利，如果程序中大多数的锁都总是被多个不同的线程访问，那偏向锁局势多余的。在具体问题具体分析的前提下，有时使用参数 -XX:-UseBiasedLocking 来禁止偏向锁优化反而可以提升性能。
以上为全部《深入理解JVM虚拟机》笔记，有问题欢迎反馈在nowcoder评论区或github提issue大家一起讨论。
注：前面的部分笔记例如jvm优化，jvm监控工具等笔者暂未编码实践，因此这部分笔记暂时不做，如有后续更新我将会发布在github上，关注本项目更新请在Understanding-the-JVM-reading-notes处点击watch。
最后感谢您的阅读，觉得有帮助的请点个star。
#读书笔记##笔记#