Java版管程：Synchronized-51CTO.COM

一、同步机制

保证共享资源的读写安全，需要一种同步机制：用于解决 2 方面问题：

线程间通信：线程间交换信息的机制
线程间同步：控制不同线程之间操作发生相对顺序的机制

二、同步机制-管程

2.1 认识管程

同步机制中有经典的管程方案，关于管程在在中国大学 mooc 中搜索管程有些大学的操作系统课程会讲解管程。管程其实就是对共享变量以及其操作的封装：

将共享资源封装起来，对外提供操作这些共享资源的方法。
线程只能通过调用管程中的方法来间接地访问管程中的共享资源

2.2 管程如何解决同步和通信问题

1）同步问题

管程是互斥进入，提供了入口等待队列，用于存储等待进入同步代码块的线程
管程的互斥进入是由编译器负责保证的，

通常的做法是用一个互斥量或二元信号量

2）通信问题，管程中设置条件变量，提供等待/唤醒操作

条件变量：java 里理解为锁对象自身
等待操作：等待条件变量时，将线程存储到条件变量的等待队列中，此时，应先释放管程的使用权，不然其它线程拿不到使用权
唤醒操作：通过发送信号将等待队列中的线程唤醒

2.3 关键数据结构和方法

1）等待队列

入口等待队列：存储等待进入同步代码块的线程；线程进入管程后，可以执行同步块代码。在 java 中是 _EntryList
条件等待队列：入口等待队列中的线程，进入管程后，执行同步块代码的过程中，需要等待某个条件满足之后，才能继续执行，就将线程放入此变量的等待队列中。MESA管程中是多个条件等待队列，java 是面向对象的设计，这里的条件变量即锁对象自身（线程都在等待拥有这个锁），所以只有一个条件变量等待队列即_WaitSet 。

2）同步方法

wait() ：等待条件变量，将当前线程放入条件变量的等待队列中
notify()：激活某个条件变量上等待队列中的一个线程
notifyAll()：激活某个条件变量上等待队列中的所有线程

三、Java 版的管程 synchronized

synchronized 是语法糖，会被编译器编译成：1 个 monitorenter 和 2 个 moitorexit（一个用于正常退出，一个用于异常退出）。monitorenter 和正常退出的 monitorexit 中间是 synchronized 包裹的代码，如下图：

image.png

在 HotSpot 虚拟机中，monitor 是由 ObjectMonitor 实现的，ObjectMonitor 主要数据结构如下：

_count：记录 owner 线程获取锁的次数，即重入次数，也即是可重入的。
_owner：指向拥有该对象的线程
_EntryList：管程的入口等待队列，即存放等待锁而被 block 的线程。
_WaitSet：管程的条件变量等待队列，存放的是拥有锁后又调用了 wait()方法的线程；

进入 _EntryList 的线程需要与其他线程争抢锁，抢到锁之后以排它方式执行同步代码块的代码，当其再调用wait()方法后进入_WaitSet，当_WaitSet里的线程被 notify()/notifyAll() 后，将从 _WaitSet 中移动到 _EntryList 中。

四、使用锁

4.1 对实例对象加锁

同步实例方法

public synchronized void fun(){
}

同步代码块参数是实例

public void fun(){
    synchronized(this){
        ...
    }
}

4.2 对类加锁

同步静态方法

class Aclass{
    static synchronized void fun(){
    }
}

同步代码块参数是类

class Aclass{
    static void fun(){
        synchronized (Aclass.class){
        }
    }
}

4.3 对象的内存结构

HotSpot 虚拟机中，对象在内存中存储的布局可以分为三块区域:对象头 (Header)、实例数据(Instance Data)和对齐填充(Padding)。

其中对象头中的 Mark Word 区域中会存储对象锁，锁状态标志，偏向锁(线程)ID，偏向时间，数组长度(数组对象)等，Mark Word 被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据，它会根据对象的状态复用自己的存储空间，也就是说， Mark Word 会随着程序的运行发生变化，32 位虚拟机中变化状态如下：

五、锁的变化

锁的性能开销的变化：无锁——>偏向锁——>轻量级锁——>重量级锁，并且膨胀方向不可逆。

偏向锁：线程获取锁后，锁对象的 Mark Word 标记偏向锁，通过一个字段记录当前线程 id，逻辑如下：

本线程再次争取锁时：检查到这个线程 ID 跟自己一样就重入
不同的线程争取锁：锁对象中的线程 ID 不是自己，且有偏向锁标识，则发起偏向锁取消操作，

偏向锁的撤销需要等待全局安全点

若偏向锁取消成功，且之后当前线程又通过 CAS 操作争取到了锁，则继续保持偏向锁状态
若经过一次 CAS 操作未争取到锁，意味着还有其他的线程也在竞争这个锁，此时就进行锁升级，升级为轻量级锁

轻量级锁是自适应自旋锁

自旋获取锁成功，是保持轻量级锁状态吗？？
自旋获取锁失败，则进入重量级锁

5.1 成本的差异

不同的锁性能成本不同：

1）重量级锁：线程在用户态到内核态之间切换成本高

锁不能降级，锁变成重量级锁之后，就一直要作为重量级锁使用吗？那还怎么自适应自旋？？

Java 锁优化--JVM 锁降级里说道：锁降级确实是会发生的，当 JVM 进入安全点（SafePoint）的时候，会检查是否有闲置的 Monitor，然后试图进行降级。

2）其他的锁都是为了更小的开销

偏向锁：一次 CAS 操作，修改一下锁中的字段，就被标识为拿得到了锁
轻量锁：一次 CAS 操作拿不到锁，那就自旋空转多次 CAS 操作，会稍稍费一点 CPU，但是能更快的拿到锁；自适应自旋后，还拿不到锁，那就只能使用重量级锁了。
自旋锁：许多情况下，共享数据的锁定状态持续时间较短，切换线程不值得，通过让线程执行循环等待锁的释放，不让出 CPU。如果得到锁，就顺利进入临界区。如果还不能获得锁，那就会将线程在操作系统层面挂起，这就是自旋锁的优化方式。但是它也存在缺点：如果锁被其他线程长时间占用，一直不释放 CPU，会带来许多的性能开销。
自适应自旋锁：这种相当于是对上面自旋锁优化方式的进一步优化，它的自旋的次数不再固定，其自旋的次数由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定，这就解决了自旋锁带来的缺点。

5.2 锁消除

消除锁是虚拟机另外一种锁的优化，这种优化更彻底，在 JIT 编译时，对运行上下文进行扫描，做逃逸分析，去除不可能存在竞争的锁（去掉了申请和释放锁的代码了）。比如下面代码的 method1 和 method2 的执行效率是一样的，因为 object 锁是私有变量，不存在所得竞争关系。

锁消除示例(来自网络).png

5.3 锁粗化

锁粗化是虚拟机对另一种极端情况的优化处理，通过扩大锁的范围，避免反复获取锁和释放锁。比如下面 method3 经过锁粗化优化之后就和 method4 执行效率一样了。

锁粗化示例(来自网络).png

本文转载自微信公众号「架构染色」，可以通过以下二维码关注。转载本文请联系【架构染色】公众号作者。