Android---java线程优化 偏向锁、轻量级锁和重量级锁

java 中的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统的帮忙，这就需要从用户态转换到核心态。状态转换需要花费很多时间，如下代码所示：

private Object lock = new Object();

private int value;

public void setValue(){
    synchronized(this){
        value++;
    }
}

value++ 被关键字 synchronized 修饰，所以会在各个线程间同步执行。但是，value++执行的时间很有可能比线程转换所消耗的时间还短。所以 synchronized 是 java 中的一个重量级操作。

synchronized 实现原理

对象头

Java 对象在内存中的布局分为 3 个部分：对象头、实例数据、对齐填充。在 Java 代码中，使用 new 创建一个对象时，JVM 会在堆中创建一个 instanceOopDesc 对象，这个对象中包含了对象头以及实例数据。instanceOopDesc 的基类为 oopDesc 类

class oopDesc{
    friend class VMStructs;
    private:
        volatile markOop _mark;
        union _metadata{
            wideKlassOop _ klass;
            narrowOop _compressed_klass;
        } _metadata;
}

其中 _mark 和 _metadata 一起组成了对象头。其中，_mark 是 markOop 类型数据，一般称它为标记字段（Mark Word)，其中主要存储了对象的 hashCode、分代年龄、锁标志位、是否偏向锁等。如下图所示，32位 Java 虚拟机的 Mark Word 的默认存储结构。

默认情况下，没有线程进行加锁操作，所以锁对象中的 mark word 处于无锁状态。但是，考虑到 JVM 的空间效率，mark word 被设定为一个非固定的数据结构，以便存储更多的有效数据。他会根据对象本身的状态复用自己的存储空间。如，32 位 JVM 下，处了上述 mark word 列出的默认存储结构外，还有如下可能变化的结构

从图中可以看出，根据锁标志位以及是否为偏向锁，Java 中的锁可以分为以下几种状态：

在 Java6之前没有偏向锁和轻量级锁，只有重量级锁，也就是通常所说的 synchronized 对象锁。从图中可以看出，当锁为重量级锁时，对象头中的 mark word 会用 30 个 bit 来指向一个互斥量，而这个互斥量就是 monitor。

Monitor

Monitor 是一个保存在对像头中的一个对象。可以把 Monitor 理解为一个同步工具或者一种同步机制。在 markOop 中有如下代码

通过 Monitor 方法创建一个 Obj 对象，而 ObjectMonitor 就是 Java 虚拟中的 Monitor 的具体实现。因此 Java 中每个对象都有一个对应 ObjectMonitor 对象。这也是 Java 中所有 Object 对象都可以作为锁的原因。

ObjectMonitor 是如何实现同步机制的呢？

首先看一下 ObjectMonitor 的结构。

其中，几个比较关键的属性如下

当多个线程同时访问一段代码时，首先会进入 _EntryList 队列中，当某个线程通过竞争获取到对象的 monitor 后，monitor 会把 _owner 变量设置为当前线程。同时 monitor 中的计数器 _count 加 1， 即获得对象锁。

若持有 monitor 的线程调用 wait() 方法，将释放当前持有的 monitor，_owner 变量恢复为 null，_count 自减1，同时该线程进入 _WaitSet 集合中等待被唤醒。若当前线程执行完毕也将释放 monitor（锁）并复位变量值，以便其它线程进入获取 monitor （锁）。

ObjectMonitor 的同步机制是 JVM 对操作系统级别的 Mutex Lock(互斥锁)的管理过程，其间都会转入操作系统内核态。synchronized 实现锁，在“重量级”状态下，当多个线程之间切换上下文时，是一个比较重量级的操作。

Java 虚拟机对 synchronized 的优化

从 java 6开始，虚拟机对 synchronized 关键字做了多方面的优化。主要目的：避免 ObjectMonitor 的访问，减少 “重量级锁”的使用次数，并最终减少线程上下文切换的频率。其中主要做了以下几个优化：1）锁自旋；2）轻量级锁；3）偏向锁。

锁自旋

线程的阻塞和唤醒需要 CPU 从用户态转为核心态，频繁的阻塞和唤醒对 CPU 来说是一件负担很重的工作，所以 java 引入自旋锁。自旋锁在 Java 1.4 被引入，默认关闭，可以使用参数 -XX:+UseSpinning 将其开启，从 Java 6 之后默认开启。

自旋：是让该线程等待一段时间，不会被立即挂起，看当前持有锁的线程是否会很快释放锁，而所谓的等待就是执行一段无意义的循环即可（自旋）。

自旋锁的缺陷：自旋要占用 CPU。如果锁竞争的时间比较长，那么自旋通常不能获得锁，白白浪费了自旋占用的 CPU 时间。这通常发生在锁持有时间长，且竞争激烈的场景中，此时应主动禁用自旋锁。

轻量级锁

Java 虚拟机中会存在这两种情形：对于一块同步代码，虽然有多个不同线程会去执行，但是这些线程是在不同的时间段交替请求这把锁对象，不存在锁竞争的情况。在这种情况下，锁会保持在轻量级锁的状态，从而避免重量级锁的阻塞和唤醒操作 。

要了解轻量级锁的工作流程，需要再次看下对象头中的 Mark Word。当线程执行某同步代码时，JVM 虚拟机会在当前线程的栈帧中开辟一块空间作为该锁的记录，如下图所示：

然后 Java 虚拟机会尝试使用 CS  操作将锁对象的 mark word 拷贝到这块空间，并且将所记录中的 owner 指向 mark word，如下图所示

 当线程再次执行同步代码块时，判断当前对象的 Mark Word 是否指向当前线程的栈帧。如果是则表示当前线程已经持有当前对象的锁，则直接执行同步代码块；否则只能说明该锁对象已经被其他线程抢占了，这时轻量级锁需要膨胀为重量级锁。轻量级锁适应的场景是线程交替执行同步块的场合，如果存在同一时间访问同一锁的场合，就会导致轻量级锁膨胀为重量级锁。

偏向锁

在一些情况下，锁总是由同一个线程获得，因此为了让锁获得的代价更低，引入了偏向锁。

偏向锁是如果一个线程获得了一个偏向锁，如果在接下来的一段时间中没有其他线程来竞争锁，那么持有偏向锁的线程再次进入或者退出同一个同步代码块，不需要再次进行抢占锁和释放锁的操作。偏向锁可以通过 -XX:+UseBiasedLocking 开启或者关闭。

偏向锁的具体实现

在锁对象的对象头中有个 ThreadId 字段，默认情况下这个字段是空的。当第一次获取锁的时候，将自身的 ThreadId 写入锁对象的 Mark word 中的 ThreadId 字段内，将是否偏向锁的状态设置为 01，下次获取锁的时候，直接检测 ThreadId 是否和自身线程 Id 一致。如果一致，则认为当前线程已经获取了锁，因此不需要再次获取锁。略过了轻量级锁和重量级锁的加锁阶段，提高了效率。

偏向锁并不适合所有应用场景。一旦出现锁竞争，偏向锁会被撤销（revoke），并膨胀为轻量级锁，而撤销操作是比较重的行为。只有当存在较多不会 真正竞争的 synchronized 块时，才能体现出明显的改善。在实践中，需要考虑具体业务场景，并测试，再次决定是否开启/关闭偏向锁。

总结

本次主要介绍了Java中锁的几种状态
● 偏向锁和轻量级锁是通过自旋等技术避免真正的加锁；

● 重量级锁是获取锁和释放锁；

● 重量级锁通过对象内部的监视器(ObjectMonitor) 实现，其本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的切换，成本非常高。