Synchronized的实现原理以及优化

最新推荐文章于 2020-12-10 07:52:55 发布

大何向东流1997

最新推荐文章于 2020-12-10 07:52:55 发布

阅读量391

点赞数

分类专栏： Java并发编程文章标签： synchronized

本文链接：https://blog.csdn.net/h2503652646/article/details/109583757

版权

Java并发编程专栏收录该内容

2 篇文章 0 订阅

订阅专栏

在多线程学习阶段，我们经常会使用synchronized来解决线程间的同步问题，很少关注过它的实现原理，但在并发编程的学习中，我们需要对synchronized的实现原理以及优化有更多的了解。

一、利用sychronized实现同步的三种方式

二、synchronized实现原理

三、对synchronized的优化

一、利用sychronized实现同步的三种方式

对于普通同步方法，锁是当前实例对象this。
对于静态同步方法，锁是当前类的Class对象。
对于同步方法块，锁是Synchonized括号里配置的对象。

二、synchronized实现原理

先来看下面一段代码：

public class SynchronizedTest {
    
    public static void main(String[] args) {
        
        synchronized (SynchronizedTest.class) {
            System.out.println("被锁内容。。。");
        }
        
    }
}

这是一个被synchronized修饰的同步代码块，将这段代码反编译后结果如下。

可以看到反编译的结果中出现了monitorenter和monitorexit两个指令。这个两个指令的意义：当虚拟机执行到monitorenter指令时就会尝试获取对象的监视器锁（monitor），如果monitor的进入数为0，则该线程进入monitor，然后将进入数+1，该线程即为monitor的所有者；如果该线程已经是monitor的所有者了，则重新进入，monitor的进入数+1；如果已经有其他线程占有了该monitor，则该线程进入阻塞状态，直到monitor进入数为0，再重新尝试获取monitor拥有权。当虚拟机执行到monitorexit指令时，monitor的进入数-1，如果减1后进入数为0，则线程退出monitor，该线程不再是monitor的所有者，其他被这个monitor阻塞的线程可以尝试获取monitor的所有权。

上面是被synchronized修饰的同步代码块，再来看下面这段代码：

public class SynchronizedTest {
    
    public static synchronized void method () {
        System.out.println("被锁内容。。。");
    }
    
    public static void main(String[] args) {
        method();
    }
}

method（）是一个被synchronized修饰的静态同步方法，同样对这段代码进行反编译后结果如下。

可以看到在反编译结果中，method（）方法的flags中出现了一个ACC_SYNCHRONIZED标识。它的意义：当方法被调用时，调用指令将会先检查是否有ACC_SYNCHRONIZED标识，如果有，则线程先获取monitor，获取成功后再执行方法体，方法执行完后再释放monitor，在此期间其他线程无法获取同一个monitor对象。

总结：对于同步代码块，在编译前后会被编译器生成monitorenter和monitorexit两个指令；而对于同步方法，在编译后会多出一个ACC_SYNCHRONIZED标识。他们的共同作用是，通过在对象头设置标记达到获取锁和释放锁的目的。

三、对synchronized的优化

JDK1.6以后，Java对synchronized做了很多的优化。

自旋锁：线程在阻塞和唤醒之间的切换所要花费的代价非常大。自旋锁是在把线程进行阻塞前先让线程进行自旋等待一段时间，因为很有可能在这段时间其他线程会释放该线程所需要的锁，这样的话该线程就不用再进行阻塞操作，也避免了阻塞和唤醒之间的切换。

锁消除：虚拟机编译器在运行时，对于一些代码上要求同步，但经过检测（逃逸分析）发现实际上不可能存在共享数据竞争的情况，于是将锁进行消除。如StringBuffer中的append（）方法是被Synchronized修饰过的，但在很多情况下它只会在一个线程中被使用，如果编译器能够确定这个StringBuffer对象只会在一个线程中被使用，就代表这个线程一定是安全的，就会做出一定的优化，把对应的synchronized消除，省去加锁解锁的开销，提高效率。

锁粗化：增大锁的作用域，减少频繁对同一个代码块的加锁和解锁操作，提升性能。比如在一个循环体内对同一个代码块进行频繁的加锁和解锁的操作，这样会增大开销。我们可以只用在循环体外加一次锁就可以了，相当于多个小的同步代码块合并成了一个大的同步代码块，这样就无需频繁申请和释放锁了，减少性能上的开销。

锁膨胀：

偏向锁：一个对象被初始化后，如果还没有任何线程来获取它的锁时，它就是可偏向的，当线程1获取了它的锁后，它会在对象头的MarkWord中记录下线程1的ID，之后线程1再次尝试获取这个锁时，这个锁发现记录中的线程ID正是线程1，则允许线程1直接执行同步代码，开销很小。此时线程2来竞争锁，但MarkWord中的线程ID并未指向线程2，判断当前对象头是否为偏向锁以及锁是否被其他线程占有，如果是偏向锁且锁已经不再被线程1占有，则线程2通过CAS操作将MarkWord中的线程ID指向线程2（此时锁不升级仍为偏向锁）；若锁此刻仍然被线程1占有，则代表此时有竞争了，到达全局安全点后（safepoint）线程1被暂时挂起，此时锁升级为轻量级锁，被挂起的线程1继续执行同步代码，线程2通过自旋方式获取锁。这种锁状态下的线程无实际的竞争。
轻量级锁：轻量级锁是由偏向锁在存在竞争的情况下升级而来。在这种情况下并不存在实际的竞争，最多也是短时间的竞争，使用CAS就可以解决。如果当前线程CAS竞争锁失败，则通过自旋的方式获取锁，若自旋一定次数后依然没有获得锁，则升级为重量级锁。这种锁状态下的线程无实际竞争，多个线程交替使用锁，允许短时间的竞争。
重量级锁：当多个线程存在实际的竞争，且竞争的时间较长，偏向锁和轻量级锁都不再满足需求了，此时锁将会升级为重量级锁。重量级锁通过同步机制实现，会让其他拿不到锁的线程进入阻塞状态，这种锁的开销较大。这种锁状态下的线程存在实际竞争，且竞争时间较长。虚拟机优先使用偏向锁，在有必要的情况下再逐步升级，这样能够有效提高了锁的性能。