并发编程——synchronized

「爱情、让人受尽委屈。」 2023-10-16 11:38 46阅读 0赞

#### 文章目录 ####

*  原子性、有序性、可见性
 *   *  原子性
     *  有序性
     *  可见性
 *  synchronized使用
 *  synchronized锁升级
 *  synchronized-ObjectMonitor

## 原子性、有序性、可见性 ##

### 原子性 ###

数据库事务的原子性：是一个最小的执行的单位，一次事务的多次操作要么都成功，要么都失败。

并发编程的原子性：一个或多个指令在CPU执行过程中不允许中断。

i++;操作是原子性？

肯定不是：i++操作一共有三个指令

![image.png][]

getfield：从主内存拉取数据到CPU寄存器

iadd：在寄存器内部对数据进行+1

putfield：将CPU寄存器中的结果更新搭配主内存中

如何保证i++是原子性？

使用synchronized、lock、Atomic（CAS）来保证

![image.png][image.png 1]

使用lock锁也会有类似的概念，也就是在操作i++的三个指令前，先基于AQS成功修改state后才可以操作

使用synchronized和lock锁时，可能会触发将线程挂起的操作，而这种操作会触发内核态和用户态的切换，从而导致消耗资源。

CAS方式就相对synchronized和lock锁的效率更高，因为CAS不会触发线程挂起操作！

CAS：compare and swap

线程基于CAS修改数据的方式：先获取主内存数据，在修改之前，先比较数据是否一致，如果一致修改主内存数据，如果不一致，放弃这次修改

CAS就是比较和交换，而比较和交换是一个原子操作

![image.png][image.png 2]

CAS在Java层面就是Unsafe类中提供的一个native方法，这个方法只提供了CAS成功返回true，失败返回false，如果需要重试策略需要自己实现

CAS问题：

*  CAS只能对一个变量的修改实现原子性。
 *  CAS存在ABA问题。
    
     *  A线程修改主内存数据从1~2，卡在了获取1之后。
     *  B线程修改主内存数据从1~2，完成。
     *  C线程修改主内存数据从2~1，完成。
     *  A线程执行CAS操作，发现主内存是1，没问题，直接修改
     *  解决方案：加版本号
 *  在CAS执行次数过多，但是依旧无法实现对数据的修改，CPU会一直调度这个线程，造成对CPU的性能损耗
    
     *  synchronized的实现方式：CAS自旋一定次数后，如果还不成，挂起线程
     *  LongAdder的实现方式：当CAS失败后，将操作的值，存储起来，后续一起添加

### 有序性 ###

指令在CPU调度执行时，CPU会为了提升执行效率，在不影响结果的前提下，对CPU指令进行重新排序。但是这样可能会造成数据的不一致。

如果不希望CPU对指定进行重排序，怎么办？

可以对属性追加volatile修饰，就不会对当前属性的操作进行指令重排序。

### 可见性 ###

CPU在处理时，需要将主内存数据拿到寄存机中再执行指令，执行完指令后，需要将寄存器数据扔回到主内存中。但是寄存器数据同步到主内存是遵循MESI协议的，简单来说就是：不是每次操作结束就将CPU缓存数据同步到主内存，这样就会造成多个线程看到的数据不一样。

所以通常需要synchronized和volatile配合解决这一问题：

*  volatile每次操作后，立即同步数据到主内存。
 *  synchronized，只有一个线程操作这个数据。

## synchronized使用 ##

使用方法：声明方法时使用synchronized或者在代码块中使用synchronized。  
锁类型：

*  类锁：基于当前类的Class加锁
 *  对象锁：基于this对象加锁

synchronized是互斥锁，每个线程获取synchronized时，基于synchronized绑定的对象去获取锁！

synchronized是如何基于对象实现的互斥锁，先了解对象再内存中是如何存储的。

![image.png][image.png 3]

在Java中查看对象的存储：

导入依赖：

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

查看对象信息

![image.png][image.png 4]

## synchronized锁升级 ##

synchronized在jdk1.6之前，一直是重量级锁：只要线程获取锁资源失败，直接挂起线程。

jdk1.6之前synchronized效率贼低，再加上Doug Lea推出了ReentrantLock，效率比synchronized快多了，导致JDK团队不得不在jdk1.6将synchronized做优化。

锁升级：

*  **无锁状态、匿名偏向状态**：没有线程拿锁。
 *  **偏向锁状态**：没有线程的竞争，只有一个线程在获取锁资源。  
    线程竞争锁资源时，发现当前synchronized没有线程占用锁资源，并且锁是偏向锁，使用CAS的方式，设置线程ID为当前线程，获取到锁资源，下次当前线程再次获取时，只需要判断是偏向锁，并且线程ID是当前线程ID即可，直接获得到锁资源。
 *  **轻量级锁**：偏向锁出现竞争时，会升级到轻量级锁。  
    轻量级锁的状态下，线程会基于CAS的方式，尝试获取锁资源，CAS的次数是基于自适应自旋锁实现的，JVM会自动的基于上一次获取锁是否成功，来决定这次获取锁资源要CAS多少次。
 *  **重量级锁**：轻量级锁CAS一段次数后，没有拿到锁资源，升级为重量级锁（其实CAS操作是在重量级锁时执行的）。重量级锁就是线程拿不到锁，就挂起。

偏向锁是延迟开启的，并且在开启偏向锁之后，默认不存在无锁状态，只存在匿名偏向synchronized因为不存在从重量级锁降级到偏向或者是轻量。

synchronized在偏向锁升级到轻量锁时，会涉及到偏向锁撤销，需要等到一个安全点，stw，才可以撤销，并发偏向锁撤销比较消耗资源。在程序启动时，偏向锁有一个延迟开启的操作，因为项目启动时，ClassLoader会加载.class文件，这里会涉及到synchronized操作。为了避免启动时涉及到偏向锁撤销，导致启动效率变慢，所以程序启动时，默认不是开启偏向锁的。

**编译器优化的结果，出现了下列效果**

*  **锁消除**：线程在执行一段synchronized代码块时，发现没有共享数据的操作，自动帮你把synchronized去掉。
 *  **锁粗化**：在一个多次循环的操作中频繁的获取和释放锁资源，synchronized在编译时，可能会优化到循环外部。

## synchronized-ObjectMonitor ##

ObjectMonitor一般是到达了重量级锁才会涉及到。在到达重量级锁之后，重量级锁的指针会指向ObjectMonitor对象。

ObjectMonitor() {
        _header       = NULL;
        _count        = 0;     // 抢占锁资源的线程个数
        _waiters      = 0,     // 调用wait的线程个数。
        _recursions   = 0;     // 可重入锁标记，
        _object       = NULL; 
        _owner        = NULL;  // 持有锁的线程
        _WaitSet      = NULL;  // wait的线程  （双向链表）
        _WaitSetLock  = 0 ;
        _Responsible  = NULL ;
        _succ         = NULL ;  // 假定的继承人（锁释放后，被唤醒的线程，有可能拿到锁资源）
        _cxq          = NULL ;  // 挂起线程存放的位置。（单向链表）
        FreeNext      = NULL ;
        _EntryList    = NULL ;  // _cxq会在一定的机制下，将_cxq里的等待线程扔到当前_EntryList里。  （双向链表）
        _SpinFreq     = 0 ;
        _SpinClock    = 0 ;
        OwnerIsThread = 0 ;
        _previous_owner_tid = 0;
      }

[image.png]: https://img-blog.csdnimg.cn/img_convert/2b384c8323cc733f432d562ec78e969a.png
[image.png 1]: https://img-blog.csdnimg.cn/img_convert/a9444f6beb4df067bd99053bc0ad410c.png
[image.png 2]: https://img-blog.csdnimg.cn/img_convert/c6df91993b202953b06410069dbffea8.png
[image.png 3]: https://img-blog.csdnimg.cn/img_convert/829c6b25f8c23ff1554ed5f48df70d11.png
[image.png 4]: https://img-blog.csdnimg.cn/img_convert/b85db8193dde61a322af48c8c48e8bec.png