多线程&锁

多线程&锁

JMM 内存模型

关于主内存与工作内存之间的具体交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步到主内存之间的实现细节，Java内存模型定义了以下八种操作来完成。

JMM 同步八种操作介绍

  1. lock「锁定」：作用于主内存的变量，把一个变量标记为一条线程独占状态；
  2. unlock「解锁」：作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定；
  3. read「读取」：作用于主内存的变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的 load 动作使用；
  4. load「载入」：作用于工作内存的变量，它把 read 操作从主内存中得到的变量值放入工作内存的变量副本中；
  5. use「使用」：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎；
  6. assign「赋值」：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量；
  7. store「存储」：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中， 以便随后的write的操作；
  8. write「写入」：作用于工作内存的变量，它把store操作从工作内存中的一个变量的值传送到主内存的变量中；

上面八步的操作如下，需要保证的是操作必须按顺序，但是没有必要保证是连续的。

avatar

并发编程的三个特性，也是需要 JMM 来解决

  • 原子性
  • 可见性
  • 有序性

  1. 原子性：即多步操作需要全部执行成功，或者全部执行不成功；

  2. 可见性：在多线程环境下，会存在一些共享变量，某个线程对共享变量的修改，其他线程能够立马感知到，并将最新的值更新到自己的工程内存中；

  3. 有序性：因为 CPU 会对编译好的程序进行指令重排，在单线程下没有影响，但是在多线程下，可能会导致异常；

指令重排序：

Java 语言规范规定 JVM 线程内部维持顺序化语义。即只要程序的最终结果与它顺序化情况的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的重排序。

指令重排序的意义是什么？

JVM 能根据处理器特性（CPU多级缓存系统、多核处理器等） 适当的对机器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度的发挥机器性能。

synchronized 和 lock 能保证原子性和可见性，不能保证有序性；

volatile 能保证可见性和有序性，不能保证原子性；

as-if-serial语义：

不管怎么重排序（编译器和处理器为了提高并行度），（单线 程）程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守 as-if-serial 语义

happens-before 原则：

  1. 程序顺序原则，即在一个线程内必须保证语义串行性，也就是说按照代码顺序执行；
  2. 锁规则解锁（unlock）操作必然发生在后续的同一个锁的加锁(lock)之前，也就是说， 如果对于一个锁解锁后，再加锁，那么加锁的动作必须在解锁动作之后(同一个锁)；
  3. volatile 规则 volatile 变量的写，先发生于读，这保证了 volatile 变量的可见性，简单的理解就是，volatile变量在每次被线程访问时，都强迫从主内存中读该变量的值，而当该变量发生变化时，又会强迫将最新的值刷新到主内存，在任何时刻，不同的线程总是能够看到该变量的最新值；
  4. 线程启动规则线程的 start() 方法先于它的每一个动作，即如果线程 A 在执行线程 B 的 start 方法之前修改了共享变量的值，那么当线程 B 执行 start 方法时，线程 A 对共享变量的修改对线程 B 可见；
  5. 传递性 A 先于 B ，B 先于 C 那么 A 必然先于 C；
  6. 线程终止规则线程的所有操作先于线程的终结，Thread.join() 方法的作用是等待当前执行的线程终止。假设在线程 B 终止之前，修改了共享变量，线程 A 从线程 B 的 join 方法 成功返回后，线程 B 对共享变量的修改将对线程 A 可见；
  7. 线程中断规则对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中 断事件的发生，可以通过 Thread.interrupted() 方法检测线程是否中断；
  8. 对象终结规则对象的构造函数执行，结束先于 finalize() 方法。

synchronized

概述：

synchronized 内置锁是一种对象锁（锁的是对象而非引用），作用粒度是对象，可以用来实现对临界资源的同步互斥访问，是可重入的。

原理：

基于 JVM 内置锁实现的，通过内部的 Monitor 去实现自动加锁和释放锁，Monitor 底层依赖的是互斥锁 「Mutex lock」，在 jdk1.5 之前，性能比较低，在 jdk1.5 之后，进行一系列的优化，比如：锁粗化、锁消除、轻量级锁、偏向锁、适应性自旋等手段来减少锁操作的开销。目前 synchronized 的性能和 Lock 基本持平。

既然是以对象作为锁，那么对象是怎么进行记录锁的？
下面是对象的内存分布：
avatar

在 HotSpot 虚拟机中，对象在内存中存储的布局分为三块区域：

  • 对象头
  • 实例数据
  • 对齐填充
  1. 对象头：
  • Mark Word「用于存储对象自身的运行时数据，如哈希码，GC 分代年龄、锁状态标志、持有该锁的线程 id、偏向线程 id、偏向时间戳等等」

volatile 是通过内存屏障来保证有序性和可见性；
内存屏障：

  1. 禁止 CPU 进行指令重排；
  2. 强制将工作内存的改动刷新到主内存中；

volatile 禁止指令重排：
avatar

锁粗化&锁消除

https://blog.csdn.net/qq_26222859/article/details/80546917

  • 锁粗化的案例：循环中多次获取同一个锁，可将获取锁的代码放在循环的外部，这样就只用获取一次锁；

  • 锁消除的案例：锁消除是发生在编译器级别的一种锁优化方式，有时候我们写的代码完全不需要加锁，却执行了加锁操作，比如：StringBuffer 类的 append 操作；

    锁粗化和锁消除都是 JIT 编译器自己做的优化，锁粗化是将多次获取锁的操作换为一次锁操作，锁消除是根据逃逸分析来的，如果对象不会发生逃逸，就可以进行锁消除。

锁的膨胀升级「从低到高」

  1. 无锁状态
  2. 偏向锁
  3. 轻量级锁
  4. 重量级锁

下面是 JVM 锁的膨胀升级：
avatar

CAS 以及 CAS 在 Java 中应用：

cas 用于解决多线程并发安全的问题，以前我们对一些多线程操作的代码都是使用 synchronize 关键字，来保证线程安全的问题，使用 cas 的话就是避免了加锁的耗时操作。
cas 是 compare and swap的简称，从字面上理解就是比较并更新，简单来说：从某一内存上取值 V，和预期值 A 进行比较，如果内存值 V 和预期值 A 的结果相等，那么我们就把新值 B 更新到内存，如果不相等，那么就重复上述操作直到成功为止。

Atomic 系列就是使用 cas 实现的，比如 AtomicInteger 中使用volatile 修饰的 value。

CAS 的隐患：

1、首先就是经典的 ABA 问题

何为 ABA 呢？我们还是以两个线程 L、N 进行自增操作为例，线程 L、N 同时获取当前的值 A，只不过此时线程 N 比较快，它在 L 操作之前，进行了两次操作，第一次将值从 A 改为了 B，之后又将 B 改为了 A ，那么在线程 L 操作的 时候发现当前的值还是 A，符合预期，那么它也会更新成功，从操作上看并没有什么不对，更新成功也是对的，但是这样是有隐患的。

2、长时间自旋非常消耗资源

先说一下什么叫自旋，自旋就是 cas 的一个操作周期，如果一个线程特别倒霉，每次获取的值都被其他线程的修改了，那么它就会一直进行自旋比较，直到成功为止，在这个过程中 cpu 的开销十分的大，所以要尽量避免。

如何结局 ABA 问题

采用数据版本号的方案，也就是 AtomicInteger 类中的 valueOffset 属性。

posted @ 2021-07-02 19:51  码上猿梦  阅读(191)  评论(0)  编辑  收藏  举报