广告公司企业网站模板,登录网页版网址是什么,舆情系统的作用,如何做众筹网站深入理解Java虚拟机#xff08;第三版#xff09;# 高效并发 chap12 Java内存模型与线程 概述 在许多场景下#xff0c;让计算机同时去做几件事情#xff0c;不仅是因为计算机的运算能力强大了#xff0c;还有一个很重要的原因是计算机的运算速度与它的存储和通信子系统的… 深入理解Java虚拟机第三版# 高效并发 chap12 Java内存模型与线程 概述 在许多场景下让计算机同时去做几件事情不仅是因为计算机的运算能力强大了还有一个很重要的原因是计算机的运算速度与它的存储和通信子系统的速度差距太大大量的时间都花费在磁盘I/O、网络通信或者数据库访问上。如果不希望处理器在大部分时间里都处于等待其他资源的空闲状态就必须使用一些手段去把处理器的运算能力“压榨”出来否则就会造成很大的性能浪费而让计算机同时处理几项任务则是最容易想到也被证明是非常有效的“压榨”手段。 landon-这里从物理计算机的角度说明了并发的重要性“不能阻塞” 于计算量相同的任务程序线程并发协调得越有条不紊效率自然就会越高反之线程之间频繁争用数据互相阻塞甚至死锁将会大大降低程序的并发能力 物理机对并发的处理方案对虚拟机的实现也有相当大的参考意义 由于计算机的存储设备与处理器的运算速度有着几个数量级的差距所以现代计算机系统都不得不加入一层或多层读写速度尽可能接近处理器运算速度的高速缓存Cache来作为内存与处理器之间的缓冲引入了一个新的问题缓存一致性Cache Coherence。在多路处理器系统中每个处理器都有自己的高速缓存而它们又共享同一主内存Main Memory为了解决一致性的问题需要各个处理器访问缓存时都遵循一些协议在读写时要根据协议来进行操作除了增加高速缓存之外为了使处理器内部的运算单元能尽量被充分利用处理器可能会对输入代码进行乱序执行Out-Of-Order Execution优化 Java内存模型 Java内存模型规定了所有的变量都存储在主内存Main Memory中每条线程还有自己的工作内存Working Memory可与前面讲的处理器高速缓存类比线程的工作内存中保存了被该线程使用的变量的主内存副本线程对变量的所有操作读取、赋值等都必须在工作内存中进行而不能直接读写主内存中的数据不同的线程之间也无法直接访问对方工作内存中的变量线程间变量值的传递均需要通过主内存来完成lock、unlock、read、load、use、assign、store、write 把一个变量从主内存拷贝到工作内存那就要按顺序执行read和load操作如果要把变量从工作内存同步回主内存就要按顺序执行store和write操作 volatile 保证此变量对所有线程的可见性这里的“可见性”是指当一条线程修改了这个变量的值新值对于其他线程来说是可以立即得知的普通的变量仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致普通变量的值在线程间传递时均需要通过主内存来完成但是Java里面的运算操作符并非原子操作这导致volatile变量的运算在并发下一样是不安全的禁止指令重排序优化 A线程有变量initialized先初始化配置文件内容再赋值initialized为trueB线程判断initialized为true则读取配置文件但是因为指令重排序有可能initialized先被赋值从而导致B线程可能读取报错如果initialized为volatile修饰则无问题 内存屏障 关键变化在于有volatile修饰的变量赋值后多执行了一个“lock addl$0x0(%esp)”操作 关键在于lock前缀相当于对缓存中的变量做了一次前面介绍Java内存模式中所说的“store和write”操作通过这样一个空操作可让前面volatile变量的修改对其他处理器立即可见 相当于一个内存屏障Memory Barrier或Memory Fence指重排序时不能把后面的指令重排序到内存屏障之前的位置如果有两个或更多处理器访问同一块内存且其中有一个在观测另一个就需要内存屏障来保证一致性了 从硬件架构上讲指令重排序是指处理器采用了允许将多条指令不按程序规定的顺序分开发送给各个相应的电路单元进行处理。但并不是说指令任意重排处理器必须能正确处理指令依赖情况保障程序能得出正确的执行结果 譬如指令1把地址A中的值加10指令2把地址A中的值乘以2指令3把地址B中的值减去3这时指令1和指令2是有依赖的它们之间的顺序不能重排但指令3可以重排到指令1、2之前或者中间只要保证处理器执行后面依赖到A、B值的操作时能获取正确的A和B值即可所以在同一个处理器中重排序过的代码看起来依然是有序的lock addl$0x0(%esp)指令把修改同步到内存时意味着所有之前的操作都已经执行完成这样便形成了“指令重排序无法越过内存屏障”的效果 我们在volatile与锁中选择的唯一判断依据仅仅是volatile的语义能否满足使用场景的需求long和double的非原子性协定。在实际开发中除非该数据有明确可知的线程竞争否则我们在编写代码时一般不需要因为这个原因刻意把用到的long和double变量专门声明为volatile 原子性 我们大致可以认为基本数据类型的访问、读写都是具备原子性的例外就是long和double的非原子性协定读者只要知道这件事情就可以了无须太过在意这些几乎不会发生的例外情况如果应用场景需要一个更大范围的原子性保证经常会遇到提供了更高层次的字节码指令monitorenter和monitorexit来隐式地使用这两个操作。这两个字节码指令反映到Java代码中就是同步块——synchronized关键字因此在synchronized块之间的操作也具备原子性 可见性 volatile保证了多线程操作时变量的可见性而普通变量则不能保证这一点除了volatile之外Java还有两个关键字能实现可见性它们是synchronized和final 有序性 Java程序中天然的有序性可以总结为一句话如果在本线程内观察所有的操作都是有序的如果在一个线程中观察另一个线程所有的操作都是无序的。前半句是指“线程内似表现为串行的语义”Within-ThreadAs-If-Serial Semantics后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性 先行发生原则 它是判断数据是否存在竞争线程是否安全的非常有用的手段先行发生是Java内存模型中定义的两项操作之间的偏序关系比如说操作A先行发生于操作B其实就是说在发生操作B之前操作A产生的影响能被操作B观察到“影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等举例 i 1线程A执行j i 线程B执行i 2线程C执行如果线程A的操作先行于B那么我们可以确定线程Bj的值一定是1如果A和B有先行关系但是C和B没有先行关系那么j的值是多少答案是不确定1和2都有可能因为线程C对变量i的影响可能会被线程B观察到也可能不会这时候线程B就存在读取到过期数据的风险不具备多线程安全性 天然的先行发生关系 程序次序规则Program Order Rule在一个线程内按照控制流顺序书写在前面的操作先行发生于书写在后面的操作。注意这里说的是控制流顺序而不是程序代码顺序因为要考虑分支、循环等结构管程锁定规则Monitor Lock Rule一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是“同一个锁”而“后面”是指时间上的先后volatile变量规则Volatile Variable Rule对一个volatile变量的写操作先行发生于后面对这个变量的读操作这里的“后面”同样是指时间上的先后线程启动规则Thread Start RuleThread对象的start()方法先行发生于此线程的每一个动作线程终止规则Thread Termination Rule线程中的所有操作都先行发生于对此线程的终止检测我们可以通过Thread::join()方法是否结束、Thread::isAlive()的返回值等手段检测线程是否已经终止执行线程中断规则Thread Interruption Rule对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生可以通过Thread::interrupted()方法检测到是否有中断发生对象终结规则Finalizer Rule一个对象的初始化完成构造函数执行结束先行发生于它的finalize()方法的开始传递性Transitivity如果操作A先行发生于操作B操作B先行发生于操作C那就可以得出操作A先行发生于操作C的结论 举例 int value 0、getValue()、setValue(int)存在线程A时间上先调用了setValue(1)然后线程B调用了同一个对象的getValue那么线程B返回值多少 由于两个方法分别由线程A和B调用不在一个线程中所以程序次序规则在这里不适用由于没有同步块自然就不会发生lock和unlock操作所以管程锁定规则不适用由于value变量没有被volatile关键字修饰所以volatile变量规则不适用后面的线程启动、终止、中断规则和对象终结规则也和这里完全没有关系因为没有一个适用的先行发生规则所以最后一条传递性也无从谈起因此我们可以判定尽管线程A在操作时间上先于线程B但是无法确定线程B中getValue()方法的返回结果换句话说这里面的操作不是线程安全的 修复问题 要么把getter/setter方法都定义为synchronized方法这样就可以套用管程锁定规则要么把value定义为volatile变量由于setter方法对value的修改不依赖value的原值满足volatile关键字使用场景这样就可以套用volatile变量规则来实现先行发生关系 一个操作“时间上的先发生”不代表这个操作会是“先行发生”int i 1;int j 2 同一个线程的两个语句 根据程序次序规则“int i1”的操作先行发生于“int j2”但是“int j2”的代码完全可能先被处理器执行这并不影响先行发生原则的正确性因为我们在这条线程之中没有办法感知到这一点 时间先后顺序与先行发生原则之间基本没有因果关系所以我们衡量并发安全问题的时候不要受时间顺序的干扰一切必须以先行发生原则为准 Java与线程 Thread类所有关键方法都被声明为Native实现线程主要有三种方式使用内核线程实现使用用户线程实现使用用户线程加轻量级进程混合实现近年来许多新的、以高并发为卖点的编程语言又普遍支持了用户线程譬如Golang、Erlang等Java线程在早期的Classic虚拟机上JDK 1.2以前是基于一种被称为“绿色线程”GreenThreads的用户线程实现的但从JDK 1.3起“主流”平台上的“主流”商用Java虚拟机的线程模型普遍都被替换为基于操作系统原生线程模型来实现Java虚拟机规范》中才不去限定Java线程需要使用哪种线程模型来实现。线程模型只对线程的并发规模和操作成本产生影响对Java程序的编码和运行过程来说这些差异都是完全透明的 Java线程调度 线程调度是指系统为线程分配处理器使用权的过程调度主要方式有两种分别是协同式Cooperative Threads-Scheduling线程调度和抢占式Preemptive Threads-Scheduling线程调度 如果使用协同式调度的多线程系统线程的执行时间由线程本身来控制线程把自己的工作执行完了之后要主动通知系统切换到另外一个线程上去。协同式多线程的最大好处是实现简单而且由于线程要把自己的事情干完后才会进行线程切换切换操作对线程自己是可知的所以一般没有什么线程同步的问题 Lua语言中的“协同例程”就是这类实现。它的坏处也很明显线程执行时间不可控制甚至如果一个线程的代码编写有问题一直不告知系统进行线程切换那么程序就会一直阻塞在那里 Landon TODO 了解Lua的协程实现原理和优劣势 如果使用抢占式调度的多线程系统那么每个线程将由系统来分配执行时间线程的切换不由线程本身来决定。Java使用的线程调度方式就是抢占式调度 线程优先级并不是一项稳定的调节手段很显然因为主流虚拟机上的Java线程是被映射到系统的原生线程上来实现的所以线程调度最终还是由操作系统说了算 状态转换 Java语言定义了6种线程状态在任意一个时间点中一个线程只能有且只有其中的一种状态并且可以通过特定的方法在不同状态之间转换 新建New创建后尚未启动的线程处于这种状态运行Runnable包括操作系统线程状态中的Running和Ready也就是处于此状态的线程有可能正在执行也有可能正在等待着操作系统为它分配执行时间无限期等待Waiting处于这种状态的线程不会被分配处理器执行时间它们要等待被其他线程显式唤醒 没有设置Timeout参数的Object::wait()方法没有设置Timeout参数的Thread::join()方法LockSupport::park()方法 限期等待Timed Waiting处于这种状态的线程也不会被分配处理器执行时间不过无须等待被其他线程显式唤醒在一定时间之后它们会由系统自动唤醒 Thread::sleep()方法设置了Timeout参数的Object::wait()方法设置了Timeout参数的Thread::join()方法LockSupport::parkNanos()方法LockSupport::parkUntil()方法 阻塞Blocked线程被阻塞了“阻塞状态”与“等待状态”的区别是“阻塞状态”在等待着获取到一个排它锁这个事件将在另外一个线程放弃这个锁的时候发生而“等待状态”则是在等待一段时间或者唤醒动作的发生。在程序等待进入同步区域的时候线程将进入这种状态结束Terminated已终止线程的线程状态线程已经结束执行 Java与协程 Java时代早期涌现过无数多线程的应用与框架譬如在网页访问时HTTP请求可以直接与Servlet API中的一条处理线程绑定在一起以“一对一服务”的方式处理由浏览器发来的信息今天对Web应用的服务要求不论是在请求数量上还是在复杂度上与十多年前相比已不可同日而语这一方面是源于业务量的增长另一方面来自于为了应对业务复杂化而不断进行的服务细分。现代B/S系统中一次对外部业务请求的响应往往需要分布在不同机器上的大量服务共同协作来实现这种服务细分的架构在减少单个服务复杂度、增加复用性的同时也不可避免地增加了服务的数量缩短了留给每个服务的响应时间。这要求每一个服务都必须在极短的时间内完成计算这样组合多个服务的总耗时才不会太长也要求每一个服务提供者都要能同时处理数量更庞大的请求这样才不会出现请求由于某个服务被阻塞而出现等待Java目前的并发编程机制就与上述架构趋势产生了一些矛盾11的内核线程模型是如今Java虚拟机线程实现的主流选择但是这种映射到操作系统上的线程天然的缺陷是切换、调度成本高昂系统能容纳的线程数量也很有限。以前处理一个请求可以允许花费很长时间在单体应用中具有这种线程切换的成本也是无伤大雅的但现在在每个请求本身的执行时间变得很短、数量变得很多的前提下用户线程切换的开销甚至可能会接近用于计算本身的开销这就会造成严重的浪费传统的Java Web服务器的线程池的容量通常在几十个到两百之间当程序员把数以百万计的请求往线程池里面灌时系统即使能处理得过来但其中的切换损耗也是相当可观的。现实的需求在迫使Java去研究新的解决方案内核线程的调度成本主要来自于用户态与核心态之间的状态转换而这两种状态转换的开销主要来自于响应中断、保护和恢复执行现场的成本 如果说内核线程的切换开销是来自于保护和恢复现场的成本那如果改为采用用户线程这部分开销就能够省略掉吗答案是“不能”。但是一旦把保护、恢复现场及调度的工作从操作系统交到程序员手上那我们就可以打开脑洞通过玩出很多新的花样来缩减这些开销 有一些古老的操作系统譬如DOS是单人单工作业形式的天生就不支持多线程自然也不会有多个调用栈这样的基础设施。而早在那样的蛮荒时代就已经出现了今天被称为栈纠缠Stack Twine的、由用户自己模拟多线程、自己保护恢复现场的工作模式。其大致的原理是通过在内存里划出一片额外空间来模拟调用栈只要其他“线程”中方法压栈、退栈时遵守规则不破坏这片空间即可这样多段代码执行时就会像相互缠绕着一样非常形象到后来操作系统开始提供多线程的支持靠应用自己模拟多线程的做法自然是变少了许多但也并没有完全消失而是演化为用户线程继续存在。由于最初多数的用户线程是被设计成协同式调度Cooperative Scheduling的所以它有了一个别名——“协程”Coroutine。又由于这时候的协程会完整地做调用栈的保护、恢复工作所以今天也被称为“有栈协程”StackfullCoroutine起这样的名字是为了便于跟后来的“无栈协程”Stackless Coroutine区分开。无栈协程不是本节的主角不过还是可以简单提一下它的典型应用即各种语言中的await、async、yield这类关键字。无栈协程本质上是一种有限状态机状态保存在闭包里自然比有栈协程恢复调用栈要轻量得多但功能也相对更有限 Landon-TODO 了解有栈协程、无栈协程 协程的主要优势是轻量无论是有栈协程还是无栈协程都要比传统内核线程要轻量得多协程当然也有它的局限需要在应用层面实现的内容调用栈、调度器这些特别多协程在最初甚至在今天很多语言和框架中会被设计成协同式调度这样在语言运行平台或者框架上的调度器就可以做得非常简单。不过有不少资料上显示既然取了“协程”这样的名字它们之间就一定以协同调度的方式工作。笔者并没有查证到这种“规定”的出处只能说这种提法在今天太过狭隘了非协同式、可自定义调度的协程的例子并不少见 具体到Java语言还会有一些别的限制譬如HotSpot这样的虚拟机Java调用栈跟本地调用栈是做在一起的。如果在协程中调用了本地方法还能否正常切换协程而不影响整个线程另外如果协程中遇传统的线程同步措施会怎样譬如Kotlin提供的协程实现一旦遭遇synchronize关键字那挂起来的仍将是整个线程 Landon - TODO Kotlin的协程是如何实现的 对于有栈协程有一种特例实现名为纤程Fiber这个词最早是来自微软公司后来微软还推出过系统层面的纤程包来方便应用做现场保存、恢复和纤程调度。OpenJDK在2018年创建了Loom项目这是Java用来应对本节开篇所列场景的官方解决方案根据目前公开的信息如无意外日后该项目为Java语言引入的、与现在线程模型平行的新并发编程机制中应该也会采用“纤程”这个名字不过这显然跟微软是没有任何关系的。从Oracle官方对“什么是纤程”的解释里可以看出它就是一种典型的有栈协程 what is a fiber?A light weight or user model thread,scheduled by the Java virtual machine,not the operating systemFibers are low footprint and have negligible task-switching overhead.You can have millions of them! Loom项目背后的意图是重新提供对用户线程的支持但与过去的绿色线程不同这些新功能不是为了取代当前基于操作系统的线程实现而是会有两个并发编程模型在Java虚拟机中并存可以在程序中同时使用。新模型有意地保持了与目前线程模型相似的API设计它们甚至可以拥有一个共同的基类这样现有的代码就不需要为了使用纤程而进行过多改动甚至不需要知道背后采用了哪个并发编程模型Loom团队在JVMLS 2018大会上公布了他们对Jetty基于纤程改造后的测试结果同样在5000QPS的压力下以容量为400的线程池的传统模式和每个请求配以一个纤程的新并发处理模式进行对比前者的请求响应延迟在10000至20000毫秒之间而后者的延迟普遍在200毫秒以下在新并发模型下一段使用纤程并发的代码会被分为两部分——执行过程Continuation和调度器Scheduler。执行过程主要用于维护执行现场保护、恢复上下文状态而调度器则负责编排所有要执行的代码的顺序。将调度程序与执行过程分离的好处是用户可以选择自行控制其中的一个或者多个而且Java中现有的调度器也可以被直接重用。事实上Loom中默认的调度器就是原来已存在的用于任务分解的Fork/Join池JDK 7中加入的ForkJoinPoolLoom项目目前仍然在进行当中还没有明确的发布日期上面笔者介绍的内容日后都有被改动的可能。如果读者现在就想尝试协程那可以在项目中使用Quasar协程库[插图]这是一个不依赖Java虚拟机的独立实现的协程库。不依赖虚拟机来实现协程是完全可能的Kotlin语言的协程就已经证明了这一点。Quasar的实现原理是字节码注入在字节码层面对当前被调用函数中的所有局部变量进行保存和恢复。这种不依赖Java虚拟机的现场保护虽然能够工作但很影响性能对即时编译器的干扰也非常大而且必须要求用户手动标注每一个函数是否会在协程上下文被调用这些都是未来Loom项目要解决的问题 © 著作权归作者所有,转载或内容合作请联系作者 喜欢的朋友记得点赞、收藏、关注哦
