java线程处理同一数据-Java关于多线程的演进史，你知道几个？

Tech

导读

本文主要讲述以下几点内容：

1 JDK多线程的演进历史；

2 Java多进程演进中某些技术点的功能原理及背景，以及解决了什么问题 ；

3 针对某些技术点作者的观点，也欢迎读者在评论区探讨观点。

01

前言

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

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

02

里程碑

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

03

手动挡时代

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

JDK 1.0 Thread和Runnable

1996年1月的JDK1.0版本，从一开始就确立了Java最基础的线程模型，并且，这样的线程模型在后续的修修补补中，并未发生实质性的变更，可以说是一个具有传承性的良好设计。

“抢占式”和“协作式”是两种常见的进程/线程调度方式，操作系统非常适合使用抢占式方式来调度它的进程，它给不同的进程分配时间片，对于长期无响应的进程，它有能力剥夺它的资源，甚至将其强行停止；采用协作式的方式java线程处理同一数据，需要进程自觉、主动地释放资源，在这种调度方式下，一个执行时间很长的线程可能使其他所有需要CPU的线程“饿死”。

Java hotspot虚拟机的调度方式为抢占式调用，因此Java语言一开始就采用抢占式线程调度的方式。JDK 1.0中创建线程的方式主要是继承Thread类或实现Runnable接口，通过对象实例的start方法启动线程，需要并行处理的代码放在run方法中，线程间的协作通信采用简单粗暴的stop/resume/suspend这样的方法。

如何解释stop/resume/suspend的概念呢？就是主线程可以直接调用子线程的终止、暂停、继续方法。类比随身听，上面有三个按键：终止、暂停、继续。想象一下如果你同时听3个随身听，3个随身听就是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的涡轮增压时代到来了。

04

自动挡时代

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大量的空间来优化线程内指令的执行。主存中的变量可以被拷贝到线程的工作内存中去单独执行，在执行结束后，结果可以在某个时间刷回主存。

但是java线程处理同一数据，怎样来保证各个线程之间数据的一致性？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；陌生在于实际似乎很少在业务研发过程中使用到它。

甚至有人觉得鸡肋。作者的观点是，对于业务需求相关的研发，基本用不到，因为大批数据量的场景有数仓工具，其它场景可以用线程池代替；如果作为中间件框架编写相关的研发，兴许会用到。

JDK 8.0

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

Completable Future

关于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通道”式的锁抢占。

响应式流

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

什么叫非阻塞背压？背压是back pressure的缩写，简单讲，生产者给消费者推送数据，当消费者处理不动了，告知生产者，此时生产者降低生产速率，此机制使用阻塞的方式实现最简单，即推送时直接返回压力数据。非阻塞方式实现增加了设计的复杂度，同时提高了性能。

为了解决消费者承受巨大的资源压力(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要做一些全局的安全的事情。

全局安全相关的事情包括以下：

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 针对多线程场景推出了性能更高的并发数据结构。这意味着如果代码更新为使用较新的类，由于不必要同步而受益于偏向锁的应用程序，可能会有很大的性能提高。此外，围绕线程池队列和工作线程构建的应用程序，性能通常在禁用偏向锁的情况下变得更好。

05

自动驾驶时代

虚拟线程使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框架。

06

总结

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