wdcp 防盗链 网站不能打开,ps做网站首页步骤,电商平台运营公司,中信建设有限责任公司待遇怎么样导航一、CPU缓存架构与一致性协议1.1 CPU缓存架构1.2 缓存行与伪共享问题1.3 MESI 缓存一致性协议1.4 伪共享的解决办法二、JMM Java 内存模型2.1 JMM 简介2.2 原子性、可见性、有序性2.3 八大内存交互操作2.4 happens-before 原则一、CPU缓存架构与一致性协议
1.1 CPU缓存架构…
导航一、CPU缓存架构与一致性协议1.1 CPU缓存架构1.2 缓存行与伪共享问题1.3 MESI 缓存一致性协议1.4 伪共享的解决办法二、JMM Java 内存模型2.1 JMM 简介2.2 原子性、可见性、有序性2.3 八大内存交互操作2.4 happens-before 原则一、CPU缓存架构与一致性协议
1.1 CPU缓存架构
现代 CPU 的发展非常快内存的速度已经完全跟不上。如果将CPU完成一个基本操作所用的时间定义为时钟周期那么 CPU 的指令处理速度要比内存的加载速度快100 倍左右。
为了解决这个性能上的鸿沟现代 CPU 架构往往采用如下图所示的缓存架构 在多核CPU和主存Main Memory之间引入三级高速缓存——L1、L2、L3。
越靠近CPU的缓存成本造价越高、性能越强、存储空间越小其中 L3 缓存是多核共享而L1、L2 是核内私有。
1.2 缓存行与伪共享问题
缓存行 Cache Line 是高速缓存一次读取内存数据的最小单位。目前最常见的 Intel cpu 的缓存行大小是 64 Bytes。 连续的数据很有可能由于数据跨度恰好在一个缓存行内就很有可能会被CPU加载到 L1、L2、L3 高速缓存中。
由于高速缓存的存在引出了缓存一致性协议它可以保证 L1、L2、L3 中的数据在多核CPU和并发场景下不会出现线程不一致问题。早期的解决方案并不是各种缓存一致性方案而是采用总线锁的方式。 总线锁顾名思义就是将高速缓存与主内存之间的总线上锁只允许一个线程去获取并操作上锁数据处理完成后释放锁并将数据从缓存中刷回主存。这种方式虽然安全但也牺牲了很大的性能。于是人们又引入了诸如 MESI 的缓存一致性协议。简单的说就是给缓存数据做标记如果CPU发现缓存的数据失效了就必须从主存中重新加载最新的数据。 那什么又是伪共享呢
伪共享是缓存行加载数据时必然会存在的性能损耗问题。当对象中包含线程局部变量且尺寸大小小于 64 字节就有可能发生伪共享问题。
再具体点内存地址连续的不同变量被加载到了同一个缓存行中而同一个缓存行中的多个变量又不一定是CPU所需的这种情况就是伪共享。
由于伪共享的存在CPU核心中的高速缓存加载了本不需要数据又在“缓存一致性协议”的要求下不得不在这些无用数据失效后重新加载缓存导致缓存失效或造成性能损耗 如上图所示x、y 两个变量由 Main Memory 加载到 core 1 和 core 2两个核心的 L1、L2 缓存中。如果线程A、B 跑在两个核心上且线程 A 修改 core 1 中的 x由于缓存一致性协议 core 2 中的 x 变量将会失效它必须从主内存中重新加载这样频繁的加载、访问主内存 core 2 中的 L1、L2 缓存几乎等于失效。
1.3 MESI 缓存一致性协议
MESI是缓存锁的实现方式之一注意这是 CPU 缓存一致性并非通常说的应用缓存。有些无法被缓存的数据或跨多个缓存行的数据依然必须使用总线锁。
MESI 的核心思想是为每个 Cache Line 标记 4 种状态
若缓存数据更改过则将 Cache Line 标记为 M如果缓存数据是独享则标记为 E如果数据是被多个CPU读取则标记为 S如果数据被其他CPU修改过则标记为 I
1.4 伪共享的解决办法
Java 7 之前可以采用字节填充的方式例如针对不同操作系统和对象头的大小补齐多个 long 类型的空数据。 但这种方式在 Java 7 的某个版本中会出现 填充失效问题原因是该版本的虚拟机优化了未使用 field 的排布。
在 Java 8 加入 Contended 注解会帮助增加128 字节的 padding并且需要开启 -XX:-RestrictContended 选项才能生效。
虽然解决了伪共享的问题但是这种填充的方式也浪费了缓存资源而且缓存又小又贵时间和空间的取舍要酌情考虑。
二、JMM Java 内存模型
2.1 JMM 简介
JMM 全称是 “Java Memory Model”Java 内存模型。 因为在不同的硬件生产商和操作系统下内存的访问方式各有所差异这样就会造成相同的代码出现不一样的问题而 JMM 屏蔽掉了各种操作系统的内存访问差异以实现“Write OnceRun Anywhere”的目标。
JMM 中规定所有的变量都存储在主内存 Main Mem中包括实例变量、静态变量但是不包括局部变量和方法参数。每条线程都有自己的工作内存Work Mem线程私有。工作内存中保存的是线程的变量从主内存中的拷贝副本。
这种结构的基本工作方式是线程对变量的读和写都必须在工作内存中进行而线程之间变量值的传递均需要通过主内存来完成。如下图所示注意与Java 内存结构堆栈等等概念区分开。 2.2 原子性、可见性、有序性
整个 JMM 实际上是围绕着三个并发特征建立起来的——原子性、可见性、有序性。
原子性和事务的 ACID 的 原子性概念一致即表示一个操作中间不可分割不能中断执行过程不允许被其他线程打扰。 JMM 只能保证基本操作的原子性如果要保证一个代码块的原子性Java 提供了 synchronized 关键字它对应了 monitorentrer 和 monitorexit 字节码指令。可见性不同的线程对数据的修改结果可以被其他线程感知到这就是可见性。synchronized 是保证可见性的最常用的操作除此之外还有 volatile 关键字它是较弱的同步机制。有序性字节码指令的执行顺序不可重排。可以使用 synchronized 或 volatile 保证多线程之间操作的有序性。volatile是使用内存屏障达到禁止指令重排保证有序性。而 synchronized 则以互斥锁的形式要求上锁的资源必须按序执行。
2.3 八大内存交互操作 说是 8 种内存交互操作
lock 和 unlock锁定与解锁。作用于主内存的变量将其设置为线程独占或解除。Read 和 Write发生在主内存和工作内存之间将变量传输到工作内存将从工作内存得到的值放入主内存中。Load 和 Store作用于工作内存的变量将工作内存中的变量放入副本中将工作内存中的变量传输到主内存中。Use 和 Assign将工作内存中的变量传输到执行引擎将一个从执行引擎中接收到的值赋值给工作内存的副本。
使用规则
不允许 read、load、store、write 操作之一单独出现即 read 操作后必须 loadstore后必须 write。不允许线程丢弃它最近的 assign 操作即工作内存中的变量修改之后必须告知主存。不允许线程将没有 assign 的数据从工作内存同步到主存。lock 和 unlock 必须成对出现。新的变量必须由主存中诞生。如果对一个变量进行 lock会清空所有工作内存中此变量的值。在执行引擎使用这个变量前必须重新 load 或 assign 。unlock 之前必须将此变量同步回主内存。
2.4 happens-before 原则
happens-before是JMM提供的有序性保证。在理解它的概念之前需要了解一下弱内存模型和强内存模型。 弱内存模型——weak memory model 弱内存模型中loadload、loadstore、storestore、storeload 四种内存重排序都有可能发生。只要不改变单线程行为弱内存模型可随意对代码进行重排序这是一种近乎不存在任何保证的模型。 强内存模型 Java的内存模型属于一种叫做 “顺序一致性” 的强内存模型。在顺序一致性模型中不再存在重排序Java的JMM就属于这种强内存模型。 虽然 JMM 属于最高级别的强内存模型——顺序一致性内存模型但并不是说Java 不允许重排序而是在某些情况下可以支持严格限制重排序的目的如volatile。而弱内存模型是无法满足这种保证的。
happens-before 是 JMM 提供的一系列关于重排序问题的规则。可以概括为 If one action happens-before another, then the first is visible to and ordered before the second. 如果一个动作 happens-before 另一个动作那么前者的执行会排在后者的前面并且其结果对后者可见。 《java language specification 8》 可以分为以下两种策略
对于会改变程序执行结果的重排序JMM要求编译器和处理器必须禁止这种重排序。对于不会改变程序执行结果的重排序JMM对编译器和处理器不做要求JMM允许这种重排序。
这两个策略概括起来可以这样理解——只要不改变程序的执行结果编译器和处理器想怎么优化就怎么优化。
例如如果编译器经过细致的分析认定一个锁只能被一个线程访问到那么这个锁可以被消除。 又例如编译器认定一个 volatile 变量只会被单个线程访问到那么它可以把这个 volatile 变量当做一个普通变量对待。
happens-before 的具体规则如下 程序顺序执行如果x和y是同一个线程的动作并且在程序顺序中x出现在y之前则 x happens-before y。如果动作 x 的结果需要同步给后面的动作 y 那么 x happens-before y。也就是说synchronized 修饰的情况先获得锁的线程就是 x 后获得锁的就是 y前者的执行结果需要同步给 y那么同样会有 x happens-before y。传递性x happens-before yy happens-before z那么 x happens-before z。 根据这些规则以下这些场景都是 happens-before 的情况 对象锁的解锁发生在对象锁后续的上锁之前对 volatile 变量的写操作一定发生在后续对该 volatile 变量的读操作之前。对线程的 start() 方法的调用一定发生在线程内其他操作之前。线程中的所有操作一定发生在该线程 join() 方法结束之前。任何对象的默认初始化一定发生在程序中其他操作之前。 总之happens-before 定义了两个动作发生资源竞争时的时间顺序是JMM 描述特定动作前后执行顺序的一种抽象关系。它原则上不允许重排序但在一些不影响程序执行结果的情况下乱序执行也是可以的。
