likes
comments
collection
share

Java版管程：Synchronized

作者站长头像
站长
· 阅读数 11

我是石页兄，朋友不因远而疏，高山不隔友谊情；偶遇美羊羊，我们互相鼓励

欢迎关注微信公众号「架构染色」交流和学习

一、同步机制

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

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

二、同步机制-管程

2.1 认识管程

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

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

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

  1. 同步问题：

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

  2. 通信问题: 管程中设置条件变量，等待/唤醒操作，以解决同步问题。

    • 条件变量（java里理解为锁对象自身）
    • 等待操作:可以让进程、线程在条件变量上等待（此时，应先释放管程的使用权，不然别其它线程、进程拿不到使用权）；将线程存储到条件变量的等待队列中。
    • 发信号操作:也可以通过发送信号将等待在条件变量上的进程、线程唤醒（将等待队列中的线程唤醒）

2.3 关键数据结构和方法：

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

Java版管程：Synchronized

三、java版的管程 synchronized

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

Java版管程：Synchronized

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

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

进入EntryList的线程需要与其他线程争抢锁，抢到锁之后以排它方式执行同步代码块的代码，当一个线程被notify后，将从_WaitSet中移动到EntryList中。 Java版管程：Synchronized

四、使用锁

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位虚拟机中变化状态如下：

Java版管程：Synchronized

五、锁的变化

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

Java版管程：Synchronized

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

  1. 本线程再次争取锁时：检查这个线程ID跟自己一样，就重入。
  2. 不同的线程争取锁：锁对象中的线程ID不是自己，且有偏向锁标识，则发起偏向锁取消操作。
    • 在SafePoint的时候，若偏向锁取消成功，且当前线程通过CAS操作争取到了锁，则继续保持偏向锁状态.
    • 若一次CAS操作未争取到锁，意味着还有其他的线程也在竞争这个锁，此时就进行锁升级，升级为轻量级锁。
  3. 轻量级锁是自适应自旋锁
    • 自旋获取锁成功：保持轻量级锁状态？？
    • 自旋获取锁失败 ，则进入重量级锁；

5.1 成本的差异

不同的锁性能成本不同：

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

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

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

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

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

5.2 锁消除

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

Java版管程：Synchronized

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

5.3 锁粗化

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

Java版管程：Synchronized

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

参考并感谢

Java锁优化--JVM锁降级

聊聊并发（二）Java SE1.6中的Synchronized