JUC–synchronized优化原理

背景

• JUC–synchronized优化原理

• 博主以黑马JUC进行学习

• 对象头Mark Word

  锁状态	最后 3 位	存储内容
  无锁	001	hashcode、分代年龄
  偏向锁	101	线程 ID、epoch、分代年龄
  轻量级锁	00	锁记录地址 (Lock Record)
  重量级锁	10	Monitor 地址

  • 无锁 → 偏向锁 → 轻量级锁 → 重量级锁

  轻量级锁

  • 轻量级锁的使用场景：如果一个对象虽然有很多线程访问，但多线程访问的时间是错开的，那么可以使用轻量级锁来优化。

  • 轻量级锁对使用者是透明的，即语法仍然是synchronized

  • 假设有两个方法同步块，利用同一个对象加锁

    static final Object obj = new Object();
    public static void method1(){
        synchronized(obj){
            method2();
        }
    }
    public static void method2(){
        synchronized(obj){
            
        }
    }

    • 创建锁记录（Lock Record）对象，每个线程都的栈帧都会包含一个锁记录的结构，内部可以存储锁定对象的Mark Word
      • 对象结构：
        • Hashcode Age Bias 01
        • Klass Word
        • Object body
      • Thread：
        • Lock Record
          • lock record 地址 00 //00即轻量级锁
          • Object reference
    • 让锁记录中Object reference 指向锁对象，并尝试用cas替换Object的Mark Word，将Mark Word的值存入锁记录
    • 如果cas替换成功，对象头中存储了锁记录地址和状态00，表示由该线程给对象加锁
      • 对象结构：
        • lock record 地址 00 //交换
        • Object body
      • Thread：
        • Lock Record
          • Hashcode Age Bias 01 //交换
          • Object reference
    • 如果cas失败，有两种情况
      • 如果是其它线程已经有了该Object的轻量级锁，这时表明有竞争，进入锁膨胀过程
      • 如果是自己执行了synchronized锁重入，那么再添加一条Lock Record作为重入的计数
      • 当退出synchronized代码块（解锁时）如果有取值为null的锁记录，表示有重入，这时重置锁记录，表示重入计数减一
      • 当退出synchronized代码块（解锁时）锁记录的值不为null，这时使用cas将Mark Word的值恢复给对象
        • 成功，则解锁成功
        • 失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程

  锁膨胀

  • 如果在尝试加轻量级锁的过程中，cas操作无法成功，这时一种情况就是有其它线程为此对象加上了轻量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁

    static Object obj = new Object();
    public static void method(){
        synchronized(obj){
            
        }
    }

    • 当Thread-1进行轻量级加锁时，Thread-0已经对该对象加了轻量级锁
    • 这时Thread-1加轻量级锁失败，进入锁膨胀流程
      • 即为Object对象申请Monitor锁，让Object指向重量级锁地址
      • 然后自己进入Monitor的EntryList BLOCKED
    • 当Thread-0 退出同步块解锁时，使用cas将Mark Word 的值恢复给对象头，失败。这时会进入重量级锁解锁流程，即按照Monitor地址找到Monitor对象，设置Owner为null，唤醒EntryList中的BLOCKED线程

  自旋优化

  • 重量级锁竞争的时候，还可以使用自旋来优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞
  • 适合多核cpu，单核cpu不适合
  • 在java6之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至是不自旋，总之，比较智能。
    • 上次自旋成功 → 多自旋几次
    • 上次失败 → 少自旋 / 不自旋
  • 自旋会占用CPU时间，单核CPU自旋就是浪费，多核CPU自旋才能发挥优势
  • Java7之后不能控制是否开启自旋功能

  偏向锁

  • 轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行CAS操作。
  • Java 6 中引入了偏向锁来做进一步优化：只有第一次使用CAS将线程ID设置到对象的Mark Word头，之后就发现这个线程ID是自己的就表示没有竞争，不用重新CAS。以后只要不发生竞争，这个对象就归线程所有

  static final Object obj = new Object();
  public static void m1(){
      synchronized(obj){	
          m2();
      }
  }
  public static void m2(){
      synchronized(obj){
          m3();
      }
  }
  public static void m3(){
      synchronized(obj){
          	
      }
  }

  偏向状态

  • 一个对象创建时：
    • 如果开启了偏向锁（默认开启），那么对象创建后，markword值为0x05即最后3位为101，在时它的thread、epoch、age都为0
    • 偏向锁是默认是延迟的，不会再程序启动时立即生效，如果想避免延迟，可以加VM参数 -XX:BiasedLockingStartupDelay=0来禁用延迟
    • 如果没有开启偏向锁，那么对象创建后，markword值为0x01即最后3位001，这时它的 hashcode、age都为0，第一次用到hashcode时才会赋值
    • 使用jol第三方工具来查看对象头信息
    • 测试禁用：在测试代码运行时，添加VM参数：-XX:-UseBiasedLocking禁用偏向锁

  撤销-调用对象hashCode

  • 调用了对象的hashCode，但偏向锁的对象MarkWord中存储的是线程id，如果调用hashCode会导致偏向锁被撤销
    • 轻量级锁会在锁记录中记录hashCode
    • 重量级锁会在Monitor中记录hashCode
  • 在调用hashCode后使用偏向锁，记得去掉-XX:-UseBiasedLocking

  撤销-其它线程使用对象

  • 当有其它线程使用偏向锁对象时，就会偏向锁升级为轻量级锁

  撤销-调用wait/notify

  批重量偏向

  • 如果对象虽然被多个线程访问，但没有竞争，这时偏向了T1的对象仍有机会重新偏向T2，重偏向会重置对象的Thread ID
  • 当撤销偏向锁阈值超过20次后，jvm会这样觉得，我是不是偏向错了呢，于是会给这些对象加锁时重新偏向至加锁状态

  批量撤销

  • 当撤销偏向锁阈值超过40次后，jvm会这样觉得，自己确实偏向错了，根本就不该偏向。于是整个类的所有对象都会变为不可偏向的，新建的对象也是不可偏向的

  锁消除

  • JIT 即时编译器
    • 对于不可共享的代码，JIT会将其锁优化掉
  • 开启（默认）：-XX:+EliminateLocks
  • 关闭：-XX:-EliminateLocks

  总结

  优化手段	解决问题	原理
  偏向锁	单线程反复加锁	只一次 CAS，后续直接用
  轻量级锁	多线程交替访问	CAS + 锁记录，无阻塞
  锁膨胀	真正并发竞争	升级为 Monitor 重量锁
  自旋优化	重量锁竞争	循环重试，避免阻塞开销
  批量重偏向 / 撤销	偏向锁频繁失效	批量调整，减少撤销开销
  锁消除	无意义的锁	JIT 直接删除不可能竞争的锁