JAVA 并发编程 (一)

最新推荐文章于 2025-12-08 09:18:56 发布

原创最新推荐文章于 2025-12-08 09:18:56 发布 · 984 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#java #开发语言 #jvm

一、并发编程

并发编程三大特性

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

1.1 原子性

数据库的事务：ACID

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

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

i++;操作是原子性？

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

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

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

putfield：将CPU寄存器中的结果甩到主内存中

如何保证i++是原子性的。

锁：synchronized，lock，Atomic（CAS）

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

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

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

CAS：compare and swap

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

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

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失败后，将操作的值，存储起来，后续一起添加

CAS：在多核情况下，有lock指令保证只有一个线程在执行当前CAS

1.2 有序性

指令在CPU调度执行时，CPU会为了提升执行效率，在不影响结果的前提下，对CPU指令进行重新排序。

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

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

什么时候指令重排：满足happens-before原则，即可重排序

单例模式-DCL双重判断。

申请内存，初始化，关联是正常顺序，如果CPU对指令重排，可能会造成

申请内存，关联，初始化，在还没有初始化时，其他线程来获取数据，导致获取到的数据虽然有地址引用，但是内部的数据还没初始化，都是默认值，导致使用时，可能出现与预期不符的结果

1.3 可见性

可见性：前面说过CPU在处理时，需要将主内存数据甩到我的寄存机中再执行指令，指向完指令后，需要将寄存器数据扔回到主内存中。倒是寄存器数据同步到主内存是遵循MESI协议的，说人话就是，

不是每次操作结束就将CPU缓存数据同步到主内存。造成多个线程看到的数据不一样。

volatile每次操作后，立即同步数据到主内存。

synchronized，触发同步数据到主内存。

final，也可以解决可见性问题。

二、synchronized使用

2.1 synchronized的使用方式

synchronized方法

synchronized代码块

类锁和对象锁：

类锁：基础当前类的Class加锁

对象锁：基于this对象加锁

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

synchronized锁是基于对象实现的！

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

在Java中查看。

导入依赖：

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

查看对象信息

初始化的对象是无锁状态

三、synchronized锁升级

synchronized在jdk1.6之前，一直是重量级锁：只要线程获取锁资源失败，直接挂起线程（用户-内核）

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

锁升级：

无锁状态、匿名偏向状态：没有线程拿锁。
偏向锁状态：没有线程的竞争，只有一个线程再获取锁资源。
线程竞争锁资源时，发现当前synchronized没有线程占用锁资源，并且锁是偏向锁，使用CAS的方式，设置o的线程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;
  }

偏向锁会降级到无锁状态嘛？怎么降？

会，当偏向锁状态下，获取当前对象的hashcode值，会因为对象头空间无法存储hashcode，导致降级到无锁状态。