synchronized原理深入

119 阅读4分钟

1 类锁、对象锁

synchronized的使用一般就是同步方法和同步代码块。 synchronized的锁是基于对象实现的。 如果使用同步方法 static:此时使用的是当前类.class作为锁(类锁) 非static:此时使用的是当前对象做为锁(对象锁)

public class MiTest { 
    public static void main(String[] args) { 
        // 锁的是,当前
        Test.class Test.a(); 
        Test test = new Test(); 
        // 锁的是new出来的test对象 
        test.b(); 
        } 
    } 
class Test{ 
    public static synchronized void a(){ 
        System.out.println("1111"); 
    } 
    public synchronized void b(){ 
        System.out.println("2222"); 
    } 
 }

2 synchronized的优化

在JDK1.5的时候,Doug Lee推出了ReentrantLock,lock的性能远高于synchronized,所以JDK团 队就在JDK1.6中,对synchronized做了大量的优化。

锁消除:在synchronized修饰的代码中,如果不存在操作临界资源的情况,会触发锁消除,你即便 写了synchronized,他也不会触发。

public synchronized void method(){ 
    // 没有操作临界资源 
    // 此时这个方法的synchronized你可以认为木有~~ 
    }

锁膨胀:如果在一个循环中,频繁的获取和释放做资源,这样带来的消耗很大,锁膨胀就是将锁的范 围扩大,避免频繁的竞争和获取锁资源带来不必要的消耗。

public void method(){
    for(int i = 0;i < 999999;i++){
        synchronized(对象){
        }
    }
    // 这是上面的代码会触发锁膨胀
    synchronized(对象){
        for(int i = 0;i < 999999;i++){
        }
    }
}

锁升级:ReentrantLock的实现,是先基于乐观锁的CAS尝试获取锁资源,如果拿不到锁资源,才会 挂起线程。synchronized在JDK1.6之前,完全就是获取不到锁,立即挂起当前线程,所以 synchronized性能比较差。

synchronized就在JDK1.6做了锁升级的优化

无锁、匿名偏向:当前对象没有作为锁存在。

偏向锁:如果当前锁资源,只有一个线程在频繁的获取和释放,那么这个线程过来,只需要判 断,当前指向的线程是否是当前线程 。 如果是,直接拿着锁资源走。 如果当前线程不是我,基于CAS的方式,尝试将偏向锁指向当前线程。如果获取不到,触发 锁升级,升级为轻量级锁。(偏向锁状态出现了锁竞争的情况)

轻量级锁:会采用自旋锁的方式去频繁的以CAS的形式获取锁资源(采用的是自适应自旋锁) 如果成功获取到,拿着锁资源走 如果自旋了一定次数,没拿到锁资源,锁升级。

重量级锁:就是最传统的synchronized方式,拿不到锁资源,就挂起当前线程。(用户态&内 核态)

3 synchronized实现原理

synchronized是基于对象实现的。 先要对Java中对象在堆内存的存储有一个了解。

image.png 展开MarkWord image.png MarkWord中标记着四种锁的信息:无锁、偏向锁、轻量级锁、重量级锁

4 synchronized的锁升级

为了可以在Java中看到对象头的MarkWord信息,需要导入依赖

<dependency>
   <groupId>org.openjdk.jol</groupId>
   <artifactId>jol-core</artifactId>
   <version>0.9</version>
</dependency>

锁默认情况下,开启了偏向锁延迟。

偏向锁在升级为轻量级锁时,会涉及到偏向锁撤销,需要等到一个安全点(STW),才可以做 偏向锁撤销,在明知道有并发情况,就可以选择不开启偏向锁,或者是设置偏向锁延迟开启

因为JVM在启动时,需要加载大量的.class文件到内存中,这个操作会涉及到synchronized的 使用,为了避免出现偏向锁撤销操作,JVM启动初期,有一个延迟4s开启偏向锁的操作

如果正常开启偏向锁了,那么不会出现无锁状态,对象会直接变为匿名偏向

public static void main(String[] args) throws InterruptedException {
    Thread.sleep(5000);
    Object o = new Object();
    System.out.println(ClassLayout.parseInstance(o).toPrintable());
    new Thread(() -> {
        synchronized (o) {
            //t1 - 偏向锁
            System.out.println("t1:" + ClassLayout.parseInstance(o).toPrintable());
        }
    }).start();
    //main - 偏向锁 - 轻量级锁CAS - 重量级锁
    synchronized (o) {
        System.out.println("main:" + ClassLayout.parseInstance(o).toPrintable());
    }
}

整个锁升级状态的转变:

image.png

Lock Record以及ObjectMonitor存储的内容

image.png

5 重量锁底层ObjectMonitor

需要去找到openjdk,在百度中直接搜索openjdk,第一个链接就是 找到ObjectMonitor的两个文件,hpp,cpp 先查看核心属性:hg.openjdk.java.net/jdk8u/jdk8u… /share/vm/runtime/objectMonitor.hpp

ObjectMonitor() {
    _header = NULL; // header存储着MarkWord
    _count = 0; // 竞争锁的线程个数
    _waiters = 0, // wait的线程个数
            _recursions = 0; // 标识当前synchronized锁重入的次数
    _object = NULL;
    _owner = NULL; // 持有锁的线程
    _WaitSet = NULL; // 保存wait的线程信息,双向链表
    _WaitSetLock = 0 ;
    _Responsible = NULL ;
    _succ = NULL ;
    _cxq = NULL ; // 获取锁资源失败后,线程要放到当前的单向链表中
    FreeNext = NULL ;
    _EntryList = NULL ; // _cxq以及被唤醒的WaitSet中的线程,在一定机制下,会放到EntryList中
    _SpinFreq = 0 ;
    _SpinClock = 0 ;
    OwnerIsThread = 0 ;
    _previous_owner_tid = 0;
}

适当的查看几个C++中实现的加锁流程 hg.openjdk.java.net/jdk8u/jdk8u… /objectMonitor.cpp

TryLock

int ObjectMonitor::TryLock (Thread * Self) {
    for (;;) {
        // 拿到持有锁的线程
        void * own = _owner ;
        // 如果有线程持有锁,告辞
        if (own != NULL) return 0 ;
        // 说明没有线程持有锁,own是null,cmpxchg指令就是底层的CAS实现。
        if (Atomic::cmpxchg_ptr (Self, &_owner, NULL) == NULL) {
            // 成功获取锁资源
            return 1 ;
        }
        // 这里其实重试操作没什么意义,直接返回-1
        if (true) return -1 ;
    }
}

try_entry

bool ObjectMonitor::try_enter(Thread* THREAD) {
    // 在判断_owner是不是当前线程
    if (THREAD != _owner) {
        // 判断当前持有锁的线程是否是当前线程,说明轻量级锁刚刚升级过来的情况
        if (THREAD->is_lock_owned ((address)_owner)) {
            _owner = THREAD ;
            _recursions = 1 ;
            OwnerIsThread = 1 ;
            return true;
        }
        // CAS操作,尝试获取锁资源
        if (Atomic::cmpxchg_ptr (THREAD, &_owner, NULL) != NULL) {
            // 没拿到锁资源,告辞
            return false;
        }
        // 拿到锁资源
        return true;
    } else {
        // 将_recursions + 1,代表锁重入操作。
        _recursions++;
        return true;
    }
}

enter(想方设法拿到锁资源,如果没拿到,挂起扔到_cxq单向链表中)

void ATTR ObjectMonitor::enter(TRAPS) {
    // 拿到当前线程
    Thread * const Self = THREAD ;
    void * cur ;
    // CAS走你,
    cur = Atomic::cmpxchg_ptr (Self, &_owner, NULL) ;
    if (cur == NULL) {
        // 拿锁成功
        return ;
    }
    // 锁重入操作
    if (cur == Self) {
        // TODO-FIXME: check for integer overflow! BUGID 6557169.
        _recursions ++ ;
        return ;
    }
    //轻量级锁过来的。
    if (Self->is_lock_owned ((address)cur)) {
        _recursions = 1 ;
        _owner = Self ;
        OwnerIsThread = 1 ;
        return ;
    }
    // 走到这了,没拿到锁资源,count++
    Atomic::inc_ptr(&_count);
    for (;;) {
        jt->set_suspend_equivalent();
        // 入队操作,进到cxq中
        EnterI (THREAD) ;
        if (!ExitSuspendEquivalent(jt)) break ;
        _recursions = 0 ;
        _succ = NULL ;
        exit (false, Self) ;
        jt->java_suspend_self();
    }
}
// count--
Atomic::dec_ptr(&_count);

EnterI

for (;;) {
    // 入队
    node._next = nxt = _cxq ;
    // CAS的方式入队。
    if (Atomic::cmpxchg_ptr (&node, &_cxq, nxt) == nxt) break ;
    // 重新尝试获取锁资源
    if (TryLock (Self) > 0) {
        assert (_succ != Self , "invariant") ;
        assert (_owner == Self , "invariant") ;
        assert (_Responsible != Self , "invariant") ;
        return ;
    }
}