全局视角看技术

作者：京东 科技 文涛

全文较长共6468字，言语深刻易懂，是一篇具备纲要性质的关于多线程的梳理，作者从历史演进的角度讲了多线程相关常识体系，让你知其然知其所以然。

前言

2022年09月22日，JDK19颁布了，此版本最大的亮点就是支持虚构线程，从此轻量级线程家族再添一员大将。虚构线程使JVM解脱了经过 操作系统 调度线程的约束，由JVM自身调度线程。其实早期sun在Solaris操作系统的虚构机中成功过JVM调度线程，基于其复杂性，和可保养性思索，最终都回归到了由操作系统调度线程的形式。

长安归来锦衣客，昨日城南起新宅。回忆这一路走来，关于多线程的概念令人烟花纷乱，网上相关解说也举不胜举，但总觉得缺少一个全局性的视角。为此笔者系统性的梳理了关于多线程的演进史，宿愿对你把握多线程常识有协助。

本文不讲什么：

1 不讲某些技术点的详细成功原理，不 拆解 源码，不画图，假设从本文找到了你感兴味的概念和技术可以自行搜查 2 不讲支持并发性的库和框架，如Quasar、Akka、Guava等

本文讲什么

1 讲JDK多线程的演进历史 2 讲演进中某些技术点的配置原理及背景，以及处置了什么疑问 3 讲针对某些技术点笔者的看法，欢迎有不同看法的人在评论区讨论

里程碑

老规矩，先上个统计表格。其中梳理了历代JDK中关于线程相关的**概念。在这里，做一个或许不太失当的比喻，可以将多线程的演进映射到汽车上，多线程的演进区分教训了手动档时代(JDK1.4及以下)，智能档时代（JDK5-JDK18）， 智能驾驶 时代(JDK19及以后)。这个比喻只为了通知读者JDK5以后可以有更舒适姿态的驾驭多线程，JDK19以后更是打破了单纯的舒适，它给IO密集型服务的性能带来了质的飞跃。

手动档时代

JDK1.4及以下笔者称之为多线程“手动档”的时代，也叫原生多线程时代。线程的操作还相对原生，没有线程池可用。研发人员必需手写工具防止频繁创立线程形成资源糜费，手动对共享资源加锁。也正是这个时代酝酿了许多低劣的多线程框架，最有名的被JDK5.0采用了。

JDK 1.0 Thread和Runnable

1996年1月的JDK1.0版本，从一开局就确立了Java最基础的线程模型，并且，这样的线程模型再后续的修修补补中，并未出现实质性的变卦，可以说是一个具备传承性的良好设计。抢占式和协作式是两种经常出现的进程/线程调度方式，操作系统十分适宜经常使用抢占式方式来调度它的进程，它给不同的进程调配期间片，关于常年无照应的进程，它有才干剥夺它的资源，甚至将其强行中止。采用协作式的方式，要求进程自觉、被动地监禁资源，在这种调度方式下,或许一个执行期间很长的线程使得其余一切要求的线程”饿死”。Java hotspot虚构机的调度方式为抢占式调用，因此Java言语一开局就采用抢占式线程调度的方式。JDK 1.0中创立线程的方式关键是承袭Thread类或成功Runnable 接口 ，经过对象实例的start方法启动线程，要求并行处置的代码放在run方法中，线程间的协作 通讯 采用便捷粗犷的stop/resume/suspend这样的方法。

如何解释stop/resume/suspend的概念呢？就是主线程可以间接调用子线程的中断，暂停，继续方法。假设你小时刻用过随身听，下面有三个按键，中断，暂停，继续。构想一下你正在同时听3个随身听，三个随身听就是三个子线程，你就是主线程，你可以轻易控制这三个设施的启停。

这一套机制有个致命的疑问，就是容易出现死锁，要素在于当线程A锁定了某个资源，还未监禁时，被主线程暂停了(suspend方法并不会监禁锁)，此时线程B假构想占有这个资源，只能期待线程A执行继续操作（resume）后监禁资源，否则将永远得不到，出现死锁。

粗犷的stop/resume/suspend机制在这个版本被制止经常使用了，转而采用wt/notify/sleep这样的多条线程配合执行的方式。值得一提的是，在这个版本中，原子对象AtomicityXXX曾经设计好了，关键是处置i++非原子性的疑问。ThreadLocal和Collections的参与参与了多线程经常使用的姿态，由于这两项技术，笔者称它为Java的涡轮增压时代。

ThreadLocal

ThreadLocal是一种采用无锁的方式成功多线程共享线程不安保对象的打算。它并不能处置“银行账户或库存参与、扣减”这类疑问，它长于将具备“工具”属性的类，经过复本的方式安保的执行“工具”方法。典型的如plFormat、库衔接等。值得一提的是它的设计十分奇妙，想像一下假设让你设计，普通的便捷思绪是：在ThreadLocal里保养一个全局线程安保的Map，key为线程，value为共享对象。这样设计有个弊病就是内存暴露疑问，由于该Map会随着越来越多的线程参与而有限收缩，假设要处置内容暴露，必需在线程完结时清算该Map，这又得强化GC才干了，显然投入产出比不适宜。于是，ThreadLocal就被设计成Map不禁ThreadLocal持有，而是由Thread自身持有。key为ThreadLocal变量，value为值。每个Thread将所用到的ThreadLol都放于其中（当然此设计还有其它衍生疑问在此不表，感兴味的同窗可以自行搜查）。

Collections

Collections工具类在这个版本被设计进去了，它包装了一些线程安选汇合如SynchronizedList。在那个只要Hashtable、Vector、Stack等线程安选汇合的年代，它的出现也是具备时代意义的。Collections工具的基本思维是我帮你将线程不安保的汇合包装成线程安保的，这样你原有代码更新变革不用花很多期间，只要要在汇合创立的时刻用我提供方法初始化汇合即可。比拟像汽车的涡轮增压技术，在发起机排量不变的状况下，参与发起机的功率和扭矩。Java的涡轮增压时代来到了^_^

智能档时代

引入并发包

Doug Lea，中文名为道格·利。是美国的一个大学教员，大神级的人物，J.U.C就是出自他之手。JDK1.5之前，咱们控制程序并发访问同步代码只能经常使用synchronized，那个时刻synchronized的性能还没优化好，性能并不好，控制线程也只能经常使用Object的wait和notify方法。这个时刻Doug Lea给JCP提交了JSR-166的提案，在提交JSR-166之前，Doug Lea曾经经常使用了相似J.U.C包配置的代码曾经三年多了，这些代码就是J.U.C的原型。

J.U.C提供了原子化对象、锁及工具套装、线程池、线程安保容器等几大类工具。研发人员可灵敏的经常使用恣意才干搭建自己的 产品 ，进可经常使用ReentrantLock搭建底层框架，退可间接经常使用现成的工具或容器启动业务代码编写。站在历史的角度去看，J.U.C在2004年毫无争议可以称为“尖端科技产品”。为Java的推行立下了悍马功劳。Java的智能档时代来到了，就好比智能档的汽车降落司机的门槛一样，J.U.C大大降落了 程序员 经常使用多线程的门槛。这是个开创了一个时代的产品。

当然J.U.C雷同存在一结瑕疵：

CPU开支大 ：假设自旋CAS常年间地不成功，则会给CPU带来十分大的开支。

处置打算：在JUC中有些中央就限度了CAS自旋的次数，例如BlockingQueue的SynchronousQueue。

ABA疑问 ：假设一个值原来是A，变成了B，而后又变成了A，在CAS审核时会发现没有扭转，但实践它曾经扭转，这就是ABA疑问。大部分状况下ABA疑问不会影响程序并发的正确性。

处置打算：每个变量都加上一个版本号，每次扭转时加1，即A —> B —> A，变成1A —> 2B —> 3A。Java提供了AtomicStampedReference来处置。AtomicStampedReference经过包装[E,Integer]的元组来对对象标志版本戳（stamp），从而防止ABA疑问。

只能保障一个共享变量原子操作 ：CAS机制所保障的只是一个变量的原子性操作，而不能保障整个代码块的原子性。

处置打算：比如要求保障3个变量独特启动原子性的更新，就不得不经常使用Synchronized了。还可以思索经常使用AtomicReference来包装多个变量，经过这种方式来处置多个共享变量的状况。

明白Java内存模型

此版本的JDK从新明白了Java内存模型，在这之前，经常出现的内存模型包括延续分歧性内存模型和后行出现模型。 关于延续分歧性模型来说，程序执行的顺序和代码上显示的顺序是齐全分歧的。这关于现代多核，并且指令执行优化的CPU来说，是很难保障的。而且，顺序分歧性的保障将JVM对代码的运转期优化重大限度住了。

但是此版本JSR 133规范指定的后行出现（Happens-before）使得执行指令的顺序变得灵敏：

在同一个线程外面，依照代码执行的顺序（也就是代码语义的顺序），前一个操作先于前面一个操作出现 对一个monitor对象的解锁操作先于后续对同一个monitor对象的锁操作 对volatile字段的写操作先于前面的对此字段的读操作 对线程的start操作（调用线程对象的start()方法）先于这个线程的其余任何操作 一个线程中一切的操作先于其余任何线程在此线程上调用 join()方法 假设A操作优先于B，B操作优先于C，那么A操作优先于C

而在内存调配上，将每个线程各自的上班内存从主存中独立进去，更是给JVM少量的空间来优化线程内指令的执行。主存中的变量可以被拷贝到线程的上班内存中去独自执行，在执行完结后，结果可以在某个期间刷回主存： 但是，怎样来保障各个线程之间数据的分歧性？JLS（Java Language Specifation）给的方法就是，自动状况下，不能保障恣意时辰的数据分歧性，但是经过对synchronized、volatile和final这几个语义被增强的关键字的经常使用，可以做到数据分歧性。

JDK 6.0 synchronized优化

作为“共和国长子”synchronized关键字，在5.0版本被ReentrantLock压过了风头。这个版本必要求扳回一局，因此JDK 6.0对锁做了一些优化，比如锁自旋、锁消弭、锁兼并、轻量级锁、所倾向等。本次优化是对“精细化治理”这个理念的一次性诠释。没优化之前被synchronized加锁的对象只要两个形态：无锁，有锁（重量级锁）。优化后锁一共存在4种形态，级别从低到高依次是：无锁、倾向锁、轻量级锁、重量级锁。这几个形态随着竞争的状况逐渐更新，但是不能升级，目的是为了提高失掉锁和监禁锁的效率（笔者以为其实是太复杂了，JVM研发人员望而生畏了）。

这一次性优化让synchronized扬眉吐气，自此再也不准许他人说它的性能比ReentrantLock差了。但好戏还在后头，倾向锁在JDK 15被废除了（─.─||）。笔者以为synchronized吃亏在了它只是个关键字，JVM担任它底层的举措，究竟运行程序加锁的时刻什么样的姿态舒适，得靠JVM“猜”。ReentrantLock就不同了，它将这件事间接交给程序员去处置了，你宿愿偏心那就用偏心锁，你宿愿你的不偏心，那你就用非偏心锁。设计层面算是一种偷懒，但同时也是一种灵敏。

JDK 7.0 Fork/Join框架

Fork/Join的降生也是一个比拟先进的产品，它的**竞争力在于，支持递归式的义务拆解，同时将各义务结果启动兼并。但它是一个既相熟又生疏的技术，相熟在于它被运行到各种中央，比如接上去JDK8.0要讲的CompletableFuture和Stream；生疏在于咱们仿佛很少在业务研发环节中经常使用到它。

甚至有人甚至觉得它鸡肋。笔者的观念是，你假设是业务需求相关的研发，它是鸡肋的，由于基本用不到，少量数据量的场景有数仓那套工具，其它场景可以用线程池替代；假设你是两边件框架编写相关的研发，它不鸡肋，也许会用到。中文互联网上很少有人质疑这项技术，但国外曾经有人在讨论，感兴味的可以间接跳转查阅 Is the Fork-Join framework in Java broken?

此版本的颁布关于Java来说是划时代的，以致于如今全环球在运转的Java程序里此版本占据了一半以上。但多线程相关的更新不如JDK5.0那么具备推翻性。此版本除了参与了一些原子对象之外 ，最亮眼的便是以下两项更新。

CompletableFuture

网上关于CompletableFuture相关引见很多，大多是讲它原理及怎样用。但是笔者一直不明白一个疑问：为什么在有那么多线程池工具的状况下，还会有CompletableFuture的出现，它处置了什么痛点？它的**竞争力究竟是什么？置信你假设启动过思索也会提出这个疑问，没相关，笔者曾经帮你找到了答案。

论断：CompletableFuture的**竞争力是 义务编排 。CompletableFuture承袭Future接口特性，可以启动并发执行义务等特性这些才干都是有可替代性的。但它的义务编排才干无可替代，它的**A中包括了结构义务链，兼并义务结果等都是为了义务编排而设计的。所以JDK之所以在此版本引入此框架，关键是处置业务开发中越来越痛的义务编排需求。

最后多说一句，CompletableFuture底层经常使用了Fork/Join框架成功。

《架构整洁之道》里曾提到有三种 编程 范式，结构化编程（面向环节编程）、面向对象编程、函数式编程。Stream是函数式编程在Java言语中的一种表现，笔者以为，高级程序员向中级进阶的必修之路就是攻克Stream，首次接触Stream必需特意不顺应，但假设相熟以后你将关上一个编程方式的新思绪。作为研发人员经常混杂三个概念，函数式编程、Stream、Lambda表白式，总以为他们三个说的是一回事。以下是笔者的了解：

•函数式编程是一种编程思维，各种编程言语中都有该思维的通常

•Stream是JDK8.0的一个新特性，也可以了解新造了个概念，目的就是迎合函数式编程这种思维，经过Stream的方式可以在汇合类上成功函数式编程

•Lambda 表白式（lambda expression）是一个匿名函数，经过它可以更繁复高效的表白函数式编程

那么说了这么多，Stream和多线程什么相关？Stream中的相关并行方法底层是经常使用了Fork/Join框架成功的。《Effective Java》中有一条相关倡导“审慎经常使用Stream并行”，理由就是由于一切的并行都是在一个通用的Fork/Join池中运转的，一个pipeline运转意外，或许侵害其余不相关部分性能。

改善锁争用机制

锁争用限度了许多Java多线程运行性能，新的锁争用机制改善了Java对象监督器的性能，并失掉了多种基准测试的验证（如Volano）,这类测试可以预算JVM的极限吞吐量。实践中, 新的锁争用机制在22种不同的基准测试中都失掉了杰出的效果。假设新的机制能在Java 9中失掉运行的话, 运行程序的性能将会大大优化。便捷的解释就是当多个线程出现锁争用时，优化之前：晚到的线程一致采用相反的规范流程启动锁期待。优化后：JVM识别出一些可优化的场景时间接让晚到的线程启动“VIP通道”式的锁抢占。

详细解释请参考： Contended locks explained – a peormance approach

照应式流

照应式流(Reactive Stre)是一种以非阻塞背压方式处置异步数据流的规范，提供一组最小化的接口，方法和协定来形容必要的操作和实体。

什么叫非阻塞背压？ 背压是back pressure的缩写，便捷讲，消费者给消费者推送数据，当消费者处置不动了，告知消费者，此时消费者降落消费速率，此机制经常使用阻塞的方式成功最便捷，即推送时间接前往压力数据。非阻塞方式成功参与了设计的复杂度，同时提高了性能。 PS:觉得背压这个词翻译的不好，不能顾名思义。反压是不是更好^_^

为了处置消费者接受渺小的资源压力(pressure)而有或许解体的疑问，数据流的速度要求被控制，即流量控制(flow control)，以防止极速的数据流不会压垮指标。因此要求反压即背压(back pressure)，消费者和消费者之间要求经过成功一种背压机制来互操作。成功这种背压机制要求是异步非阻塞的，假设是同步阻塞的，消费者在处置数据时消费者必需期待，会发生性能疑问。

照应式流(Reactive Streams)经过定义一组实体，接口和互操作方法，给出了成功非阻塞背压的规范。第三方遵照这个规范来成功详细的处置打算，经常出现的有Reactor，RxJava，Akka Streams，Ratpack等。

JDK 10 线程-部分管控

Safepoint及其无余：

Safepoint是Hotspot JVM中一种让一切运行程序中止的一种机制。JVM为了做一些底层的上班，必要求Stop The World，让运行线程都停上去。但不能粗犷的间接中止，而是会给运行线程发送个指令 信号 通知他，你该停下了。此时运行线程执行到一个Safepoint点时就会遵从指令并照应。这也是为什么叫Safepoint。之所以加safe，是强调JVM要做一些全局的安保的事件了，所以给这个点加了个safe。

全局的安保的事件包括以下： 1、渣滓清算暂停 2、代码去优化（Code deoptimization）。 3、flush code cache。 4、类文件从新定义时（Class redefinition，比如热更新 or instrumentation)。 5、倾向锁的敞开（Biased lock revocation）。 6、各种debug操作(比如： 死锁审核或许stacktrace dump等)。

但是，让一切线程都到就近的safepoint停上去自身就要求较长的期间。而且让一切线程都停上去是不是显得太过莽撞和专断了呢。为此Java10就引入了一种可以不用stop all threads的方式，就是线程-部分管控（Thread Local Handshake）。

比如以下是不要求stop一切线程就可以搞定的场景： 1、倾向锁撤销。这个事件只要要中止单个线程就可以撤销倾向锁，而不要求中止一切的线程。 2、缩小不同类型的可服务性查问的总体VM提前影响，例如失掉具备少量Java线程的VM上的一切线程的stack trace或许是一个缓慢的操作。 3、经过缩小对信号（signals）的依赖来执行更安保的stack trace采样。 4、经常使用所谓的非对称Dekker同步技术，经过与Java线程握手来消弭一些内存阻碍。 例如，G1和CMS里经常使用的“条件卡标志码”（conditional card mark code），将不再要求“内存屏障”这个东东。这样的话，G1发送的“写屏障（write barrier）”就可以被优化， 并且那些尝试要规避“内存屏障”的分支也可以被删除了。

JDK 15 禁用和废除倾向锁

为什么要废除倾向锁？倾向锁在过去带来的的性能优化，在如今看来曾经不那么显著了。受益于倾向锁的运行程序，往往是经常使用了早期 Java 汇合 API的程序（JDK 1.1），这些 API（Hashtable 和 Vector） 每次访问时都启动同步。JDK 1.2 引入了针对复线程场景的非同步汇合（HashMap 和 ArrayList），JDK 1.5 针对多线程场景推出了性能更高的并发数据结构。这象征着假设代码更新为经常使用较新的类，由于不用要同步而受益于倾向锁的运行程序，或许会看到很大的性能提高。此外，围绕线程池队列和上班线程构建的运行程序，性能通常在禁用倾向锁的状况下变得更好。

以下以经常使用了Hashtable 和 Vector的API成功： java.lang.Classloader uses Vector java.util.Properties extends Hashtable java.security.Provider extends Properties java.net.URL uses Hashtable java.net.URConnection uses Hashtable java.util.ZipOutputStream uses Vector javax.management.timer.TimerMBean has Vector on the interface

智能驾驶时代

虚构线程使Java进入了智能驾驶时代。很多言语都有相似于“虚构线程”的技术，比如Go、、Erlang、Lua等，他们称之为“协程”。这次java没有新增任何关键字，甚至没有新增新的概念，虚构线程比起goroutine，协程，要好了解得多，看这名字就大略知道它在做啥了。

JDK 19 虚构线程

传统Java中的线程模型与操作系统是 1:1 对应的，创立和切换线程代价很大，受限于操作系统，只能创立有限的数量。当并发量很大时，不可为每个恳求都创立一个线程。经常使用线程池可以缓解疑问，线程池缩小了线程创立的消耗，但是也不可优化线程的数量。假设并发量是2000，线程池只要1000个线程，那么同一时辰只能处置1000个恳求，还有1000个恳求是不可处置的，可以拒绝掉，也可以使其期待，直到有线程让出。

虚构线程的之前的打算是采用异步格调。曾经有很多框架成功了异步格调的并发编程（如Spring5的Reactor），经过线程共享来成功更高的可用性。原理是经过线程共享缩小了线程的切换，降落了消耗，同时也防止阻塞，只在程序执行时经常使用线程，当程序要求期待时则不占用线程。异步格调确实有不少优化，但是也有缺陷。大部分异步框架都经常使用链式写法，将程序分为很多个步骤，每个步骤或许会在不同的线程中执行。你不能再经常使用相熟的 ThreadLocal 等并发编程相关的API，否则或许会有失误。编程格调上也有很大的变动，比传统形式的编程格调要复杂很多，学习老本高，或许还要变革名目中的很多已有模块使其适配异步形式。

虚构线程的成功原理和一些异步框架差不多，也是线程共享，当然也就不要求池化。在经常使用时你可以以为虚构线程是有限富余的，你想创立多少就创立多少，不用担忧会有疑问。不只如此，虚构线程支持 debug，并且能被 Java 相关的监控工具所支持，这很关键。虚构线程会使你程序的内存占用大幅降落，一切IO密集型运行，比如Web Serve，都可以在等同 配件 条件下，大幅优化IO的吞吐量。原来1G内存，同时可以host 1000个访问，经常使用虚构线程后，依照官网的说法，能轻松处置100万的并发，详细到业务场景上是否撑持还要看压力测试，但是咱们打个折扣，10万应该能够轻松成功，而你不要求为此付出任何的代价，或许连代码都不用改。由于虚构线程可以使得你坚持传统的编程格调，也就是一个恳求一个线程的形式，像经常使用线程一样经常使用虚构线程，程序只要要做很少的改动。虚构线程也没有引入新的语法，可以说学习和迁徙老本极低。

值得一提的是虚构线程底层依然经常使用了Fork/Join框架。

介绍 阅读

SaaS租户隔离及存储打算梳理

参考

java多线程的开展简史

Java 19 Virtual Threads--Java的虚构线程来到，给带来哪些扭转？

Java19 正式 GA！看虚构线程如何大幅提高系统吞吐量

虚构线程 - VirtualThread源码透视

内核开展史和linux发行版

Is the Fork-Join framework in Java broken?

Java Concurrency Evolution

如何看待Spring 5引入函数式编程思维以及Reactor?

java 锁竞争_Java 9（JEP 143）中针对竞争锁的优化

Contended locks explained – a performance approach

一次性与印度兄弟就Java10中的Thread-Local Handshakes的讨论

Disable biased-locking and deprecate all flags related to biased-locking

Why Do We Need Completable Future?

java并发包JUC降生及详细内容

Java 19 Virtual Threads--Java的虚构线程来到，给带来哪些扭转？

照应式流(Reactive,Streams)

JAVA19虚构线程以及原理审核编辑 黄宇