Java并发之锁

• 一、临界区
• 二、线程安全
• 三、解决临界区线程安全问题
• 四、Java对象头
• 五、重量级锁 Monitor
• • 5.1 synchronized
  • 5.1.1 synchronized加锁流程
• 六、轻量级锁
• • 6.1 轻量级锁加锁流程
  • 6.2 CAS失败的情况
  • 6.3 轻量级锁解锁流程
• 七、偏向锁（轻量级锁优化）
• 八、锁膨胀
• 九、自旋优化（重量级锁优化）
• 十、锁消除
• • 10.1 逃逸分析
• 十一、锁粗化
• 十二、锁粒度
• • 12.1 死锁
  • • 12.1.1 死锁的条件
    • 12.1.2 定位死锁
  • 12.2 活锁
  • 12.3 饥饿

一、临界区

二、线程安全

三、解决临界区线程安全问题

四、Java对象头

• Java对象在内存中都有三部分组成：对象头、对象体、对齐填充
  普通对象头：Mark Word、Class Word
  数组对象头：Mark Word、Class Word、array length
• Mark Word存储的是哈希码、分代年龄、加锁状态位
  Class Word存储的是类型指针（指针指向对象，判断对象是什么类型）
• 查看对象头：借助第三方jar包jol-core，使用ClassLayout

五、重量级锁 Monitor

5.1 synchronized

• Java中调用 synchronized（不是Java层面） 时，底层即使用Monitor加重量级锁，重量级锁属于悲观锁，即防着其他线程来修改共享变量，即上锁之后其他线程都别想修改，当前线程改完了解开锁，其他线程才有机会
• Monitor（锁）由操作系统提供，成本较高，每次执行synchronized获取Monitor锁对程序的运行性能有一定的影响，JDK6之后对synchronized获取Monitor锁的方式做了一定的改进优化（轻量级锁、偏向锁）

5.1.1 synchronized加锁流程

前提条件：synchronized必须是进入同一个对象的monitor；不加synchronized的对象不会关联monitor

• 调用synchronized给对象上锁（重量级）时，每个Java对象去关联一个Monitor对象，Java对象头的Mark Word中就被设置指向Monitor对象的指针
• 刚开始Monitor中Owner为null，当一个线程执行synchronized时就会将Monitor的所有者置为当前线程，Monitor中只能有一个Owner
• 在当前线程上锁的过程中，如果其他线程也来执行synchronized，就会进入EntryList 阻塞 BLOCKED
• 当前线程执行完同步代码块的内容，然后唤醒EntryList中等待的线程来竞争锁，竞争的时候是非公平的（JDK底层实现）

六、轻量级锁

• 前提条件：一个对象虽然有多线程访问，但多线程访问的时间是错开的（没有竞争），则可以使用轻量级锁来优化，有竞争，则还会升级为重量级锁
• 轻量级锁对使用者是透明的，即语法仍然是synchronized，即优先使用轻量级锁加锁，若加锁失败，则升级为重量级锁

6.1 轻量级锁加锁流程

1. 创建锁记录（Lock Record）对象，每个线程的栈都会包含一个锁记录的结构（不可见，不是Java层面），内部包含两部分，一部分是对象的地址（指针）Object reference，另一部分是加锁对象的Mark Word
2. 让锁记录中的Object reference指向锁对象，并尝试用cas替换对象的Mark Word，将Mark Word的值存入锁记录，将对象的Mark Word存入锁记录地址以及加锁状态位（替换的目的就是为了加锁），加锁状态位为01表示无锁状态，00表示轻量级锁状态，10表示重量级锁状态，11表示Marked for GC
3. 若cas替换成功，对象头中存储了锁记录地址和状态00，表示由该线程给对象加轻量级锁（cas保证替换操作是原子性的，不会被打断）

6.2 CAS失败的情况

1. 如果是其他线程已经持有了该Object的轻量级锁，这时表明有竞争，进入锁膨胀过程
2. 如果是自己执行了锁重入，那么再添加一条Lock Record作为重入的计数，即锁记录数对应加锁的次数，锁重入的锁记录中的加锁对象的Mark Word为null

6.3 轻量级锁解锁流程

1. 当退出synchronized代码块（解锁时），如果有取值为null的锁记录，表示有重入，这时重置锁记录，表示重入计数减一
2. 当退出synchronized代码块（解锁时）锁记录的值不为null，这时使用cas将Mark Word的值恢复给对象
   成功，则解锁成功
   失败，说明轻量级锁进行了锁膨胀或已经升级为重量级锁，进入重量级锁解锁流程

七、偏向锁（轻量级锁优化）

• 前提：线程无竞争，轻量级锁在没有竞争时，每次重入仍然需要执行cas操作
• JDK6之后引入偏向锁来做进一步优化：只有第一次使用cas将线程ID设置到对象的Mark Word中，之后只要发现这个线程ID是自己的即表示没有竞争，不用重新cas，以后只要不发生竞争，这个对象就归该线程所有
  对象头格式中，biased_lock：0表示没有启用偏向锁，为1表示~
• 一个对象创建时：
  如果开启了偏向锁（默认开启），那么对象创建以后，Mark Word值为0x05即最后3位为101，这时它的thread、epoch、age都为0，加锁时才会set值
  偏向锁默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加VM参数：-XX:BiasedLockingStartupDelay=0来禁用延迟
  如果没有开启偏向锁，那么对象创建以后，Mark Word值为0x01即最后3位为001，这时它的hashcode、age都为0，第一次用到hashcode时才会赋值
• 禁用偏向锁：添加VM参数：-XX:-UseBisedLocking

八、锁膨胀

• 如果在尝试加轻量级锁的过程中，cas操作无法成功，这时一种情况就是有其他线程为此对象加上了轻量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁，即：
  1. 当前线程为对象申请Monitor重量级锁，让对象的对象头中的Mark Word指向Monitor重量级锁地址，并将加锁状态位置为10，然后自己进入Monitor的EntryList阻塞BLOCKED（此时可以进行自旋优化），轻量级锁没有阻塞的说法，到重量级锁才有阻塞
  2. 当其他线程退出synchronized解锁时，使用cas将Mark Word的值恢复给对象头，失败，这时会进入重量级解锁流程，即按照Monitor地址找到Monitor对象，设置Owner为null，唤醒EntryList中的BLOCKED线程

九、自旋优化（重量级锁优化）

• 重量级锁竞争，在进入Monitor的EntryList阻塞前还可以使用自旋来优化，如果当前线程自旋成功（即此时持有锁的线程已经退出了synchronized同步代码块，释放了锁），这时当前线程就可以避免阻塞
• 在JDK6之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性高，就多自旋几次，反之，就少自旋甚至不自旋（智能自旋次数，随着程序运行和数据积累，JVM可以进行预判同步）
• 自旋会占用CPU时间，单核自旋就是浪费，多核自旋才更有意义
• JDK6默认开启自旋，自旋次数默认是10次，JDK7之后不能手动控制是否开启自旋功能（由JVM底层实现）
• 自旋是一种获取锁时的优化手段，获取锁包含获取轻量级锁、重量级锁，自旋获取轻量级锁失败，升级为重量级锁，获取重量级锁时，可以通过尝试自旋获取重量级锁，自旋获取失败才进入阻塞队列

十、锁消除

10.1 逃逸分析

• 在运行时分析一个方法中创建的对象是否会逃逸到方法或线程外部，如果没有逃逸，可以进而执行一些编译优化，比如栈上分配、同步消除、标量替换等。如果一个对象被分配到栈上，就意味着当方法结束后就会自动销毁，省去了 GC 的开销，这对于优化应用内存占用和 GC 停顿时间来说，无疑是个好消息；而标量替换意味着压根就不会创建对象，相关数据被替换成基本类型数据直接分配到栈上，不仅省去了对象操作相关开销，也更利于 CPU 高速缓存或寄存器进行优化
  -XX:+DoEscapeAnalysis 开启逃逸分析（JDK7默认开启逃逸分析）
• 逃逸分析后锁同步消除
  开启锁消除：-XX:+EliminateLocks
  禁用锁消除：-XX:-EliminateLocks

十一、锁粗化

• 锁粗化就是把很多次锁的请求合并成一个请求，以降低短时间内大量锁请求、同步、释放带来的性能损耗

十二、锁粒度

12.1 死锁

• 多个线程相互占用对方的资源的锁，而又相互等对方释放锁
  t1线程获得A对象的锁，接下来想获取B对象的锁
  t2线程获得B对象的锁，接下来想获取A对象的锁
• 可以顺序加锁解决死锁的问题，但容易产生饥饿

12.1.1 死锁的条件

1. 互斥使用，当资源被一个线程使用(占有)时，别的线程不能使用
2. 不可抢占，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放
3. 请求和保持，当资源请求者在请求其他的资源的同时保持对原有资源的占有
4. 循环等待，存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。这样就形成了一个等待环路

12.1.2 定位死锁

• 检测死锁可以使用jconsole工具，或者使用jps定位进程ID，再用jstack定位死锁

12.2 活锁

• 拿到资源却又相互释放不执行，两个线程互相改变对方的结束条件，最后谁也无法结束
• 可以增加随机睡眠的时间避免活锁的产生

12.3 饥饿

1. 如果优先级高的线程一直抢占优先级低线程的资源，导致低优先级线程无法得到执行，则产生饥饿
2. 一个线程一直占着一个资源不放而导致其他线程得不到执行