深入理解Java虚拟机（第3版）学习笔记——线程安全与锁优化（超详细）

第13章 线程安全与锁优化

13.2 线程安全

“当多个线程同时访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那就称这个对象是线程安全的。”

定义：当多个线程无论以何种方式去访问某对象时，这个对象始终都保持正确的行为，那么称这个对象就是线程安全的。

竞态条件：由于不恰当的执行顺序而导致了不正确的结果。

13.2.1 Java语言中的线程安全

按照线程安全的“安全程度”可分为五类：

• 不可变
• 绝对线程安全
• 相对线程安全
• 线程兼容
• 线程对立

1. 不可变

final修饰不可变的基本数据类型一定是线程安全的，final修饰不可变的对象不一定是线程安全的：

• 如果多线程共享的是基本数据，那么只要这个变量被定义为final，那么就可以保证它一定是线程安全的

• 如果共享数据是对象，那么需要对象自行保证其行为不会对其状态产生任何影响，才可以确保这个对象一定是线程安全的

  例如我们定义：

  final Person person = new Person(19,zky)；
  

  假如线程A获取了person对象，得到了person的信息并想要去打印person的信息。

  但在打印之前线程B也去获取了person，并且修改了person的值。可能就会导致最终线程A打印的结果并不是线程B修改的结果。

  通过final关键字的规则：我们可以知道它只是对于对象的引用不可变，而对象的属性值是可以被多个线程修改的，所以也有可能造成线程不安全。

2.绝对线程安全

不管运行时环境如何，调用者都不需要任何额外的同步措施

常见的Java API中标注自己是线程安全的类，大多数都不是绝对的线程安全。

代码清单13-2 对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() {
        	@Override
            public void run() {
                for (int i = 0; i < vector.size(); i++) {
                    vector.remove(i);
                }
            }
        });
        Thread printThread = new Thread(new Runnable() {
        	@Override
            public void run() {
                for (int i = 0; i < vector.size(); i++) {
                    System.out.println((vector.get(i)));
                }
            }
        });
        removeThread.start();
        printThread.start();
        //不要同时产生过多的线程，否则会导致操作系统假死
        while (Thread.activeCount() > 20);
    }
}

现象：如果另一个线程恰 好在错误的时间里删除了一个元素，导致序号i已经不再可用，再用i访问数组就会抛出一个 ArrayIndexOutOfBoundsException异常。

代码清单13-3 必须加入同步保证Vector访问的线程安全性

Thread removeThread = new Thread(new Runnable() {
@Override
    public void run() {
        synchronized (vector) {
            for (int i = 0; i < vector.size(); i++) {
            vector.remove(i);
            }
        }
    }
});
Thread printThread = new Thread(new Runnable() {
   @Override
   public void run() {
        synchronized (vector) {
            for (int i = 0; i < vector.size(); i++) {
            System.out.println((vector.get(i)));
            }
        }
    }
});

3.相对线程安全

相对线程安全：相对线程安全就是我们通常意义上所讲的线程安全，它需要保证对这个对象单次的操作是线程安全的，我们在调用的时候不需要进行额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。

在Java语言中，大部分声称线程安全的类都属于这种类型，例如Vector、HashTable、Collections的 synchronizedCollection()方法包装的集合等。

4.线程兼容

线程兼容：线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用。

Java类库API中大部分的类都是线程兼容的，如与前面的Vector和HashTable相对应的集合类ArrayList和 HashMap等。

5.线程对立

线程对立：线程对立是指不管调用端是否采取了同步措施，都无法在多线程环境中并发使用代码。

例如：是Thread类的suspend()和resume()方法

• 当suspend()和resume()方法操作的线程是使用用一个对象作为锁时：当在suspend()方法先与resume()方法执行时，挂起的线程并不会释放锁，所以会导致resume()方法尝试获取锁失败，会一直阻塞。

13.2.2 线程安全的实现方法

1.互斥同步

同步：同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一条（或者是一些， 当使用信号量的时候）线程使用。

常见的互斥同步：临界区（Critical Section）、互斥量 （Mutex）和信号量（Semaphore）

synchronized关键字锁定同步块：

• synchronized关键字经过Javac编译之后，会在同步块的前后分别形成 monitorenter和monitorexit这两个字节码指令

• 两个字节码指令都需要一个reference类型的参数来指明要锁定和解锁的对象（会对对象的mark word进行操作，后面会详细描述）

  • 如果Java源码中的synchronized明确指定了对象参数：那就以这个对象的引用作为reference；
  • 如果没有明确指定，那将根据synchronized修饰的方法类型（如实例方法或类方法），来决定是取代码所在的对象实例还是取类型对应的Class对象来作为线程要持有的锁。

• 在执行monitorenter指令时，首先要去尝试获取对象的锁。

  • 如果这个对象没被锁定，或者当前线程已经持有了那个对象的锁，就把锁的计数器的值增加一

    而在执行monitorexit指令时会将锁计数器的值减一。一旦计数器的值为零，锁随即就被释放了。（决定了synchronized是可重入锁）

  • 如果获取对象锁失败，那当前线程就应当被阻塞等待，直到请求锁定的对象被持有它的线程释放为止。

两个关于synchronized的直接推论

• 被synchronized修饰的同步块对同一条线程来说是可重入的
• 被synchronized修饰的同步块在持有锁的线程执行完毕并释放锁之前，会无条件地阻塞后面其他线程的进入

java.util.concurrent.locks.Lock接口是Java的另一种全新的互斥同步手段：

基于Lock接口，用户能够以非块结构（Non-Block Structured）来实现互斥同步，从而摆脱了语言特性的束缚，改为在类库层面去实现同步

ReentrantLock（可重入锁）是Lock接口最常见的一种实现。

ReentrantLock与synchronized相比增加了一些高级功能，主要有以下三项：

• 等待可中断：当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情。
• 公平锁：是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平锁则不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。
• 锁绑定多个条件：一个ReentrantLock对象可以同时绑定多个Condition对象。synchronized只能通过锁对象去实现线程的切换。

ReentrantLock是API层面的同步，增大了我们的可操作性。

JDK5以及之前，多线程环境下synchronized的吞吐量下降得非常严重。JDK6之后对synchronized做出了很大的优化，效率几乎与ReentrantLock相同。

synchronized相于ReentrantLock的优点：

• synchronized是在Java语法层面的同步，足够清晰，也足够简单。每个Java程序员都熟悉 synchronized，但J.U.C中的Lock接口则并非如此。因此在只需要基础的同步功能时，更推荐 synchronized。
• Lock应该确保在finally块中释放锁，否则一旦受同步保护的代码块中抛出异常，则有可能永远不会释放持有的锁。这一点必须由程序员自己来保证，而使用synchronized的话则可以由Java虚拟机来确保即使出现异常，锁也能被自动释放。
• 从长远来看，Java虚拟机更容易针对synchronized来进行优化，因为Java虚拟机可以在线程和对象元数据中记录synchronized中锁的相关信息，而使用J.U.C中的Lock的话，Java虚拟机是很难得知具体哪些锁对象是由特定线程锁持有的。

2.非阻塞同步

悲观锁：总是认为只要不去做正确的同步措施（例如加锁），那就肯定会出现问题，无论共享的数据是否真的会出现竞争，它都会进行加锁。这将会导致用户态到核心态转换、维护锁计数器和检查是否有被阻塞的线程需要被唤醒等开销

CAS乐观锁策略：

• 基于冲突检测的乐观并发策略，通俗地说就是不管风险，先进行操作，如果没有其他线程争用共享数据，那操作就直接成功了；
• 如果共享的数据的确被争用，产生了冲突，那再进行其他的补偿措施，最常用的补偿措施是不断地重试，直到出现没有竞争的共享数据为止。

CAS指令：

• CAS指令需要有三个操作数，分别是内存位置（在Java中可以简单地理解为变量的内存地址，用V表示）、旧的预期值（用A表示）和准备设置的新值（用B表示）。
• CAS指令执行时，当且仅当V符合A时，处理器才会用B更新V的值，否则它就不执行更新。但是，不管是否更新了V的值，都会返回V的旧值，上述的处理过程通过调用处理器指令（Compare-and-Swap）来保证一个原子操作，执行期间不会被其他线程中断。

常用的原子性指令：

• 测试并设置（Test-and-Set）；
• 获取并增加（Fetch-and-Increment）；
• 交换（Swap）；
• 比较并交换（Compare-and-Swap，下文称CAS）；
• 加载链接/条件储存（Load-Linked/Store-Conditional，下文称LL/SC）。

JDK5之后，Java中才引入了CAS操作。该操作由sun.misc.Unsafe类里面的 compareAndSwapInt()和compareAndSwapLong()等几个方法包装提供。

• HotSpot虚拟机在内部对这些方法做了特殊处理，即时编译出来的结果就是一条平台相关的处理器CAS指令

• Unsafe类只能够通过启动类加载器去加载后，才能使用（可通过反射去获取）。

  直到JDK 9之后，Java类库才在VarHandle类里开放了面向用户程序使用的CAS操作。

  因此在JDK 9之前只有Java类库可以使用CAS，譬如J.U.C包里面的整数原子类：中的 compareAndSet()和getAndIncrement()等方法都使用了Unsafe类的CAS操作来实现。

代码清单13-5 AtomicInteger的incrementAndGet()方法的JDK源码

/**
* Atomically increment by one the current value.
* @return the updated value
*/
public final int incrementAndGet() {
    for (;;) {
        int current = get();
        int next = current + 1;
        if (compareAndSet(current, next))
            return next;
    }
}

CAS会造成ABA问题：J.U.C包为了解决这个问题，提供了一个带有 标记的原子引用类AtomicStampedReference，它可以通过控制变量值的版本来保证CAS的正确性。

3.无同步方案

有一些代码天生是线程安全的，不需要进行额外的同步操作

可重入代码

可重入代码（纯代码）：是指可以在代码执行的任何时刻中断它，转而去执行另外一段代码（包括递归调用它本身），而在控制权返回后，原来的程序不会出现任何错误，也不会对结果有所影响。

• 特征：不依赖全局变量、存储在堆上的数据和公用的系统资源， 用到的状态量都由参数中传入，不调用非可重入的方法等。
• 判断方法：如果一个方法的返回结果是可以预测的，只要输入了相同的数据，就都能返回相同的结果。

线程本地存储

线程本地存储（Thread Local Storage）：我们可以把共享数据的可见范围限制在同一个线程之内，这样，无须同步也能保证线程之间不出现数据争用的问题。（代替Session存放用户信息）

可以通过java.lang.ThreadLocal类来实现线程本地存储的功能

• 每一个线程的Thread对象中都有一个ThreadLocalMap对象，这个对象存储了一组以ThreadLocal.threadLocalHashCode为键，以本地线程变量为值的K-V值对，ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口，每一个 ThreadLocal对象都包含了一个独一无二的threadLocalHashCode值，使用这个值就可以在线程K-V值对 中找回对应的本地线程变量。

13.3 锁优化

JDK6之前，Synchornized关键字实现的同步是直接利用重量级锁

JDK6之后，对Synchornized关键字做出了优化

Synchornized具有无锁 -> 偏向锁 -> 轻量级锁(自旋锁、自适应自旋锁) -> 重量级锁的优化过程

13.3.1 自旋锁与自适应自旋

自旋锁：如果物理机器有一个以上的处理器或者处理器核心，能让两个或以上的线程同时并行执行，我们就可以让后面请求锁的那个线程“稍等一会”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只须让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。

JDK 6中默认开启

自旋锁的缺点：

• 如果锁被占用的时间很长，那么自旋的线程只会白白消耗处理器资源，而不会做任何有价值的工作，这就会带来性能的浪费。

解决方案：在 JDK 6中对自旋锁的优化，引入了自适应的自旋。

• 自适应自旋：自旋的时间不再是固定的了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定的。

  如果对于同一个锁对象，自旋等待刚刚成功获得过锁。那么虚拟机会将自旋次数设置为更大。如果通过自旋很少获得锁，那么会减少自旋次数甚至不开启自旋以避免浪费处理器资源。

13.3.2 锁消除

锁消除是指虚拟机==即时编译器==在运行时，对一些代码要求同步，但是对被检测到不可能存在共享数据竞争的锁进行消除。（属于后端编译优化）

锁消除的主要判定依据来源于逃逸分析的数据支持

• 如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那么这个变量的读写肯定就不会有竞争， 对这个变量实施的同步措施也就可以安全地消除掉。

13.3.3 锁粗化

问题：如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体之中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。

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()方法内部==，其他线程无法访问到它，所以这里虽然有锁，但是可以被安全地消除掉。

虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部

• 以上述代码为例：就是扩展到第一个append()操作之前直至最后一个append()操作之后，这样只需要加锁一次就可以了

13.3.4 轻量级锁

重量级锁：在传统的锁机制中，每次发生线程切换时，需要从用户态切换到核心态，然后发出中断处理并作出保护现场、恢复现场的一些操作，代价及其昂贵，因此传统的使用操作系统互斥量来实现的锁机制被称为”重量级锁“

HotSpot虚拟机的对象头的内存布局

• 存储自身的运行时数据：哈希码（HashCode）、GC分代年龄（Generational GC Age） 、锁标志相关信息等。

  这部分就为我们后面常说的Mark Word

• 另外一部分用于存储指向方法区对象类型数据的指针，如果是数组对象，还会有一个额外的部分用于存储数组长度。

轻量级锁的工作流程：

• 在代码即将进入同步块的时候，如果此同步对象没有被锁定（锁标志位为“01”状态），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，存储锁对象目前的Mark Word的拷贝（官方为这份拷贝加了一个Displaced前缀，即Displaced Mark Word）

  

• 然后，虚拟机将使用CAS操作尝试把对象的Mark Word更新为指向Lock Record的指针

  • 更新成功：如果这个更新动作成功了，即代表该线程拥有了这个对象的锁，并且对象Mark Word的锁标志位（Mark Word的最后两个比特）将转变为“00”，表示此对象处于轻量级锁定状态。这时候线程堆栈与对象头的状态如下图所示

  

  • 更新失败：如果这个更新操作失败了，那就意味着至少存在一条线程与当前线程竞争获取该对象的锁。
    • 当前线程重复进入：虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是，说明当前线程已经拥有了这个对象的锁，那直接进入同步块继续执行就可以了
    • 其它线程抢占：对象的Mark Word已经被修改，此时轻量级锁就不再有效，必须要膨胀为重量级锁，锁标志的状态值变为“10”，此时Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也必须进入阻塞状态

• 解锁过程同样通过CAS来实现：如果对象的Mark Word仍然指向线程的锁记录，那就用CAS操作把对象当前的Mark Word和线程中复制的Displaced Mark Word替换回来。

  • 假如能够成功替换，那整个同步过程就顺利完成了
  • 如果替换失败，则说明有其他线程尝试过获取该锁，就要在释放锁的同时，唤醒被挂起的线程。

13.3.5 偏向锁

偏向锁也是JDK 6中引入的一项锁优化措施，它的目的是==消除数据在无竞争情况下的同步原语， 进一步提高程序的运行性能。==默认开启

偏向锁的定义：这个锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁一直没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。

偏向锁工作原理

• 当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设置为“01”、把偏向模式设置为“1”，表示进入偏向模式。同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中。

  如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如加锁、解锁及对Mark Word的更新操作等）。

• 一旦出现另外一个线程去尝试获取这个锁的情况，偏向模式就马上宣告结束，等待全局安全点，开始撤销偏向锁，根据锁对象目前是否处于被锁定的状态发生以下两种情况：

  • 撤销偏向锁后标志位恢复到未锁定
  • 变为轻量级锁定（标志位为“00”）的状态

  

• 后续的同步操作就按照上面介绍的轻量级锁那样去执行。

当锁进入偏向状态时，存储hash码的位置被覆盖了，那对象的hash码存储到哪儿的？

关于hash：在Java语言里面一个对象如果计算过哈希码，就应该一直保持该值不变，否则很多依赖对象哈希码的API都可能存在出错风险。绝大多数对象哈希码来源的Object::hashCode()方法，返回的是对象的一致性哈希码。

如何保持hash码一致不变？

它通过在对象头中存储计算结果来保证第一 次计算之后，再次调用该方法取到的哈希码值永远不会再发生改变。

因此，由于偏向锁的产生需要利用存储hash码的位置，所以当一个对象计算过hash码后会造成下面两种情况：

• 当一个对象已经计算过一致性哈希码后，它就再也无法进入偏向锁状态了

• 当一个对象当前正处于偏向锁状态，又收到需要计算其一致性哈希码请求时，它的偏向状态会被立即撤销，并且锁会膨胀为重量级锁

  这里说的计算请求应来自于对**Object::hashCode()或者System::identityHashCode(Object)方法的 调用，如果重写了对象的hashCode()**方法，计算哈希码时并不会产生这里所说的请求

在重量级锁的实现中，对象头指向了重量级锁的位置，代表重量级锁的ObjectMonitor类里有字段可以记录非加锁状态（标志位为“01”）下的Mark Word，其中自然可以存储原来的哈希码。

偏向锁可以提高带有同步但无竞争的程序性能。但如果程序中大多数的锁都总是被多个不同的线程访问，那偏向模式就是多余的。

13.3. 重量级锁

可以先看看moniter的实现原理，有助于帮助理解

Moniter的实现原理

Java精通并发-通过openjdk源码分析ObjectMonitor底层实现 - cexo - 博客园 (cnblogs.com)

使用了monitor的对象的就是重量级锁，因为==monitor的实现依赖于底层操作系统的mutex互斥原语==，而操作系统实现线程之间的切换的时候需要从用户态转到内核态，这个转成过程开销比较大。所以下面两种方式就是重量级锁

• 同步方法的时候

  Jvm采用的是 ACC_synchoronized 标记符来实现的同步，这个是因为jvm在调用方法时会验证方法是不是有ACC_synchoronized 的标记符。如果设置了该标志，执行线程会线获取到monitor对象，然后执行方法，在该方法的运行期间，其他线程是无法获取到monitor对象的，只有当拥有monitor对象的线程执行完任务了才能获取，释放了monitor对象才能进入到代码块。

• 同步代码块的时候

  对于同步代码块，是由 monitorenter和monitorexit指令来实现的同步。monitorenter是获取monitor的所有权，mointorexit是释放monitor的所有权。

  monitorenter的执行原理

  • 获取到monitor的所有权，进入数+1
  • 如果该线程已经拥有了此次方法的monitor，又重新进入到monitor。进入数 +1 这个就是锁的重入
  • 其他线程进入到阻塞状态，直到monitor的进入数为0 时，才会重新获取到monitor的所有权
    monitorexit 则表示该线程必须释放montor的所有权。并把进入数减去1 直到为0 线程退出monitor。

13.4 各种锁的优缺点以及使用场景

锁	优点	缺点	适用场景
偏向锁	加锁和解锁不需要额外的消耗，和非同步块只有纳秒级别的差距	如果存在线程竞争，回带来额外的锁撤销消耗	使用于一个线程访问同步块
轻量级锁	竞争的线程不会阻塞，提高来线程的响应速度	如果始终得不到锁竞争的线程，是使用自旋消耗CPU	追求响应 同步块执行速度非常快
重量级锁	线程竞争不使用自旋，不会消耗CPU	线程阻塞，响应时间缓慢	追求吞吐量，同步块执行速度较长

一张图读懂synchornized锁膨胀的过程