深入理解synchronized

 

作用范围

修饰实例方法，作用于当前实例加锁，进入同步代码前要获得当前实例的锁
对于静态方法，由于此时对象还未生成，所以只能采用类锁；
修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。

对于对象锁（this），如果是同一个实例，就会按顺序访问，但是如果是不同实例，就可以同时访问。

1.原理

• monitor与对象头

在JVM中，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充
实例变量：存放类的属性数据信息，包括父类的属性信息，如果是数组的实例部分还包括数组的长度，这部分内存按4字节对齐。
填充数据：由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐
Java头对象，它实现synchronized的锁对象的基础，其主要结构是由Mark Word 和 Class Metadata Address 组成
Mark Word在默认情况下存储着对象的HashCode、分代年龄、锁标记位等以下是32位JVM的Mark Word默认存储结构

还有如下可能变化的结构：

 

• 锁原理

每个对象都有一个monitor监视器，调用monitorenter就是尝试获取这个对象，成功获取到了就将值+1，离开就将值减1。如果是线程重入，在将值+1，说明monitor对象是支持可重入的。
同步方法并不是由 monitorenter 和 monitorexit，而是由方法调用指令读取运行时常量池中方法的 ACC_SYNCHRONIZED 标志来隐式实现的，获取它的monitor，所以本质上是一样的

2.锁类别

• 锁的状态总共有四种，无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁

2.1重量级锁

监视器锁（monitor）是依赖于底层的操作系统的Mutex Lock来实现的，而操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，这也是为什么早期的synchronized效率低的原因。

2.2偏向锁

如果一个线程获得了锁，那么锁就进入偏向模式，当这个线程再次请求锁时，无需再做任何同步操作，即获取锁的过程，这样就省去了大量有关锁申请的操作，从而也就提供程序的性能。所以，对于没有锁竞争的场合，偏向锁有很好的优化效果，毕竟极有可能连续多次是同一个线程申请相同的锁。如果有其他线程来，偏向模式就结束了，标志位会恢复到未锁定或者偏向锁。所以如果锁总是会被多个线程访问的话，还是禁止掉偏向锁优化比较好。
同一个线程第二次进来之后，虚拟机不会再进行任何的同步操作

2.3轻量级锁

轻量级锁所适应的场景是线程交替执行同步块的场合（将申请互斥量这步也省掉），如果存在同一时间访问同一锁的场合，就会导致轻量级锁膨胀为重量级锁。

2.4自旋锁

轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。这是基于在大多数情况下，线程持有锁的时间都不会太长，如果直接挂起操作系统层面的线程可能会得不偿失，毕竟操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，因此自旋锁会假设在不久将来，当前的线程可以获得锁，因此虚拟机会让当前想要获取锁的线程做几个空循环(这也是称为自旋的原因)，一般不会太久，可能是50个循环或100循环，在经过若干次循环后，如果得到锁，就顺利进入临界区。如果还不能获得锁，那就会将线程在操作系统层面挂起，这就是自旋锁的优化方式，这种方式确实也是可以提升效率的。最后没办法也就只能升级为重量级锁了。
 

2.5锁消除

通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，就是jvm一种优化