全局视角看技术-Java多线程演进史

作者：京东科技 文涛

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

前言

2022年09月22日，JDK19发布了，此版本最大的亮点就是支持虚拟线程，从此轻量级线程家族再添一员大将。虚拟线程使JVM摆脱了通过操作系统调度线程的束缚，由JVM自身调度线程。其实早期sun在Solaris操作系统的虚拟机中实现过JVM调度线程，基于其复杂性，和可维护性考虑，最终都回归到了由操作系统调度线程的模式。

长安归来锦衣客，昨日城南起新宅。回想这一路走来，关于多线程的概念令人烟花缭乱，网上相关讲解也不胜枚举，但总感觉缺少一个全局性的视角。为此笔者系统性的梳理了Java关于多线程的演进史，希望对你掌握多线程知识有帮助。

本文不讲什么：

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

本文讲什么

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

里程碑

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

时代	版本	发布时间	核心概念
手动档	JDK1.0	1996-01-23	Thread和Runnable
手动档	JDK1.2	1998-12-04	ThreadLocal、Collections
自动档	JDK1.5/5.0	2004-09-30	明确Java内存模型、引入并发包
自动档	JDK1.6/6.0	2006-12-11	synchronized优化
自动档	JDK1.7/7.0	2011-07-28	Fork/Join框架
自动档	JDK1.8/8.0	2014-03-18	CompletableFuture、Stream
自动档	JDK1.9/9.0	2014-09-08	改善锁争用机制
自动档	JDK10	2018-03-21	线程-局部管控
自动档	JDK15	2020-09-15	禁用和废弃偏向锁
自动驾驶	JDK19	2022-09-22	虚拟线程

手动档时代

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

JDK 1.0 Thread和Runnable

1996年1月的JDK1.0版本，从一开始就确立了Java最基础的线程模型，并且，这样的线程模型再后续的修修补补中，并未发生实质性的变更，可以说是一个具有传承性的良好设计。抢占式和协作式是两种常见的进程/线程调度方式，操作系统非常适合使用抢占式方式来调度它的进程，它给不同的进程分配时间片，对于长期无响应的进程，它有能力剥夺它的资源，甚至将其强行停止。采用协作式的方式，需要进程自觉、主动地释放资源，在这种调度方式下,可能一个执行时间很长的线程使得其他所有需要CPU的线程”饿死”。Java hotspot虚拟机的调度方式为抢占式调用，因此Java语言一开始就采用抢占式线程调度的方式。JDK 1.0中创建线程的方式主要是继承Thread类或实现Runnable接口，通过对象实例的start方法启动线程，需要并行处理的代码放在run方法中，线程间的协作通信采用简单粗暴的stop/resume/suspend这样的方法。

如何解释stop/resume/suspend的概念呢？就是主线程可以直接调用子线程的终止，暂停，继续方法。如果你小时候用过随身听，上面有三个按键，终止，暂停，继续。想象一下你正在同时听3个随身听，三个随身听就是三个子线程，你就是主线程，你可以随意控制这三个设备的启停。

这一套机制有个致命的问题，就是容易发生死锁，原因在于当线程A锁定了某个资源，还未释放时，被主线程暂停了(suspend方法并不会释放锁)，此时线程B如果想占有这个资源，只能等待线程A执行继续操作（resume）后释放资源，否则将永远得不到，发生死锁。

JDK 1.2

粗暴的stop/resume/suspend机制在这个版本被禁止使用了，转而采用wait/notify/sleep这样的多条线程配合行动的方式。值得一提的是，在这个版本中，原子对象AtomicityXXX已经设计好了，主要是解决i++非原子性的问题。ThreadLocal和Collections的加入增加了多线程使用的姿势，因为这两项技术，笔者称它为Java的涡轮增压时代。

ThreadLocal

ThreadLocal是一种采用无锁的方式实现多线程共享线程不安全对象的方案。它并不能解决“银行账户或库存增加、扣减”这类问题，它擅长将具有“工具”属性的类，通过复本的方式安全的执行“工具”方法。典型的如SimpleDateFormat、库连接等。值得一提的是它的设计非常巧妙，想像一下如果让你设计，一般的简单思路是：在ThreadLocal里维护一个全局线程安全的Map，key为线程，value为共享对象。这样设计有个弊端就是内存泄露问题，因为该Map会随着越来越多的线程加入而无限膨胀，如果要解决内容泄露，必须在线程结束时清理该Map，这又得强化GC能力了，显然投入产出比不合适。于是，ThreadLocal就被设计成Map不由ThreadLocal持有，而是由Thread本身持有。key为ThreadLocal变量，value为值。每个Thread将所用到的ThreadLoacl都放于其中（当然此设计还有其它衍生问题在此不表，感兴趣的同学可以自行搜索）。

Collections

Collections工具类在这个版本被设计出来了，它包装了一些线程安全集合如SynchronizedList。在那个只有Hashtable、Vector、Stack等线程安全集合的年代，它的出现也是具有时代意义的。Collections工具的基本思想是我帮你将线程不安全的集合包装成线程安全的，这样你原有代码升级改造不必花很多时间，只需要在集合创建的时候用我提供方法初始化集合即可。比较像汽车的涡轮增压技术，在发动机排量不变的情况下，增加发动机的功率和扭矩。Java的涡轮增压时代到来了^_

自动档时代

JDK 5.0

引入并发包

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 Specification）给的办法就是，默认情况下，不能保证任意时刻的数据一致性，但是通过对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?

JDK 8.0

此版本的发布对于Java来说是划时代的，以至于现在全世界在运行的Java程序里此版本占据了一半以上。但多线程相关的更新不如JDK5.0那么具有颠覆性。此版本除了增加了一些原子对象之外 ，最亮眼的便是以下两项更新。

CompletableFuture

网上关于CompletableFuture相关介绍很多，大多是讲它原理及怎么用。但是笔者始终不明白一个问题：为什么在有那么多线程池工具的情况下，还会有CompletableFuture的出现，它解决了什么痛点？它的核心竞争力到底是什么？相信你如果进行过思考也会提出这个问题，没关系，笔者已经帮你找到了答案。

结论：CompletableFuture的核心竞争力是任务编排。CompletableFuture继承Future接口特性，可以进行并发执行任务等特性这些能力都是有可替代性的。但它的任务编排能力无可替代，它的核心API中包括了构造任务链，合并任务结果等都是为了任务编排而设计的。所以JDK之所以在此版本引入此框架，主要是解决业务开发中越来越痛的任务编排需求。

最后多说一句，CompletableFuture底层使用了Fork/Join框架实现。

Stream

《架构整洁之道》里曾提到有三种编程范式，结构化编程（面向过程编程）、面向对象编程、函数式编程。Stream是函数式编程在Java语言中的一种体现，笔者认为，初级程序员向中级进阶的必经之路就是攻克Stream，初次接触Stream肯定特别不适应，但如果熟悉以后你将打开一个编程方式的新思路。作为研发人员经常混淆三个概念，函数式编程、Stream、Lambda表达式，总以为他们三个说的是一回事。以下是笔者的理解：

?函数式编程是一种编程思想，各种编程语言中都有该思想的实践

?Stream是JDK8.0的一个新特性，也可以理解新造了个概念，目的就是迎合函数式编程这种思想，通过Stream的形式可以在集合类上实现函数式编程

?Lambda 表达式（lambda expression）是一个匿名函数，通过它可以更简洁高效的表达函数式编程

那么说了这么多，Stream和多线程什么关系？Stream中的相关并行方法底层是使用了Fork/Join框架实现的。《Effective Java》中有一条相关建议“谨慎使用Stream并行”，理由就是因为所有的并行都是在一个通用的Fork/Join池中运行的，一个pipeline运行异常，可能损害其他不相关部分性能。

JDK 9.0

改善锁争用机制

锁争用限制了许多Java多线程应用性能，新的锁争用机制改善了Java对象监视器的性能，并得到了多种基准测试的验证（如Volano）,这类测试可以估算JVM的极限吞吐量。实际中, 新的锁争用机制在22种不同的基准测试中都得到了出色的成绩。如果新的机制能在Java 9中得到应用的话, 应用程序的性能将会大大提升。简单的解释就是当多个线程发生锁争用时，优化之前：晚到的线程统一采用相同的标准流程进行锁等待。优化后：JVM识别出一些可优化的场景时直接让晚到的线程进行“VIP通道”式的锁抢占。

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

响应式流

响应式流(Reactive Streams)是一种以非阻塞背压方式处理异步数据流的标准，提供一组最小化的接口，方法和协议来描述必要的操作和实体。

什么叫非阻塞背压？ 背压是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、C、Erlang、Lua等，他们称之为“协程”。这次java没有新增任何关键字，甚至没有新增新的概念，虚拟线程比起goroutine，协程，要好理解得多，看这名字就大概知道它在做啥了。

JDK 19 虚拟线程

传统Java中的线程模型与操作系统是 1:1 对应的，创建和切换线程代价很大，受限于操作系统，只能创建有限的数量。当并发量很大时，无法为每个请求都创建一个线程。使用线程池可以缓解问题，线程池减少了线程创建的消耗，但是也无法提升线程的数量。假如并发量是2000，线程池只有1000个线程，那么同一时刻只能处理1000个请求，还有1000个请求是无法处理的，可以拒绝掉，也可以使其等待，直到有线程让出。

虚拟线程的之前的方案是采用异步风格。已经有很多框架实现了异步风格的并发编程（如Spring5的Reactor），通过线程共享来实现更高的可用性。原理是通过线程共享减少了线程的切换，降低了消耗，同时也避免阻塞，只在程序执行时使用线程，当程序需要等待时则不占用线程。异步风格确实有不少提升，但是也有缺点。大部分异步框架都使用链式写法，将程序分为很多个步骤，每个步骤可能会在不同的线程中执行。你不能再使用熟悉的 ThreadLocal 等并发编程相关的API，否则可能会有错误。编程风格上也有很大的变化，比传统模式的编程风格要复杂很多，学习成本高，可能还要改造项目中的很多已有模块使其适配异步模式。

虚拟线程的实现原理和一些异步框架差不多，也是线程共享，当然也就不需要池化。在使用时你可以认为虚拟线程是无限充裕的，你想创建多少就创建多少，不必担心会有问题。不仅如此，虚拟线程支持 debug，并且能被 Java 相关的监控工具所支持，这很重要。虚拟线程会使你程序的内存占用大幅降低，所有IO密集型应用，比如Web Servers，都可以在同等硬件条件下，大幅提升IO的吞吐量。原来1G内存，同时可以host 1000个访问，使用虚拟线程后，按照官方的说法，能轻松处理100万的并发，具体到业务场景上能否支撑还要看压力测试，但是我们打个折扣，10万应该能够轻松实现，而你不需要为此付出任何的代价，可能连代码都不用改。因为虚拟线程可以使得你保持传统的编程风格，也就是一个请求一个线程的模式，像使用线程一样使用虚拟线程，程序只需要做很少的改动。虚拟线程也没有引入新的语法，可以说学习和迁移成本极低。

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