直播app开发哪家好,企业电子商务网站优化方案,哪家做网站好 成都,广州品牌策划公司排行优质博文#xff1a;IT-BLOG-CN
一、并发编程模型的两个关键问题
【1】并发中常见的两个问题#xff1a;线程之间如何通信及线程之间如何同步。通信是指线程之间以何种机制来交换信息。在命令式编程中#xff0c;线程之间的通信机制有两种#xff1a;内存共享和消息传递IT-BLOG-CN
一、并发编程模型的两个关键问题
【1】并发中常见的两个问题线程之间如何通信及线程之间如何同步。通信是指线程之间以何种机制来交换信息。在命令式编程中线程之间的通信机制有两种内存共享和消息传递 【2】在共享内存的并发模型里线程之间共享程序的公共状态通过写-读内存中的公共数据进行隐式通信。在消息传递的并发模型里如果没有公共状态线程之间必须通过发送消息来显示进行通讯 【3】同步是指程序中用于控制不同线程间操作发生相对顺序的机制可以理解为协同步调按预定的先后次序运行。这里的“同”字应是指协同、协助、互相配合的意思而非一起的意思。可理解为线程A和B一块配合A执行到一定程度时要依靠B的某个结果于是停下来示意B运行B执行结束后再将结果给AA再继续操作。在共享内存并发模型里同步是显式进行的。在消息传递的并发模型里由于消息的发送必须在消息接收之前。因此同步是隐式进行的 【4】Java 的并发采用的是共享内存模型Java 线程之间的通信总是隐式进行整个通信过程对程序员完全透明。如果编写多线程程序的 Java程序员不理解隐式进行的线程之间通信的工作机制很可能会遇到各种奇怪的内存可见性问题
二、Java内存模型的抽象结构
【1】Java中堆内存主要用于存储实例域、静态域和数组元素等堆内存在线程之间共享“共享变量”指实例域、静态域和数组元素。局部变量Local Variables方法定义参数和异常处理器参数Exception Handler Parameters不会在线程之间共享它们不会有内存可见性问题也不会受内存模型的影响。 【2】Java 线程之间的通讯由 Java内存模型JMM控制JMM决定一个线程对共享变量的写入何时对另一个线程可见。从抽象角度来看JMM定义了线程和主内存之间的抽象关系线程之间的共享变量存储在主内存Main Memory中每个线程都有一个私有的本地内存Local Memory本地内存中存储了该线程以读/写共享变量的副本。本地内存是 JMM的一个抽象概念并不真实存在。它涵盖了缓存、写缓存区、寄存器以及其它的硬件和编译器优化。Java内存模型的抽象示意图如下 从上图来看如果线程A和线程B之间要通信的话必须要经历下面2个步骤 1、线程A把本地内存A中更新过的共享变量刷新到主内存中去。 2、线程B到内存中去读取线程A之前已更新过的共享变量。 从整体上来看这两个步骤实质上是线程A在向线程B发送消息而且这个通信过程必须要经过主内存。JMM通过控制主内存与每个线程的本地内存之间的交互来为Java程序员提供内存可见性保证。
三、从源代码到指令序列的重排序
在执行程序时为了提高性能编译器javac将 java源程序编译成中间代码字节码文件和处理器常常会对指令做重排序。重排序分为三种 1、编译器优化的重排序。编译器再不改变单线程程序语义的前提下可以重新安排语句的性质顺序。 2、指令集并行的重排序。现代处理器采用了指令级并行技术Instruction-Level ParallelismILP来将多条指令重叠执行。如果不存在数据依赖性处理器可以改变语句对应机器指令的执行顺序。 3、内存系统的重排序。由于处理器使用缓存和读/写缓冲区这使得加载和存储操作看上去可能是在乱序中执行。从 Java源代码到最终实际执行的指令序列会分别经历下面重排序 【1】上述的1属于编译器重排序2和3属于处理器重排序。这些重排序可能会导致多线程程序出现内存可见性问题。对于编译器JMM的编译器重排序规则会禁止特定类型的编译器重排序不是所有的编译器重排序都要禁止。对于处理器排序JMM的处理器重排序规则会要求 Java编译器在生成指令序列时插入特定类型的内存屏障Memory BarriersInter称之为Memory Fence指令通过内存屏障指令来禁止特定类型的处理器重排序。 【2】JMM 属于语言级的内存模型它确保在不同的编译器和不同的处理器平台之上通过禁止特定类型的编译器重排序和处理器重排序为程序员提供一致的内存可见性保证。
四、并发编程模型的分类
现在的处理器使用写缓冲区临时保存向内存写入的数据因为处理器的处理速度远远大于 IO的处理速度。写缓冲区能够保证指令流水线运行可以有效的避免由于处理器停顿下来等待向内存写入数据而产生的延迟。同时通过以批处理的方式刷新写缓冲区以及合并写缓存器中内存地址相同的多次写操作减少对内存总线的占用。虽然写缓存区有这么多好处但每个处理器上的写缓冲区仅仅对它所在的处理器可见这个特性会对内存操作的执行产生重要的影响处理器对内存的读/写操作的执行顺序不一定与内存实际发生的读/写操作顺序一致。举个栗子
示例列/处理器ProcessAProcessB代码a1;//A1xb;//A2b2;//B1ya;//B2运行结果初始状态ab0处理器运行执行后得到的结果xy0
假设处理器A 和处理器B 按程序的顺序并行执行内存访问最终可能得到 xy0的结果。具体原因就是上面所说的处理器上的缓存区仅可见于它所在的处理器。 【1】这里处理器A 和处理器B 可以同时把共享变量写入自己的缓冲区A1、B1然后从共享内存中读取另一个共享变量A2、B2最后才把自己写缓存中保存的脏数据刷新到内存中A3、B3当以这种时序执行时程序就可以得到 xy0的结果。 【2】从内存操作实际发生的顺序来看直到处理器A执行A3来刷新自己的写缓存区写操作A1才算真正执行了。虽然处理器A执行内存操作的顺序为A1——A2但实际内存操作的顺序A2——A1。此时处理器A 的内存操作顺序被重排序了处理器B相同 【3】这里关键是由于写缓存区仅对自己的处理器可见从而导致处理器执行内存操作的顺序可能会与内存实际的操作执行顺序不一致。由于现在的处理器都支持写缓存因此现在的处理器都支持写-读操作的重排序。 ▶ 常见处理器允许的重排序类型的列表N表示不允许重排序
处理器/规则Load-LoadLoad-StoreStore-StoreStore写-Load读数据依赖SPARC-TSONNNYNX86NNNYNIA64YYYYNPowerPCYYYYN
可以看出常见的处理器都允许 Store-Load重排序常见的处理器都不允许存在数据依赖的操作重排序。Sparc-TSO 和 X86拥有相对较强的处理器内存模型它们仅允许对写-读操作做重排序因为它们都使用了写缓冲区。为了保证内存可见性Java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。JMM 把内存屏障指令分为4类
屏障类型指令示例说明LoadLoad BarriersLoad1; LoadLoad; Load2确保Load1装载数据优先Load2及所有后续装载指令的装载。StoreStore BarriersStore1; StoreStore; Store2确保Store1数据对其他处理器可见刷新到内存优先Store2及所有后续存储指令的存储。LoadStore BarriersLoad1; LoadSotre; Store2确保Load1数据装载优先于Store2及所有后续的存储指令刷新到内存。StoreLoad BarriersStore1; StoreLoad; Load2确保Store1中的数据对其他处理器可见刷新到内存优于Load2及所有的后续加载指令。StoreLoad Barriers会使该屏障是前的所有内存访问指令存储和装载指令完成后才执行该屏障后的内存访问指令
StoreLoad Barriers是一个“全能型”的屏障它同时具有前面3个屏障的效果。现在的大多数处理器都支持该屏障其他类型的屏障不一定被支持支持开屏障开销一般很昂贵因为当前处理器通常要把写缓存中的数据全部刷新到内存中Buffer Fully Fulsh。
五、happens-before 简介
JSR-133内存模型使用 happens-before的概念来阐述操作之间的内存可见性。JMM中如果一个操作执行的结果需要对另一个操作可见那么这两个操作之间必须要存在 happens-before关系。这两个操作既可以是同一个线程内也可以是在不同线程之间。 与程序员密切相关的 happens-before规则如下 【1】程序顺序规则 一个线程中的每个操作happens-before于该线程中的任意后续操作。 【2】监视器锁规则 对一个锁的解锁happens-before于随后对这个锁的加锁。 【3】volatile变量规则 对一个volatile域的写happens-before于任意后续对这个volatile域的读。 【4】传递性 如果A happens-before B且B happens-before C那么A happens-before C。
【注意】 两个操作具有 happens-before关系并不意味着前一个操作必须要在后一个操作之前执行happens-before仅仅要求前一个操作执行的结果对后一个操作可见且前一个操作按顺序排在第二个操作之前。happens-before定义很微妙后文具体说明 happens-before为什么要这么定义。 一个 happens-before规则对应于一个或多个编译器和处理器重排序规则。对于Java程序员来说happens-before规则简单易懂它避免了程序员为了理解 JMM提供的内存可见性保证而去学习复杂的重排序规则以及这些规则的具体实现方法。
