-黑马JUC学习笔记-上

JAY.LIN 收录于未分类

2025-03-14 约 8986 字预计阅读 18 分钟

https://bing.ee123.net/img/rand?artid=146253469

黑马JUC学习笔记-上

1.进程与线程

1.进程与线程的概念

2.并行和并发

并发

操作系统的任务调度器可以在同一时间应对多件事情

时间片轮转

每个线程都有一个时间片在一个时间片内如果线程未执行完毕会被暂停然后将下一条将要执行的指令存在程序计数器上（类似于存档）然后切换到下一个线程继续执行避免后续的线程等待时间过长

并行

3.线程

1.创建线程

1.普通创建方式

第一种直接创建线程

第二种先创建线程然后newthread对象导入任务

2.使用lambda表达式

这里其实使用了匿名内部类（匿名内部类必须继承一个类 Runnable）

3.使用FutureTask

继承了Runnable接口

并且多了一个future接口可以用来返回对象 在线程之间传递结果

callable和runnable类似

callable可以抛出异常

callable和runnable类似 futuretask也实现了runnable接口

因此callable传入futuretask

task传入thread

2.Tread和Runnable的关系

在test2中使用了Thread t=new Thread（Runnable）传入任务的方式

在跟进源码后得知他们都会调用thread的run方法在执行run方法前会判断是否传入任务对象

3.线程运行原理

1.单线程

1.首先线程运行时先进行类加载将TestFrams加载到JVM中放入方法区

2.为main线程分配栈内存 cpu将时间片分配给main

3.JVM创建String对象放入堆中在main的栈帧中引用string对象将变量存储到局部变量表

4.调用methord1方法为方法分配栈帧并且将变量存储到局部变量表

5.不断执行方法区中的代码对变量进行操作

2.多线程

栈帧是以线程为单位的堆中创建的对象才会被线程共享这样是高并发会应发数据库各种问题的原因

栈帧与线程

在Java中，每个线程都有自己的虚拟机栈（VM Stack），每当一个方法被调用时，就会创建一个新的栈帧（Stack Frame）并将其压入当前线程的栈中。栈帧存储了方法执行期间所需的信息，比如局部变量、操作数栈等。因为这些栈是线程私有的，所以栈帧中的数据默认情况下是不会被其他线程访问到的，这就保证了线程的安全性。

堆中对象的共享

而堆（Heap）是所有线程共享的一块内存区域，用于存放对象实例。如果多个线程需要访问同一个对象，那么就存在数据竞争的可能性，除非有适当的同步机制来保护对这些共享资源的访问。这确实是导致并发问题的一个原因，例如竞态条件（Race Condition）、死锁（Deadlock）等。

3.上下文切换

上下文切换是有性能消耗的这在JVM的学习中也解释过同一个问题使用多个线程和单线程有可能单线程更快因为需要用到程序计数器上下文切换性能会有一定的下降

4.常见方法

1.start | run

start启动线程 run是执行的方法

为什么要start 如果不start线程那么会直接由主线程执行

start线程就可以调用新的线程用以实现异步的目的

如果二次启用就会报异常

2.sleep | yield

Runnable VS TimedWaiting 就绪状态和阻塞状态对比

就绪状态是主动等待时间片而阻塞状态是被迫无法接受到时间片

程序优先级

3.Join

join底层是Wait

等待某个线程运行结束

异步转同步

限时同步

4.Interrupt

sleep，wait和join被打断后都会将打断标记清空

被打断的线程并不会停止运行可以通过自己选择是否停止

被吵醒了也可以装睡）

5.Park

守护线程

5.线程状态

五种状态

操作系统层面

初始状态 ：刚刚创建了线程对象刚刚new出来的

可运行状态 ：也叫就绪状态 standby 时刻准备着接受任务接受cpu的调度

运行状态 ：获取了cpu的时间片当时间片用完就会从运行态转为可运行态

阻塞状态 ：

如果调用了阻塞API 例如：BIO读写文件这时候该线程实际不会用到CPU 会导致上下文切换加入阻塞状态等BIO操作完毕会由操作系统幻想阻塞线程转入可运行状态

终止状态 ：表示线程已经执行完毕生命周期结束

六种状态

异步的思想真的和我以前理解Redis并发问题的时候想的一样原来他叫统筹方法！

其实感觉又和拓扑排序有关系

4.共享模型知管程

1.共享带来的问题

并发安全问题产生的原因就是缺乏原子性 i++这种代码也分为好多条指令

本质原因是多个线程访问了共享资源

2.Synchronized

对象锁

语法

操作系统是独立于锁之外的

整 整体流程：

1.线程2首先获取锁由于此时没人获取锁因此线程2获取锁对象成功

2.执行指令集此时操作系统依然会进行调度在时间片用完之后进行上下文切换

3.线程1拿到时间片尝试获取锁对象但是此时锁对象依然在线程2手中线程1获取锁失败进入阻塞状态

然后进行上下文切换

4.线程2由于手中持有锁对象依然拥有对静态资源的访问权限进行写入-1操作执行完成后释放锁并且唤醒刚刚加入阻塞状态的线程1 将锁交给线程1

q1：强调原子性但是会消耗性能

q2：如果需要保护一块共享空间那么所有对这块资源操作的线程都必须只能进入一个房间（持有同一把锁）

q3：不可以不加锁就根本不会尝试获取锁那么上下文切换的时候就不会被阻塞直接修改资源

优化

采用面向对象的思想将需要保护的共享变量放入一个类

将逻辑封装

Synchronized加在方法上

加载方法上相当于锁住了成员方法但锁的依然是对象

线程八锁

为什么这样写可以“锁住对象”？
synchronized 方法本质：
当你在实例方法（如 a() 和 b()）前加 synchronized 时，等同于：

java

复制

public void a() {

synchronized(this) { // 锁的是当前对象实例（n1）

// 方法体

}

锁对象就是 this（即调用方法的对象实例 n1）。

两个线程操作同一个对象（n1）：

线程1调用 n1.a()，会先获取 n1 的锁。

线程2调用 n1.b()，也需要获取 n1 的锁，但此时锁已被线程1持有，所以线程2必须等待。

最终效果：a() 和 b() 不会同时执行，保证互斥。

this 指的是什么？
this 是当前对象实例：
在 a() 和 b() 中，this 都指向 Number 类的实例 n1。

两个同步方法共享同一把锁（n1 对象本身的锁）。

如果创建多个 Number 对象（如 n1、n2），每个对象的锁是独立的，不会互相干扰。

对于普通同步方法，锁的是当前实例对象，对于静态方法，锁的是类的class对象

a锁的是当前类对象class

b锁的是实例对象thi

n1.a锁了number

n1.b锁了n1

首先，静态方法（Static Methods）是属于类本身的，而不是类的某个具体实例。这意味着即使没有创建类的对象，也可以直接通过类名调用静态方法。

静态方法在类加载时就被分配内存，且在整个应用程序生命周期中只存在一份。这对于频繁使用的工具方法来说更加高效，因为它们不需要随着对象的创建和销毁而重复分配内存。

静态方法 ：
- 不能访问实例变量或实例方法 ，强制开发者分离无关状态的操作。
- 例如， StringUtils.isEmpty(str) 不依赖任何对象状态，仅处理输入参数。
实例方法 ：
- 可自由访问实例变量和其他实例方法，支持对象状态的封装和操作。
- 例如， Car.startEngine() 需要检查燃油量（实例变量）并触发引擎行为。

3.线程安全问题分析

1.成员变量和静态变量是否线程安全

1.如果没有被共享：安全

局部变量会在各自线程虚拟机栈中创建栈帧

2.如果被共享

如果只有读操作：安全

如果有读写操作：不安全

2.局部变量是否线程安全

创建子类访问父类中的局部变量资源儿子坑爹这也是访问修饰符的存在意义避免子类覆盖父类的方法

1.局部变量是线程安全的

2.局部变量引用的对象则未必：

如果对象没有逃离方法的作用范围：安全

如果对象逃离方法的作用范围：不安全

4.常见线程安全类

与前面的例子读写分离时发生的线程安全一致

5.不可变类线程安全性

String：

subString 每次都会创建新的字符串（不会覆盖）因此不会对原有的字符串进行改变

HashMap不是线程安全的 HashTable线程安全

String 是不可变量线程安全

Date可变不是线程安全

解释：虽然start是private的，但是可以通过调用before来实现对start的修改，又因为它是成员变量，不是局部变量，生命周期是从类的创建到消亡，因此在堆内存中只有一份。所以不是线程安全的这个start是单例的z

总结…无状态（没有成员变量），不可变（成员变量不被修改）就是对应没有共享变量，没有写操作

这里的dao只有一份导致userdao的connectiopn（成员方法只有一份）因此会被共享

6.Synchronized底层

1.Monitor

当对象获得锁后会将 markword的标记值更改 markword就是专门记录标记的区域

并且把操作系统中的monitor的值传入markword中记录

由于没有其他人获得锁因此获取锁成功成为owner

上锁流程：

1.线程首先尝试获取锁将obj对象与操作系统monitor相关联

2.使用指针将OBJ对象中的markWord指向monitor

3.然后操作系统的owner就指向Thread2

此时如果thread1 尝试获取obj锁：

1.检查obj是否关联了monitor 锁

2.检查owner是否关联了线程

3.失败将thread1加入EntryList （阻塞队列）并且进入阻塞状态

当thread2执行完后就会唤醒队列中等待的线程（此时竞争是非公平的）将owner交给线程

7.轻量级锁

1.上锁流程

1.在每个线程的栈帧中存储锁记录LockRecord（JVM层面）的信息

ObjectReference记录对象地址

2.将锁记录的数据和锁对象markword的数据交换表示加锁

3.成功交换如下

4.如果失败分为两种情况：

进入锁膨胀阶段

如果是自己执行加锁即—锁重入那么会再添加一条LockRecord作为重入的条数

5.解锁过程：

2.锁膨胀

1.获取锁失败事态升级！变为重量级锁

2.修改Markword 锁升级改为monitor锁

并且线程1进入阻塞但是此时线程1还是轻量级锁类似商场扶梯没人慢慢走有人就加速

3.解锁流程改变线程0还原地址的时候失败

进入重量级锁解锁流程

3.自旋优化

为了避免上下文切换（消耗性能）那么就选择多等一会（等不到公交就多等一会毕竟已经等了一段时间了实在不行再走回家）

单核CPU同一时间只能运行一个线程。如果有线程在自旋等待锁，而锁被另一个线程持有，但那个线程无法运行，因为CPU被自旋的线程占用了。这样会导致持有锁的线程得不到执行，无法释放锁，自旋的线程就会一直空转，无法继续下去，形成死锁吗？或者说，这种情况会导致系统无法调度，因为自旋的线程占用了CPU，其他线程无法运行，所以锁无法释放，从而自旋的线程永远等不到锁，导致CPU空转，浪费资源。

等了也是拜登！

4.偏向锁

为什么要比较获得是不是自己的锁？

并发安全主要还是因为多个线程操作共享资源

如果是自己线程获得了锁那就不用竞争锁自己总不会撞自己的车吧

偏向状态

偏向锁的设计初衷是为了减少无竞争情况下的同步开销。当一个线程访问同步块时，会在对象头和栈帧的锁记录中存储线程ID，之后该线程进入和退出同步块时不需要进行CAS操作，只需检查线程ID是否一致。这样可以减少轻量级锁使用CAS带来的开销。然后是偏向锁与轻量级锁的关系。轻量级锁是通过CAS操作来尝试获取锁，适用于线程交替执行的情况，但如果有竞争，会升级为重量级锁。而偏向锁是在无竞争的情况下，直接偏向第一个访问的线程，省去了后续的同步操作。当出现另一个线程尝试获取锁时，偏向锁会撤销，升级为轻量级锁或重量级锁。因此，偏向锁可以看作是轻量级锁的一个优化，只有在无竞争时才有效，有竞争时则退化为轻量级锁。

如果可偏向的对象调用了hashcode就会取消偏向锁因为对象头只能存32位 hashcode占用了偏向锁的位置

为什么重量级锁可以直接调用？

因为重量级锁是存在monitor的而偏向锁是存在对象头中

一、偏向锁的特点

适用场景
单线程重复访问同步代码块：若一个同步代码块始终被同一个线程访问，偏向锁会直接记录该线程ID，后续无需任何同步操作。

无实际竞争：在代码逻辑上存在“同步”，但运行时没有多线程竞争。

核心机制
对象头标记：在对象头的 Mark Word 中记录偏向线程ID，以及偏向时间戳（epoch）。

免同步：一旦偏向锁生效，线程进入同步块时无需任何 CAS 操作，只需检查线程ID是否匹配。

延迟启用：JVM 默认在程序启动后几秒（约 4 秒）才启用偏向锁，以避免初始阶段的锁撤销开销。

优缺点
优点：无竞争时性能极高（几乎无开销）。

缺点：

锁撤销（Revoke）成本高：当其他线程尝试获取锁时，需撤销偏向锁并升级为轻量级锁。

不适合高竞争场景：频繁竞争会导致反复锁撤销，反而降低性能。

二、轻量级锁的特点

适用场景
低竞争的多线程交替执行：线程交替访问同步代码块，但不会同时竞争锁（即不存在锁膨胀为重量级锁的条件）。
核心机制
CAS 操作：通过 CAS 操作将对象头的 Mark Word 替换为指向线程栈中锁记录（Lock Record）的指针。

自旋优化：若 CAS 失败，线程会短暂自旋重试（避免直接升级为重量级锁）。

锁记录：在栈帧中存储锁对象的原始 Mark Word 和锁状态。

优缺点
优点：低竞争时性能优于重量级锁（无需操作系统介入）。

缺点：

自旋消耗 CPU：若竞争激烈，自旋会导致 CPU 空转。

不适用于长临界区：长时间占用锁会触发膨胀为重量级锁。

三、偏向锁与轻量级锁的关系

锁升级流程
无竞争时：对象初始为无锁状态 → 第一次访问时升级为偏向锁。

出现竞争时：

偏向锁 → 轻量级锁：当第二个线程尝试获取偏向锁，JVM 会撤销偏向锁，升级为轻量级锁（通过 CAS 竞争）。

轻量级锁 → 重量级锁：若自旋失败或竞争加剧，轻量级锁膨胀为重量级锁（依赖操作系统互斥量）。

性能对比
特性偏向锁轻量级锁重量级锁
适用场景单线程重复访问低竞争的多线程交替访问高竞争、长临界区
同步开销几乎无开销 CAS 自旋操作系统互斥量（线程阻塞）
竞争处理直接升级为轻量级锁自旋失败后升级为重量级锁无升级
典型应用单例模式、工具类短暂并发操作（如计数器）数据库连接池、复杂事务

偏向状态的撤销

1.调用hashcode

2.其他线程使用对象

其他的线程加入争抢锁对象偏向锁升级为轻量级锁

批量重偏向

偏向锁会加在第一个尝试获取锁的线程对象但是如果多次有其他线程来尝试获取锁那么jvm就会认为第一次的偏向是错的批量的冲偏向到其他线程

批量撤销

5.锁消除

逃逸分析

8.Wait-Notify

sleep和wait的区别

1.方法继承类不同

2.wait需要获得锁的使用权

3.wait会释放锁

9.Park-UnPark

为什么先执行unpark再park也可以继续执行？

Park和Unpark的原理

先park后unpark：

thread进入parker对象（区域） park就是观察counter（看看有没有干粮）如果parker为1就继续运行没有就进入condition（休息）并且把counter设置为0

unpark后将counter设置为1（补充干粮）唤醒thread 恢复运行后将counter设置为0

10.重新理解线程状态

11.多把锁

可以采用多把锁提高并发度

1.线程活跃性

1.死锁

定位死锁：

使用jps查看pid

使用jstack查看线程状态

2.哲学家就餐问题

3.活锁

死锁：两个线程互相持有一个锁并且等待对方释放锁 —对峙

活锁：两个线程没有阻塞由于改变了对方的结束条件 —僵持

可以增加睡眠时间让线程交错来避免活锁

12.ReentranLock

Condition
与 ReentrantLock 结合使用，可以实现类似 Object 监视器方法（如 wait() , notify() , 和 notifyAll() ）的功能。每个 Condition 实例都与一个 ReentrantLock 实例关联，允许线程在满足某些条件前等待，或者在条件满足时通知其他线程。

继承 `ReentrantLock` 的目的

当你的类继承了 ReentrantLock ，你实际上是让这个类拥有了锁的能力，使得你可以在这个类中方便地使用锁来保护临界区代码，避免并发访问的问题。此外，你可以通过调用 newCondition() 方法来创建一个或多个 Condition 对象，这些对象依赖于该锁进行操作。

但是，继承 ReentrantLock 并不意味着“自动获得锁”或者“condition就自动获得了锁”。实际上，你需要显式地调用 lock.lock() 来获取锁，并在操作完成后调用 lock.unlock() 来释放锁。对于 Condition ，同样需要先获取锁才能调用它的 await() 或 signal() 方法。

1.可重入

@Slf4j
public class demo8 {
    private static ReentrantLock reentrantLock = new ReentrantLock();

    public static void main(String[] args) {
        reentrantLock.lock();
        try {
            log.debug("enter main");
            m1();
        }finally {
            reentrantLock.unlock();
        }
    }
    public static void m1(){
        reentrantLock.lock();
        try {
            log.debug("enter m1");
            m2();
        }finally {
            reentrantLock.unlock();
        }
    }public static void m2(){
        reentrantLock.lock();
        try {
            log.debug("enter m2");
        }finally {
            reentrantLock.unlock();
        }
    }
}

2.可打断（被动取消等待）

使用lockInterruptibly（）

如果直接使用lock方法是无法被打断的防止死锁的一种机制

3.锁超时（主动取消等待）

4.公平锁

5.条件变量

@Slf4j
public class demo9 {
    static  final ReentrantLock lock=new ReentrantLock();
    static final Condition condition = lock.newCondition();
    static  boolean t2Runned=false;
    public static void main(String[] args) {
        Thread t1 = new Thread(() -> {
            lock.lock();
            try{
                while (!t2Runned){
                    try {
                        condition.await();
                    } catch (InterruptedException e) {
                        throw new RuntimeException(e);
                    }
                }
                log.debug("1");
            }finally {
                lock.unlock();
            }
        }, "t1");

        Thread t2 = new Thread(() -> {
            lock.lock();
            try{
                log.debug("2");
                t2Runned=true;
                condition.signal();
            }finally {
                lock.unlock();
            }

        }, "t2");
        t1.start();
        t2.start();


    }
}

13.小结

在JVM层面实现的Monitor是使用Synchronized 的锁

而在Java层面实现的是ReentranLock

5.共享模型之内存（JMM JAVA内存模型）

不会停下来

不走static 直接将run缓存下来类似中间层

其实也是数据不一致带来的问题

1.可见性

Volatile

更加轻量级在解决可见性的问题

易变关键字修饰成员变量和静态变量用于避免线程从工作缓存中查找变量的值

必须到主存上查找变量的值

volatile static boolean run=true;

public static void main(String[] args) throws InterruptedException {
    new Thread(()->{
        while (run){

        }
    }).start();

    Thread.sleep(1000);
    System.out.println("停止");
    run=true;
}

可见性与原子性

Synchronized既可以保证原子也可以保证可见但是比较消耗性能

2.Volatile原理

指令重排序的目的主要是提高运行效率

可以使用Volatile来禁止指令重排序

1.如何保证可见性

通过读屏障和写屏障

写屏障：在写屏障之前的所有对共享变量的改动都会同步到主存之中防止指令跑到屏障之后

读屏障：在读屏障之前对共享变量的读取都会访问主存防止指令跑到屏障之前

2.如何保证有序性

volatile不能解决原子性问题即指令的交错执行

Volatile解决的是单线程的指令重排的问题但是如果是多线程就难免交错

总结： Volatile是用来解决有序性和可见性的

3.DCL

Double Check Locking

这样加锁的方法有什么问题：

性能受限：在每次调用getInstance都会加入同步代码块但其实只需要在第一次加入代码块的时候保护起来然后更改instance就可以了

解决：

但是这样操作任然是存在问题的：并发问题指令重排

1.首先先行的线程率先对instance变量进行赋值

2.而由于在同步代码块外面还有一次对instance的引用就导致instance的暴露

其他线程获取到了instance

3.由于在率先的线程中已经对instance进行了赋值就可以直接进行后续的代码执行

变量暴露问题 ：

- 假设线程 A 执行到 INSTANCE = new Singleton(); 时，由于指令重排，它可能先将未初始化的对象引用赋值给 INSTANCE ，然后才开始初始化对象。
- 如果此时另一个线程 B 访问 getInstance() 方法，并且刚好跳过了同步块（因为 INSTANCE 已经不为 null ），那么 B 可能会拿到一个尚未完全初始化的对象引用。

真正解决：

采用Volatile 组织指令重排

读屏障（Acquire Barrier）和写屏障（Release Barrier）的设计是为了确保内存操作的顺序性，以维护程序在并发环境下的正确性。理解为什么读屏障要保证指令在屏障之前完成而写屏障确保指令在屏障之后完成，需要从它们各自解决的问题出发。

读屏障（Acquire Barrier）

目的：确保所有后续的读操作不会看到任何在读屏障之前未完成的操作结果。换句话说，它确保了在此之前的所有读取操作都已完成，并且任何共享变量的更新都能被当前线程看到。
原因：当一个线程试图获取某个锁或进入临界区时，读屏障确保该线程能看到所有由其他线程释放该锁之前所做的更改。这样可以避免由于乱序执行导致的数据不一致问题。例如，在一个多线程环境中，如果线程A修改了一些共享数据并释放了一个锁，那么随后获得该锁的线程B必须能够看到线程A所做的所有修改。

写屏障（Release Barrier）

目的：确保所有在此之前的写操作都已完成，之后的操作可以看到这些变化。这保证了对于共享资源的所有修改在这个点上都是可见的。

原因：当一个线程准备释放一个锁或者发布（publish）一个对象到另一个线程时，写屏障确保在此之前的所有写操作都已对外可见。这意味着任何后续的读操作（可能发生在另一个线程中）都能够看到这些修改。例如，如果线程A对共享数据进行了修改，并通过某种方式通知了线程B（比如解锁或发送信号），则需要确保所有这些修改都已经完成并且是可见的，以便线程B能够看到最新的状态。

总结来说，读屏障和写屏障分别用于不同的同步场景，前者关注的是确保读取操作前的所有相关操作都已完成，后者则确保写入操作的结果对后续操作（特别是其他线程的操作）是可见的。这种机制是保障多线程环境下数据一致性和程序正确性的基础。

说白了

读屏障保证读取的一定是最新数据

写屏障保证写操作一定全部执行完

这样就解决了上面构造方法未执行完毕就读取的问题

4.Happens-Before

几个对线程可见性的方法

小结

1.为什么加Final

避免子类覆盖父类方法破坏单例

2.序列化怎么防止破坏单例（序列化会创建新的对象）

返回自己原先的对象

3.为什么需要设置为私有能否防止反射

不能防止

4.可以因为这样对象是在类加载时就创建的没有并发安全

重新认识：

为什么要DOUBLECHECK？

可以自行模拟

1.在多线程情况下线程1率先判断发现instance为空加入Synchronize 获得锁执行同步代码块

2.线程2在线程1释放锁之前尝试获取锁失败进入阻塞队列

3.线程1 释放锁线程2获得锁假设没有第二条判断 此时就会又一次的新建一个对象

6.共享模型之无锁

1.CAS与Volatile

package org.example.JUC;

import java.util.ArrayList;
import java.util.concurrent.atomic.AtomicInteger;

public class demo15 {
    public static void main(String[] args) {
        Account account=new AccountCas(10000);
        Account.demo(account);
    }

}
class AccountCas implements Account{
    private AtomicInteger balance;

    public AccountCas(int balance){
        this.balance=new AtomicInteger(balance);
    }
    @Override
    public Integer getBalance() {
        return balance.get();
    }

    @Override
    public void withDraw(Integer ammount) {
        while (true){
            int pre=balance.get();
            int next=pre-ammount;
            if (balance.compareAndSet(pre,next)){
                break;
            }
        }
    }
}
class AccountSyn implements Account{

    private Integer balance;
    public AccountSyn(Integer balance){
        this.balance=balance;
    }
    @Override
    public Integer getBalance() {
        return this.balance;
    }

    @Override
    public void withDraw(Integer ammount) {
        synchronized (this){
            this.balance-=ammount;
        }
    }
}
interface Account{

    Integer getBalance();
    void withDraw(Integer ammount);
    static void demo(Account account){
        ArrayList<Thread> ts = new ArrayList<>();
        for(int i=0;i<1000;i++){
            ts.add(new Thread(()->{
                account.withDraw(10);
            }));

        }
        long start=System.nanoTime();
        ts.forEach(Thread::start);;
        ts.forEach(t->{
            try {
                t.join();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
        long  end=System.nanoTime();
        System.out.println(account.getBalance()+"        cost:"+(end-start)/1000_000+"ms");
    }
}

因为cas需要数据的实时性因此需要volatile来保证他的数据最新

Volatile

CAS特点

CAS操作执行时，首先检查内存位置V处的值是否等于预期值A。如果是，则将内存位置V更新为新值B，并返回成功；如果不是，则不执行任何操作，并返回失败。整个过程必须是原子的，这意味着一旦一个线程开始执行CAS操作，在它完成之前，不会有其他线程能够修改内存位置V的值。

适用于无锁并发特别是在线程数少 CPU多的情况下

2.原子整数

3.原子引用

ABA问题

Cas无法判断共享变量是否被修改过

无法感知其他线程对变量的操作

解决：

AtomicStampedReference

版本号法

AtomicMarkableReference

原子数组

函数式编程

目录

-黑马JUC学习笔记-上

黑马JUC学习笔记-上

1.进程与线程

1.进程与线程的概念

2.并行和并发

并发

并行

3.线程

1.创建线程

1.普通创建方式

2.使用lambda表达式

3.使用FutureTask

2.Tread和Runnable的关系

3.线程运行原理

1.单线程

2.多线程

3.上下文切换

4.常见方法

1.start | run

2.sleep | yield

程序优先级

3.Join

限时同步

4.Interrupt

5.Park

守护线程

5.线程状态

五种状态

六种状态

4.共享模型知管程

1.共享带来的问题

2.Synchronized

对象锁

语法

优化

Synchronized加在方法上

线程八锁

3.线程安全问题分析

1.成员变量和静态变量是否线程安全

2.局部变量是否线程安全

4.常见线程安全类

5.不可变类线程安全性

6.Synchronized底层

1.Monitor

7.轻量级锁

1.上锁流程

2.锁膨胀

3.自旋优化

4.偏向锁

偏向状态

偏向状态的撤销

1.调用hashcode

2.其他线程使用对象

批量重偏向

批量撤销

5.锁消除

8.Wait-Notify

9.Park-UnPark

Park和Unpark的原理

10.重新理解线程状态

11.多把锁

1.线程活跃性

1.死锁

2.哲学家就餐问题

3.活锁

12.ReentranLock

继承 ReentrantLock 的目的

1.可重入

2.可打断（被动取消等待）

3.锁超时（主动取消等待）

4.公平锁

5.条件变量

13.小结

5.共享模型之内存（JMM JAVA内存模型）

1.可见性

Volatile

可见性与原子性

2.Volatile原理

1.如何保证可见性

继承 `ReentrantLock` 的目的