代码编织梦想

CPU、内存、I/O 设备,有一个核心矛盾就是这三者的速度差异。

为了合理利用 CPU 的高性能,平衡这三者的速度差异:

1、CPU 增加了缓存,以均衡与内存的速度差异;
2、操作系统增加了进程、线程,以分时复用 CPU,进而均衡 CPU 与 I/O 设备的速度差异;
3、编译程序优化指令执行次序,使得缓存能够得到更加合理地利用。

缓存导致的可见性问题

多核时代,线程 A 操作的是 CPU-1 上的缓存,而线程 B 操作的是 CPU-2 上的缓存,这个时候线程 A 对变量 V 的操作对于线程 B 而言就不具备可见性了。
在这里插入图片描述

线程切换带来的原子性问题

任务切换的时机大多数是在时间片结束的时候,我们现在基本都使用高级语言编程,高级语言里一条语句往往需要多条 CPU 指令完成。count += 1,至少需要三条 CPU 指令:

指令 1:首先,需要把变量 count 从内存加载到 CPU 的寄存器;
指令 2:之后,在寄存器中执行 +1 操作;
指令 3:最后,将结果写入内存(缓存机制导致可能写入的是 CPU 缓存而不是内存)。

操作系统做任务切换,可以发生在任何一条CPU 指令执行完。

假设 count=0,如果线程 A 在指令 1 执行完后做线程切换,线程 A 和线程 B 按照下图的序列执行,那么我们会发现两个线程都执行了 count+=1 的操作,但是得到的结果不是我们期望的 2,而是 1。

在这里插入图片描述

把一个或者多个操作在 CPU 执行的过程中不被中断的特性称为原子性。CPU 能保证的原子操作是 CPU 指令级别的,而不是高级语言的操作符。因此,很多时候需要在高级语言层面保证操作的原子性。

编译优化带来的有序性问题

编译器为了优化性能,有时候会改变程序中语句的先后顺序

Java 领域一个经典的案例就是利用双重检查创建单例对象,代码:在获取实例 getInstance() 的方法中,我们首先判断 instance 是否为空,如果为空,则锁定 Singleton.class 并再次检查 instance
是否为空,如果还为空则创建 Singleton 的一个实例。

public class Singleton {
    public static Singleton instance;

    private Singleton() {
    }

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null)
                    instance = new Singleton();
            }
        }
        return instance;
    }
}

这个 getInstance() 方法并不完美。问题出在 new 操作上,我们以为的 new 操作应该是:

1、分配一块内存 M;
2、在内存 M 上初始化 Singleton 对象;
3、然后 M 的地址赋值给 instance 变量。

实际上优化后的执行路径却是这样的

1、分配一块内存 M;
2、将 M 的地址赋值给 instance 变量;
3、最后在内存 M 上初始化 Singleton 对象。

假设线程 A 先执行 getInstance() 方法,当执行完指令 2 时恰好发生了线程切换,切换到了线程 B 上;如果此时线程 B 也执行 getInstance() 方法,那么线程 B 在执行第一个判断时会发现 instance !=
null ,所以直接返回 instance,而此时的 instance 是没有初始化过的,如果我们这个时候访问 instance 的成员变量就可能触发空指针异常。

在这里插入图片描述

Java解决可见性和有序性问题

导致可见性的原因是缓存,导致有序性的原因是编译优化,那解决可见性、有序性合理的方案应该是按需禁用缓存以及编译优化,指按照程序员的要求来禁用。

Java 内存模型规范了 JVM 如何提供按需禁用缓存和编译优化的方法。这些方法包括 volatile、synchronized 和 final 三个关键字,以及六项 Happens-Before 规则。

volatile

volatile 关键字并不是 Java 语言(禁用缓存以及编译优化)的特产,古老的 C 语言里也有,它最原始的意义就是禁用 CPU 缓存。

声明一个 volatile 变量 volatile int x = 0,它表达的是:告诉编译器,对这个变量的读写,不能使用 CPU 缓存,必须从内存中读取或者写入。

Happens-Before 规则

在 Java 语言里面,Happens-Before 的语义本质上是一种可见性,A Happens-Before B 意味着 A 事件对 B 事件来说是可见的,无论 A 事件和 B 事件是否发生在同一个线程里。

Happens-Before 要表达的是:前面一个操作的结果对后续操作是可见的。Happens-Before 约束了编译器的优化行为,虽允许编译器优化,但是要求编译器优化后一定遵守 Happens-Before 规则。

class VolatileExample {
    int x = 0;
    volatile boolean v = false;

    public void writer() {
        x = 42;
        v = true;
    }

    public void reader() {
        if (v == true) {
            // 这里 x 会是多少呢?
// 这个要看 Java 的版本,如果在低于 1.5 版本上运行,x 可能是 42,也有可能是 0;如果在 1.5 以上的版本上运行,x 就是等于 42。Java 内存模型在 1.5 版本对 volatile 语义进行了增强(Happens-Before 传递性)
        }
    }
}
  • 1、程序的顺序性规则

    一个线程中,按照程序顺序,前面的操作 Happens-Before 于后续的任意操作

  • 2、volatile 变量规则

    对一个 volatile 变量的写操作, Happens-Before 于后续对这个 volatile 变量的读操作。

  • 3、传递性

    如果 A Happens-Before B,且 B Happens-Before C,那么 A Happens-Before C
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zfAddSPJ-1664763368864)(pic/传递性规则.png)]

    1、“x=42” Happens-Before 写变量 “v=true” ,这是 程序的顺序性规则;
    2、写变量“v=true” Happens-Before 读变量 “v=true”,这是volatile 变量规则;
    3、再根据传递性规则,得到结果:“x=42” Happens-Before 读变量“v=true”。

    如果线程 B 读到了“v=true”,那么线程 A 设置的“x=42”对线程 B 是可见的。(这就是 1.5 版本对 volatile 语义的增强)

  • 4、管程中锁的规则

    一个锁的解锁 Happens-Before 于后续对这个锁的加锁

    管程是一种通用的同步原语,在 Java 中指的就是 synchronized,synchronized 是 Java 里对管程的实现。
    管程中的锁在 Java 里是隐式实现的,例如下面的代码,在进入同步块之前,会自动加锁,而在代码块执行完会自动释放锁,加锁以及释放锁都是编译器帮我们实现的。

    synchronized (this) { // 此处自动加锁
      // x 是共享变量, 初始值 =10
      if (this.x < 12) {
          this.x = 12;
      }  
    } // 此处自动解锁
    

    假设 x 的初始值是 10,线程 A 执行完代码块后 x 的值会变成 12(执行完自动释放锁),线程 B 进入代码块时,能够看到线程 A 对 x 的写操作,也就是线程 B 能够看到 x==12。

  • 5、线程 start() 规则

    主线程 A 启动子线程 B 后,子线程 B 能够看到主线程在启动子线程 B 前的操作。所谓的“看到”,指的是对共享变量的操作。

     // 在线程 A 中启动线程 B,那么该 start() 操作 Happens-Before 于线程 B 中的任意操作。
     Thread B = new Thread(()->{
       // 主线程调用 B.start() 之前
       // 所有对共享变量的修改,此处皆可见
       // 此例中,var==77
     });
     // 此处对共享变量 var 修改
     var = 77;
     // 主线程启动子线程
     B.start();
    
  • 6、线程 join() 规则

    主线程 A 等待子线程 B 完成(主线程 A 通过调用子线程 B 的 join() 方法实现),当子线程 B 完成后(主线程 A 中 join() 方法返回),主线程能够看到子线程的操作。所谓的“看到”,指的是对共享变量的操作。

    //在线程 A 中,调用线程 B 的 join() 并成功返回,那么线程 B 中的任意操作 Happens-Before 于该 join() 操作的返回
    Thread B = new Thread(()->{
      // 此处对共享变量 var 修改
      var = 66;
    });
    // 例如此处对共享变量修改,
    // 则这个修改结果对线程 B 可见
    // 主线程启动子线程
    B.start();
    B.join()
    // 子线程所有对共享变量的修改
    // 在主线程调用 B.join() 之后皆可见
    // 此例中,var==66
    
  • 7、线程中断规则

    对线程interrupt()方法的调用 Happens-Before 于被中断线程的代码检测到中断事件的发生
    对线程中断操作 Happens-Before 于该线程中断之前
    可以通过Thread.interrupted()方法检测到是否有中断发生。

  • 8、对象终结规则

    一个对象的初始化完成(构造函数执行结束) Happens-Before 于它的finalize()方法的开始。

final

final 修饰变量时,初衷是告诉编译器:这个变量生而不变,可以可劲儿优化。在 1.5 以后 Java 内存模型对 final 类型变量的重排进行了约束。现在只要我们提供正确构造函数没有“逸出”,就不会出问题了。

//在构造函数里面将 this 赋值给了全局变量 global.obj,这就是“逸出”,线程通过 global.obj 读取 x 是有可能读到 0 的。
public class FinalFieldExample {
    final int x;

    // 错误的构造函数
    public FinalFieldExample() {
        x = 3;
        y = 4;
        // 此处就是 this 逸出,
        global.obj = this;
    }
}

解决原子性问题

互斥锁

“同一时刻只有一个线程执行”这个条件非常重要,我们称之为互斥。如果能够保证对共享变量的修改是互斥的,无论是单核 CPU 还是多核 CPU,就都能保证原子性了。

锁和锁要保护的资源是有关联关系的
在这里插入图片描述

Java 语言提供的锁技术:synchronized

管程中锁的规则:对一个锁的解锁 Happens-Before 于后续对这个锁的加锁。(前一个线程在临界区修改的共享变量(该操作在解锁之前),对后续进入临界区(该操作在加锁之后)的线程是可见的。)

Java 编译器会在 synchronized 修饰的方法或代码块前后自动加上加锁 lock() 和解锁 unlock(),这样做的好处就是加锁 lock() 和解锁 unlock() 一定是成对出现的。

锁,一定有一个要锁定的对象,至于这个锁定的对象要保护的资源以及在哪里加锁 / 解锁,就属于设计层面的事情了。

class X {
    // 修饰非静态方法
    //当修饰非静态方法的时候,锁定的是当前实例对象 this
    synchronized void foo() {
        // 临界区
    }

    // 修饰静态方法
    //当修饰静态方法的时候,锁定的是当前类的 Class 对象
    synchronized static void bar() {
        // 临界区
    }

    // 修饰代码块
    Object obj = new Object();

    void baz() {
        synchronized (obj) {
            // 临界区
        }
    }
}  

受保护资源和锁之间的关联关系是 N:1 的关系,可以用同一把锁来保护多个资源

class SafeCalc {
    //没有 volatile 修饰,有可见性问题
    static long value = 0L;

    // 锁  this
    synchronized long get() {
        return value;
    }

    // 锁 SafeCalc.class
    synchronized static void addOne() {
        value += 1;
    }
}

由于临界区 get() 和 addOne() 是用两个锁保护的,因此这两个临界区没有互斥关系,临界区 addOne() 对 value 的修改对临界区 get() 也没有可见性保证,这就导致并发问题了。
在这里插入图片描述

用不同的锁对受保护资源进行精细化管理,能够提升性能。这种锁叫细粒度锁。使用细粒度锁可以提高并行度,是性能优化的一个重要手段。使用细粒度锁是有代价的,这个代价就是可能会导致死锁。

如何保护多个资源,关键是要分析多个资源之间的关系。如果资源之间没有关系,很好处理,每个资源一把锁就可以了。如果资源之间有关联关系,就要选择一个粒度更大的锁,这个锁应该能够覆盖所有相关的资源。除此之外,还要梳理出有哪些访问路径,所有的访问路径都要设置合适的锁

“原子性”的本质其实不是不可分割,不可分割只是外在表现,其本质是多个资源间有一致性的要求,操作的中间状态对外不可见。例如,在 32 位的机器上写 long 型变量有中间状态(只写了 64 位中的 32
位),在银行转账的操作中也有中间状态(账户 A 减少了 100,账户 B 还没来得及发生变化)。所以解决原子性问题,是要保证中间状态对外不可见。

  • 避免死锁
    • 只有以下这四个条件都发生时才会出现死锁:

      1、互斥,共享资源 X 和 Y 只能被一个线程占用;
      2、占有且等待,线程 T1 已经取得共享资源 X,在等待共享资源 Y 的时候,不释放共享资源 X;
      3、不可抢占,其他线程不能强行抢占线程 T1 占有的资源;
      4、循环等待,线程 T1 等待线程 T2 占有的资源,线程 T2 等待线程 T1 占有的资源,就是循环等待。

    • 互斥这个条件没有办法破坏,因为用锁为的就是互斥

      1、破坏占用且等待条件----->一次性申请所有资源
      2、破坏不可抢占条件-------->能够主动释放它占有的资源

      这一点 synchronized 是做不到的。原因是 synchronized 申请资源的时候,如果申请不到,线程直接进入阻塞状态了,而线程进入阻塞状态,啥都干不了,也释放不了线程已经占有的资源。java.util.concurrent 这个包下面提供的 Lock 是可以轻松解决这个问题的
      3、破坏循环等待条件---------> 需要对资源进行排序,然后按序申请资源。
      按一定顺序加锁

用“等待-通知”机制优化循环等待

一个完整的等待 - 通知机制:线程首先获取互斥锁,当线程要求的条件不满足时,释放互斥锁,进入等待状态;当要求的条件满足时,通知等待的线程,重新获取互斥锁。

用 synchronized 实现等待 - 通知机制

wait()、notify()、notifyAll()

在下面这个图里,左边有一个等待队列,同一时刻,只允许一个线程进入 synchronized 保护的临界区(这个临界区可以看作大夫的诊室),当有一个线程进入临界区后,其他线程就只能进入图中左边的等待队列里等待(相当于患者分诊等待)。这个等待队列和互斥锁是一对一的关系,每个互斥锁都有自己独立的等待队列
在这里插入图片描述

在并发程序中,当一个线程进入临界区后,由于某些条件不满足,需要进入等待状态,Java 对象的 wait() 方法就能够满足这种需求。如上图所示,当调用 wait() 方法后,当前线程就会被阻塞,并且进入到右边的等待队列中,这个等待队列也是互斥锁的等待队列。 线程在进入等待队列的同时,会释放持有的互斥锁,线程释放锁后,其他线程就有机会获得锁,并进入临界区了。

当条件满足时调用 notify(),会通知等待队列(互斥锁的等待队列)中的线程,告诉它条件曾经满足过。,被通知的线程要想重新执行,仍然需要获取到互斥锁
在这里插入图片描述

wait()、notify()、notifyAll() 方法操作的等待队列是互斥锁的等待队列

如果 synchronized 锁定的是 this,那么对应的一定是 this.wait()、this.notify()、this.notifyAll();如果 synchronized 锁定的是 target,那么对应的一定是 target.wait()、target.notify()、target.notifyAll() 。而且wait()、notify()、notifyAll() 这三个方法能够被调用的前提是已经获取了相应的互斥锁, wait()、notify()、notifyAll() 都是在 synchronized{}内部被调用的。

如果 synchronized 锁定的是 this,那么对应的一定是 this.wait()、this.notify()、this.notifyAll();如果 synchronized 锁定的是 target,那么对应的一定是 target.wait()、target.notify()、target.notifyAll() 。而且wait()、notify()、notifyAll() 这三个方法能够被调用的前提是已经获取了相应的互斥锁, wait()、notify()、notifyAll() 都是在 synchronized{}内部被调用的。

尽量使用 notifyAll(),notify() 是会随机地通知等待队列中的一个线程,而 notifyAll() 会通知等待队列中的所有线程。实际上使用 notify() 也很有风险,它的风险在于可能导致某些线程永远不会被通知到。

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/weixin_46488959/article/details/127149701

Java并发编程实战_Java并发编程实战-爱代码爱编程

并发编程基础概念: 原子性: 多个线程一起执行的时候,一个操作开始就不会受到其他的影响. 可见性: 当一个线程修改了某一个共享变量的值, 其他线程能否知道这个修改. 有序性: 在并发时,可能会进行指令重排,导致程序执行顺序发生改变. 核心的问题: 性能的提升! CPU, 内存, I/O设备的存在严重的速度差异. 根据木桶理论, 程序的整体性

C++并发编程-爱代码爱编程

第1章:C++的并发世界 1.1 何谓并发 最简单和最基本的并发,是指两个或更多独立的活动同时发生。 并发在生活中随处可见,我们可以一边走路一边说话,也可以两只手同时作不同的动作,还有我们每个人都过着相互独立的生活——当我在游泳的时候,你可以看球赛,等等。 1.1.1 计算机系统中的并发 计算机领域的并发指的是在单个系统里同时执行多个独立的任务,

如何深入学习Java并发编程?-爱代码爱编程

在讲解深入学习Java并发编程的方法之前,先分析如下若干错误的观点和学习方法。 错误观点1:学习Java编程主要是学习多线程。 这话其实是说明了表面现象,多线程其实还真是并发编程的实现方式,但在实际高并发的项目里,程序员一般不会通过多线程去实现并发的需求,而是通过使用一些后文会提到的高并发组件来实现高并发的需求。 甚至可以这样说,线程方面的技能对实现

java并发编程——并发编程的挑战-爱代码爱编程

本文是阅读《Java并发编程的艺术》后将自己记忆的理论知识和理解复写出来的产物,若有不足,欢迎指正! java并发编程是什么?让多个线程同时处理一个任务,从而达到快速的效果。但不是所有场景都适合并发编程。并发编程的挑战有哪些呢?①并发需要对线程的调度,自然需要切换线程,这就带来了上下文切换的挑战,这里关系到中断。如何保存被中断的线程的上下文,如何选择下一

牛客每日刷题__18shou的博客-爱代码爱编程

✅作者简介:我是18shou,一名即将秋招的java实习生 ✨个人主页:_18shou 🔥系列专栏:牛客刷题专栏 👉 在线刷题面经模拟面试    题目 题目主要信息: 给出一组区间,区间包括起始点,要求将重叠的区间合并重叠后的区间按照起点位置升序排列 思路 方法: 排序+贪心(推荐使用) 知识点:贪心思想 贪心思想属于动态规划思

基于java演唱会购票系统计算机毕业设计源码+系统+数据库+lw文档+部署_ssh 演唱会门票预约管理系统-爱代码爱编程

基于JAVA演唱会购票系统计算机毕业设计源码+系统+数据库+lw文档+部署 基于JAVA演唱会购票系统计算机毕业设计源码+系统+数据库+lw文档+部署 本源码技术栈: 项目架构:B/S架构 开发语言:Java语言 开发软件:idea eclipse 前端技术:Layui、HTML、CSS、JS、JQuery等技术 后端技术