谈一谈对synchronized的理解

朴灿烈づ我的快乐病毒、 2022-11-30 12:51 81阅读 0赞

## Java对象的构成 ##

在 JVM 中，对象在内存中分为三块区域：  
**对象头**

*  Mark Word（标记字段）：默认存储对象的HashCode，分代年龄和锁标志位信息。它会根据对象的状态复用自己的存储空间，markword数据的长度在32位和64位的虚拟机（未开启压缩指针）中分别为32bit和64bit，它的最后2bit是锁状态标志位，用来标记当前对象的状态，对象的所处的状态，决定了markword存储的内容，如下表所示:  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70_pic_center]  
    32位虚拟机在不同状态下markword结构如下图所示：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70_pic_center 1]
 *  Klass Point（类型指针）：对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

**实例数据**

*  这部分主要是存放类的数据信息，父类的信息。

**对其填充**

*  由于虚拟机要求对象起始地址必须是8字节的整数倍，填充数据不是必须存在的，仅仅是为了字节对齐。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70_pic_center 2]

## synchronized加锁，synchronized 是最常用的线程同步手段之一 ##

synchronized 应用在方法上时，在字节码中是通过方法的 ACC\_SYNCHRONIZED 标志来实现的。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70_pic_center 3]

synchronized 应用在同步块上时，在字节码中是通过 monitorenter 和 monitorexit 实现的。

每个对象都会与一个monitor相关联，当某个monitor被拥有之后就会被锁住，当线程执行到monitorenter指令时，就会去尝试获得对应的monitor。

步骤如下：

每个monitor维护着一个记录着拥有次数的计数器。未被拥有的monitor的该计数器为0，当一个线程获得monitor（执行monitorenter）后，该计数器自增变为 1 。

当同一个线程再次获得该monitor的时候，计数器再次自增；

当不同线程想要获得该monitor的时候，就会被阻塞。

当同一个线程释放 monitor（执行monitorexit指令）的时候，计数器再自减。

当计数器为0的时候，monitor将被释放，其他线程便可以获得monitor。

同样看一下反编译后的一段锁定代码块的结果：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70_pic_center 4]  
小结：  
同步方法和同步代码块底层都是通过monitor来实现同步的。

两者的区别：同步方式是通过方法中的access\_flags中设置ACC\_SYNCHRONIZED标志来实现，同步代码块是通过monitorenter和monitorexit来实现。

每个对象都与一个monitor相关联，而monitor可以被线程拥有或释放。

但是，随着 Java SE 1.6 对 synchronized 进行了各种优化之后，有些情况下它就并不那么重，Java SE 1.6 中为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁。

针对 synchronized 获取锁的方式，JVM 使用了锁升级的优化方式，就是先使用偏向锁优先同一线程然后再次获取锁，如果失败，就升级为 CAS 轻量级锁，如果失败就会短暂自旋，防止线程被系统挂起。最后如果以上都失败就升级为重量级锁。  
![在这里插入图片描述][20200824170322804.png_pic_center]  
Linux系统的用户态和内核态的切换很耗资源，其实就是线程的等待唤起过程，那怎么才能减少这种消耗呢？

自旋，过来的现在就不断自旋，防止线程被挂起，一旦可以获取资源，就直接尝试成功，直到超出阈值，自旋锁的默认大小是10次，-XX：PreBlockSpin可以修改。

自旋都失败了，那就升级为重量级的锁，像1.5的一样，等待唤起咯。  
![在这里插入图片描述][20200824174605132.png_pic_center]  
synchronized的执行过程：

1.  检测Mark Word里面是不是当前线程的ID，如果是，表示当前线程处于偏向锁
2.  如果不是，则使用CAS将当前线程的ID替换Mard Word，如果成功则表示当前线程获得偏向锁，置偏向标志位1
3.  如果失败，则说明发生竞争，撤销偏向锁，进而升级为轻量级锁。
4.  当前线程使用CAS将对象头的Mark Word替换为锁记录指针，如果成功，当前线程获得锁
5.  如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。
6.  如果自旋成功则依然处于轻量级状态。
7.  如果自旋失败，则升级为重量级锁。

上面几种锁都是JVM自己内部实现，当我们执行synchronized同步块的时候jvm会根据启用的锁和当前线程的争用情况，决定如何执行同步操作；

在所有的锁都启用的情况下线程进入临界区时会先去获取偏向锁，如果已经存在偏向锁了，则会尝试获取轻量级锁，启用自旋锁，如果自旋也没有获取到锁，则使用重量级锁，没有获取到锁的线程阻塞挂起，直到持有锁的线程执行完同步块唤醒他们；

偏向锁是在无锁争用的情况下使用的，也就是同步开在当前线程没有执行完之前，没有其它线程会执行该同步块，一旦有了第二个线程的争用，偏向锁就会升级为轻量级锁，如果轻量级锁自旋到达阈值后，没有获取到锁，就会升级为重量级锁；

如果线程争用激烈，那么应该禁用偏向锁。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/f23ce21de78547839bdb4e0e144506b0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/439b2eb372d943e88ff8a0b8b5caf415.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/5ddabe8098c142daae22364e85989b54.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/72d258737d2d45a3b216f314ce6e6a75.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzIxNzA2NQ_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/c15f7c666e514ad68ec7e655a2d311ed.png
[20200824170322804.png_pic_center]: /images/20221123/77ada30542c44c499efed2f429f1818c.png
[20200824174605132.png_pic_center]: /images/20221123/234d0a6456864f58a863308e6db9a565.png