Java并发之Synchronized机制详解

带着问题阅读

1、Synchronized如何使用，加锁的粒度分别是什么

2、Synchronized的实现机制是什么

3、Synchronized是公平锁吗

4、Java对Synchronized做了哪些优化

Synchronized介绍

基本上所有的并发模式在解决线程冲突问题的时候，都是采用序列化访问共享资源的方案。这意味着在给定时刻只允许一个任务访问共享资源。通常这是通过在代码前面加上一条锁语句来实现的，这就使得在一段时间内只有一个任务可以运行这段代码。因为锁语句产生了一种互相排斥的效果，所以这种机制常常称为互斥量(mutex)。

为防止资源冲突，Java提供了Synchronized用于解决互斥访问的问题。当任务执行被Synchronized修饰的代码时，将先检查锁是否可用，然后获取锁、执行代码，最后释放锁。考虑屋里有一个卫生间，多个人都需要单独使用，为了使用卫生间，每个人都先敲门，看看能否使用，如果没人使用他就进入卫生间并锁上门，当其它人来的时候就会被挡在门外。

Synchronized使用方式

对象锁

synchronized可以用于修饰具体对象，如示例中分别对synObj和this对象加锁，即synObj和this分别作为共享资源被用于互斥访问，其中thread1和thread2同时访问synObj互斥，thread3和thread4同时访问this(demo对象)互斥。

public class Demo {
    private Object synObj = new Object();
    
    public void synObj() {
        // 对synObj对象加锁
        synchronized(synObj) {
            // 同步代码
        }
    }
    
    public void synThis() {
        // 对当前对象加锁
        synchronized(this) {
            // 同步代码
        }
    }
}

Demo demo = new Demo();
// 假设以下四个线程同时运行
new Thread(demo::synObj).start();   // thread1
new Thread(demo::synObj).start();   // thread2
new Thread(demo::synThis).start();  // thread3
new Thread(demo::synThis).start();  // thread4

普通方法锁

synchronized也可用于修饰方法，修饰方法时锁的对象即this，因此如果类的多个方法上都添加了synchronized，那么这几个方法在同步执行时也是互斥的。

public class Demo {
    public synchronized void test1() {};
    public synchronized void test2() {};
}

Demo demo = new Demo();
// 以下两个线程同步执行时是互斥的，都需要获取demo对象的锁
new Thread(demo::test1).start();
new Thread(demo::test2).start();

静态方法锁

以上两种应用方式由于锁的粒度都是对象，因此只能在并发调用同一个对象的方法是才会互斥，如果创建了Demo demo1 = new Demo()和Demo demo2 = new Demo()两个对象并分别调用，就不会产生互斥。如要在多实例之间也达成互斥，则可以通过修饰静态方法来达成。

public class StaticDemo {
    private static Object obj = new Object();
    public void test() {
        synchronized(obj) {
            // 同步代码
        }
    }
    
    public static synchronized void testStatic() {};
}

// 两个线程互斥s
new Thread(StaticDemo::testStatic).start();
new Thread(StaticDemo::testStatic).start();

类锁

通过添加类锁，也可实现多实例之间的互斥。synchronized修饰在静态方法时，也等价于修饰当前类对象。

public class StaticDemo {
    public void test() {
        synchronized(StaticDemo.class) {
            // 同步代码
        }
    }
}

Synchronized原理分析

不论synchronized用于修饰哪里，本质还是会修饰到具体的对象(实例对象或类对象)上，synchronized的实现机制也是对对象的加锁。Java中每个对象都隐含关联一个监视器ObjectMonitor，监视器通过cpp实现内置在JVM中，监视器地址记录在对象的MarkWord上，synchronized通过ObjectMonitor实现对象的锁操作。

对象头MarkWord简介

JVM在内存中将对象划为三部分：对象头、实例数据和填充数据。对象头分为MarkWord和类型指针两部分，这里只针对锁相关做进一步介绍。MarkWord用于存储对象自身的运行数据，如哈希值、GC分代年龄等，这部分在32位和64位虚拟机中会分别占用32位和64位空间，以下是32位的空间布局(64位布局相同，分的bit数不同)，MarkWord会根据对象状态复用存储空间，例如对象未锁定状态下，采用25bit哈希 + 4bitGC年龄 + 1bit固定0 + 2bit标志存储。当标志位为10表示对象处于重量级锁定时，剩余空间就用于存储ObjectMonitor对象的地址。

ObjectMonitor简介

ObjectMonitor() {
    ...
    _count = 0; // 记录个数
    _owner = NULL;  // 记录持有线程
    _cxq = NULL;    // 记录锁阻塞线程，与EntryList配合
    _WaitSet = NULL;    // 记录处于wait状态的线程
    _EntryList = NULL;  // 记录处于锁阻塞状态的线程
    ...
}

ObjectMonitor整体内容略去，核心关注以上字段。_owner用于记录持有线程，_count用于记录重入次数，_cxq和_EntryList配合用于记录获取锁失败阻塞后的线程。
线程获取锁失败后会首先被挂载到_cxq队列上并调用park阻塞。当锁被释放时，如_EntryList不为空，则尝试唤醒_EntryList队首元素；如_EntryList为空，默认从_cxq摘取队首元素放入_EntryList并试图获取锁。由于monitor锁机制为非公平锁，因此可能唤醒失败，两个队列都会保存阻塞元素。

详细解析可见参考第二篇文章

objectMonitor

Synchronized重量级锁原理

public class Demo {
    private Object obj = new Object();
    public void test() {
        synchronized(obj) {
            System.out.println("lock");
        }
    }
}

编译以上代码，javap -v查看字节码。

...
public void test();
    Code:
        ...
        monitorenter    // 加锁
        ...
        monitorexit     // 释放锁
        ...
        return
...

其余内容略去，关键在于monitorenter和monitorexit两个指令。

当执行monitorenter时，将会尝试获取该对象monitor的所有权。

如果monitor持有数为0即无线程持有，则直接获取monitor并将进入数+1；
如果monitor已被线程占有，检查是否为当前线程，如是当前线程，则将计数器+1；否则阻塞当前线程。

当执行monitorexit时，将monitor计数器-1，如减后为0，则线程释放monitor。

如synchronized修饰在方法上，则会在方法上增加ACC_SYNCHRONIZED的标记，原理与上述相同。

JVM对Synchronized的优化

monitorenter和monitorexit依赖底层操作系统的mutex lock实现，该指令对线程的挂起和唤醒涉及到用户态到内核态的切换，如果同步代码频繁调用，会带来昂贵的切换开销。自jdk1.6起对锁的实现引入了大量优化，下面来介绍一下都做了哪些优化。

锁消除

锁消除是指虚拟机即时编译器在运行时，对一些代码要求同步，但是对被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定一句来源于逃逸分析的数据支持，如果判断一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为是线程私有的，同步加锁无须进行。

public String copyString(String s) {
    StringBuffer sb = new StringBuffer();
    sb.append(s);
    return sb.toString();
}

如示例代码，StringBuffer.append是通过sychronized修饰的线程安全操作，但在该代码块中，sb对象是局部变量，仅会被当前线程访问，不存在线程竞争，因此锁经过编译器检测后可以消除。

锁粗化

原则上编写同步代码时，推荐将同步块的作用范围限制的尽量小，一方面减少同步代码块的执行时间，一方面减少同步竞争次数，以便存在竞争时，等待锁的线程可以尽快获得锁。但是如果一系列连续操作都在对同一对象反复加锁和释放锁，那即使没有线程竞争也会产生很多没必要的开销。

private Object obj = new Object();

public void lock() {
    synchronized(obj) {
        ...
    }
    // 再次加锁
    synchronized(obj) {
        ...
    }
}

如上代码，连续两次对同一对象进行同步，即可将锁粗化合并为一个锁。

锁消除和锁粗化都是依赖JIT即时编译实现，因此通过javac查看编译后的字节码，仍然保留着原始的锁指令。

自旋锁和自适应自旋

前文中我们提到，互斥同步涉及的挂起/唤醒线程都涉及内核态转换，如果频繁产生竞争会带来很大的压力。虚拟机开发团队注意到很多应用对锁的持有只会持续很短的时间，如果可以让竞争锁的线程稍等一下，不放弃处理器，就可以在持有锁的线程执行完毕后获取锁，避免产生空间切换，这就是自旋。

自旋锁在jdk1.4.2中就引入，需要-XX: +UseSpining开启，在jdk6以后就默认开启了。自旋虽然避免了空间切换问题，但如果某个锁竞争很激烈或者锁的持有时间很长，那自旋只能白白占用处理器资源，因此在jdk1.6中引入了自适应自旋。自适应意味着自旋的时间不再固定，如果对一个锁对象自旋等待刚刚成功过，则允许后续自旋等待较长时间；如果自旋很少成功，那就在后续获得锁的过程中直接跳过自旋。

偏向锁

偏向锁也是jdk1.6引入的优化，目的是消除数据在无竞争情况下的同步原语。锁被第一个线程获取后，在接下来的执行过程中，如果一直没有被其他线程获取，则持有偏向锁的线程不在需要同步。

偏向锁加锁流程如下：

检查当前是否为偏向状态。
如果是，检查当前线程ID与Mark Word记录的线程ID是否一致，如一致则进入同步代码，不一致则释放偏向锁
如不是偏向锁，则使用CAS尝试修改线程ID，如修改成功则进入同步代码，失败则释放偏向锁

线程获取偏向锁后，持有锁的线程以后每次进入相应同步块时，都不需要再进行任何同步操作。

偏向锁不会主动释放，只有当其他线程尝试获取锁时，才会检查持有线程是否可以释放锁。如可以释放则替换为新线程ID，不可释放则升级为轻量级锁。

勘误：图中如判断对象头Mark Word记录非当前线程ID，下一步应当为开始偏向锁撤销而非CAS替换。如有不同意见欢迎留言

轻量级锁

轻量级锁在MarkWord标志位中由00表示，轻量级锁首先在当前线程栈帧当中建立一个锁记录Lock Record，用于存储MarkWord的拷贝；然后虚拟机使用CAS操作将Lock Record的地址记录到MarkWord当中，并将标志位改为00，表示对象处于轻量级锁定状态。如果更新失败，则会进入自旋并在自旋达到一定次数后升级为重量级锁。自旋的同时如果有第三个线程尝试获取锁，也会直接升级到重量级锁。

同步代码执行完毕后，轻量级锁同样使用CAS操作将栈帧中的MarkWord拷贝回到对象中，如果操作成功，则释放锁；如果替换失败，则说明有其他线程在竞争锁(意味着升级为重量级锁)，则当前膨胀为重量锁转换为重量锁的释放。

重量级锁

重量级锁即上文Synchronized重量级锁原理所述内容，综上synchronized的加锁过程为偏向锁 -> 轻量级锁 -> 重量级锁，这个过程也称为锁膨胀。

图源自网络

总结

最后总结对比一下几种锁实现。

锁类型	运行空间	实现机制	适用范围
偏向锁	用户态	初次CAS加锁，后续如无竞争可直接进入	单线程执行
轻量级锁	用户态	CAS+自旋加锁	锁竞争不激烈
重量级锁	内核态	mutex 内核态操作	锁激烈竞争

参考

posted @ 2021-08-17 23:16 拉夫德鲁阅读(746) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

拉夫德鲁