多线程知识梳理(2) - synchronized 三部曲之基本使用

一、为什么要使用 synchronized

使用synchronized的原因在于:它能够确保多个线程在同一时刻,只能有一个线程处于方法或者同步块中,它保证了线程对变量访问的可见性和排他性。

二、synchronized 原理

JDK 1.6之前,synchronized的实现是基于对象上的监视器,这也被称为重量锁。默认情况下,每一个对象都有一个关联的Monitor,而每个Monitor包含了一个EntryCount计数器,它是synchronized实现可重入的关键。

JDK 1.6之后,对锁进行了一系列优化的措施,通过引入自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。

这些优化措施最终的目的是减少锁操作的开销,然而它所改变的只是锁的实现方式,但是加锁和解锁这一基本原则是没有改变的。这篇文章主要是介绍synchronized的使用,因此,在后面的介绍中,我们还是按照比较容易理解的重量锁的方式进行分析,在之后的文章中,我们再来谈一下优化后的实现策略。

2.1 进入同步方法或者代码块

当一个线程执行某个对象的同步方法或者代码块时,会先检查这个对象所关联的Monitor's EntryCount是否为0

  • 如果EntryCount0,那么该线程就会将Monitor’s EntryCount设置为1,并成为该Monitor的所有者,接着执行该方法或者代码块中的语句。
  • 如果EntryCount不为0,这时会去检查对象所关联的Monitor的持有者是哪一个线程:
  • 第一种情况:持有该Monitor的线程就是当前正在尝试获取Monitor的线程,那么将EntryCount的数值加1,继续执行方法或者代码块中的语句。
  • 第二种情况:持有该Monitor的是其它的线程,那么该线程进入阻塞状态,直到EntryCount的数值变为0

2.2 退出同步方法或者代码块

当一个线程从同步方法或者代码块退出时,会将EntryCount1,如果EntryCount变为0,那么该线程会释放它所持有的Monitor。之前那些阻塞在synchronized的线程会尝试去获取Monitor,成功获取Monitor的线程可以进入同步方法或者代码块。

三、synchronized 使用

对于synchronized的使用,我们有两种分类方法:

  • 根据使用场景分类
  • 根据Monitor关联的对象分类。

3.1 根据使用场景分类

很多介绍synchronized的文章,都是通过使用场景进行分类的,一般来说可以分为如下四种使用场景,而每种场景下根据Monitor所关联的对象不同,又会衍生出另外的用法:

  • 静态方法
    //静态方法,使用的是Class类锁
    synchronized public static void staticMethod() {}
  • 静态方法代码块
    private static final byte[] mStaticLockByte = new byte[1];

    //静态方法代码块1,使用的是Class类锁
    public static void staticBlock1() {
        synchronized (SynchronizedObject.class) {}
    }

    //静态方法代码块2,使用的是内部静态变量锁
    public static void staticBlock2() {
        synchronized (mStaticLockByte) {} 
    }
  • 普通方法
    //普通方法,使用的是调用该方法的对象锁
    synchronized public void method() {}
  • 普通方法代码块
    private static final byte[] mStaticLockByte = new byte[1];
    private final byte[] mLockByte = new byte[1];

    //普通方法代码块1,使用的是Class类锁
    public void block1() {
        synchronized (SynchronizedObject.class) {}
    }

    //普通方法代码块2,使用的是mLockByte的变量锁
    public void block2() {
        synchronized (mLockByte) {} //变量需要声明为final
    }
    
    //普通方法代码块3,使用的是mStaticLockByte的变量锁
    public void block3() {
        synchronized (mStaticLockByte) {} 
    }

    //普通方法代码块4,使用的是调用该方法的对象锁
    public void block4() {
        synchronized (this) {}
    }

3.2 根据 Monitor 关联的对象分类

根据使用场景进行分类,主要是为了让大家知道如何使用synchronized关键字,然而要真正地理解synchronized,就需要结合第二节谈到的synchronized原理,其实3.1中谈到的多种场景,都是和Monitor有关,那么从和Monitor关联的对象来看,我们重新对3.1中的8种场景重新进行分类:

  • Class对象:
  • 静态方法
  • 静态方法代码块1 – SynchronizedObject.class
  • 普通方法代码块1 – SynchronizedObject.class
  • 调用方法的对象
  • 普通方法
  • 普通方法代码块4 – this
  • 静态对象
  • 静态方法代码块2 – mStaticLockByte
  • 普通方法代码块3 – mStaticLockByte
  • 非静态对象
  • 普通方法代码块1 – mLockByte

如果使用场景属于上面的同一个分类当中,那么才有可能产生线程阻塞在synchronized关键字的情况,举一个例子,如果A线程通过静态方法访问(分类一)并且没有从该方法退出:

  • 这时B线程是通过一个对象的普通方法来访问(分类二),那么是不会阻塞的,这是因为调用该方法的对象所关联的Monitor没有被持有。
  • 如果B线程使用的是静态方法代码块来访问,而该静态方法代码块使用的是SynchronizedObject.class来修饰(分类一),由于这两种使用场景是属于同一个分类,那么就会B线程就会进入阻塞状态,这是因为SynchronizedObject类所关联的Monitor已经被A线程持有了。

四、小结

从表面上来看,synchronized的使用可以简单地分为同步方法和同步代码块,但是究竟在什么情况下会导致一个线程在synchronized上阻塞,则需要分析synchronized方法所尝试获取的Monitor的是否已经被其它线程持有了。

    原文作者:泽毛
    原文地址: https://www.jianshu.com/p/7cc152bf107e
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞