【技术专栏】深度对决：Java 21 虚拟线程 (Loom) 终结 Go 并发神话？

🍂 枫言枫语：我是予枫，一名行走在 Java 后端与多模态 AI 交叉路口的研二学生。 “予一人以深耕，观万木之成枫。” 在这里，我记录从底层源码到算法前沿的每一次思考。希望能与你一起，在逻辑的丛林中寻找技术的微光。

在技术圈的演进史中，并发模型一直是一块“兵家必争之地”。

长期以来，Java 开发者在面对高并发场景时，总有一种“英雄气短”的感觉。看着隔壁 Go 语言凭借轻量级的 goroutine 在云原生领域混得风生水起，我们只能守着厚重的线程池，或是钻研那些让人头秃的响应式编程（Reactive Programming）。

但随着 Java 21 的发布，Project Loom 带来的虚拟线程正式转正。这一刻，Java 终于补齐了它在并发领域最后的短板。今天，作为一名深耕 Java、同样关注底层架构的开发者，我将带大家深度拆解这两大并发流派，看看 Java 的“反击战”究竟打得如何。

一、 溯源：为什么传统的 Java 线程“跑不动”了？

要理解虚拟线程，首先要明白传统线程（Platform Thread）的瓶颈在哪里。

1. 1:1 模型的“沉重枷锁”

在 Java 21 之前，每一个 java.lang.Thread 实例都对应一个操作系统的内核线程（Kernel Thread）。这种 1:1 的映射模型带来了两个致命问题：

• 内存开销（The Memory Wall）：内核线程很“贵”。在 Linux 上，一个线程默认的栈空间（Stack Size）通常是 1MB。如果你想开启 100 万个线程，仅仅栈内存就需要 1TB，这显然是不现实的。
• 切换成本（Context Switch）：线程的调度是由操作系统内核负责的。当 CPU 从线程 A 切换到线程 B 时，需要从用户态（User Mode）切换到内核态（Kernel Mode），保存寄存器、程序计数器等上下文。这种切换在微秒级，但在极高并发下，CPU 可能会把一半的时间都花在“搬家”上，而不是真正干活。

2. 线程池：一种“饮鸩止渴”的妥协

为了解决线程太重的问题，我们发明了线程池（Thread Pool）。但这引入了新的矛盾：如果线程池只有 200 个线程，而这 200 个请求都在等待数据库返回（阻塞 IO），那么后续的 2000 个请求只能排队。服务器的 CPU 此时很闲，但由于线程被占满，吞吐量硬生生卡住了。

二、 破局：Java 21 虚拟线程的“黑科技”

Java 21 引入了虚拟线程（Virtual Thread），它彻底改变了游戏规则。

1. 搬运工模型：载体线程与虚拟线程

虚拟线程不再直接映射内核线程。它引入了一个“中间层”：

• 虚拟线程 (Virtual Thread)：极其轻量，一个对象只占几百字节，可以随手创建几百万个。
• 载体线程 (Carrier Thread)：底层的传统线程，负责真正执行代码。

2. 核心机密：Continuation（续体）

虚拟线程之所以能实现“阻塞而不挂起”，靠的是 JVM 内部的 Continuation 机制。

当你在虚拟线程里发起一个阻塞的 IO 调用（比如 Socket.read()）时：

1. 挂起（Yield）：JVM 会感知到阻塞，它会自动把当前虚拟线程的栈帧（Stack Frames）从堆外内存拷贝到 Java 堆（Heap）中，并释放底层的载体线程。
2. 轮询与唤醒：底层的操作系统继续处理 IO。当数据返回后，JVM 收到通知，再把堆里的栈帧拷贝回载体线程，继续从上次断掉的地方往下跑。

一句话总结：虚拟线程让“阻塞”变成了“原地休息”，CPU 转身就去拉别的纤了，实现了 M:N 的高效调度。

三、 宿敌：Go 语言的并发神话

谈到并发，绕不开 Go。Go 语言之所以在云原生领域统治地位稳固，很大程度上归功于它的 GMP 调度模型。

1. 什么是 GMP？

• G (Goroutine)：协程，初始栈只有 2KB，随用随扩。
• M (Machine)：对应物理线程。
• P (Processor)：处理器，逻辑中介，负责把 G 挂载到 M 上。

2. 为什么 Go 显得更轻快？

Go 的编译器和运行时（Runtime）天生就是为协程设计的。它的调度器是在“代码级”实现的，不需要 JVM 这种大型的解释器环境。这让 Go 程序的二进制文件极小，且在高并发小任务场景下具有极佳的响应速度。

四、 巅峰对决：Java Loom vs Go Goroutine

既然两者的原理相似，那么 Java 的这次升级真的能反杀吗？我们从三个维度来看：

1. 编程范式：Java 的“降维打击”

这是 Java 最大的优势。

• Go：你需要学习一套全新的语法（go 关键字、chan、select）。
• Java：你什么都不需要学。你原来的同步代码、try-catch、synchronized 照样写，只需要把 Executors.newFixedThreadPool 换成 Executors.newVirtualThreadPerTaskExecutor。 这意味着数以百万计的存量 Java 项目，可以无痛升级，瞬间获得百万并发能力。

2. 生态兼容性

Java 拥有世界上最成熟的生态。

• 过去：为了高并发，我们得用 WebFlux（异步非阻塞），代码写得像天书，调试（Debug）简直是噩梦。
• 现在：有了虚拟线程，你可以用最直观的顺序逻辑写代码，同时享受异步的性能。JDBC、Spring、MyBatis 统统不需要重写。

3. 技术细节的较量

• 调度方式：Go 的调度是**抢占式（Preemptive）**的，能更均匀地分配 CPU。Java 目前的虚拟线程调度在处理一些 CPU 密集型任务（长时间不放手）时，可能还会出现“线程饥饿”。
• Pinning（钉住）问题：Java 的虚拟线程在执行 synchronized 块或原生方法（JNI）时，目前还不能顺畅地卸载，会暂时“钉”在载体线程上。这是目前 Java 还在优化的痛点。

五、 总结与启发：作为开发者的我们该怎么办？

通过对比，我们可以看到：Java 21 并不是要消灭 Go，而是要在“企业级业务开发”这一主战场上，夺回被响应式编程抢走的领地。

予枫的思考：

1. 对于后端求职者：如果你在面试中能详细讲清楚“虚拟线程如何通过 Continuation 避免内核态切换”，以及它与 Go GMP 模型的异同，面试官对你的评价绝对会上升一个档次。
2. 对于项目选型：如果你的项目是 CPU 密集型（如加解密、复杂计算），请继续使用传统线程池；如果你的项目是典型的 IO 密集型（如知光平台这种需要频繁查询数据库和缓存的社区应用），虚拟线程将是你提升系统吞吐量的核武器。

结束语

没有最好的语言，只有最适合场景的工具。Java 21 的虚拟线程是一场“旧瓶装新酒”的革命，它让我们在享受 Java 严谨生态的同时，也能拥有媲美 Go 的并发爆发力。

关于作者： 💡 予枫，某高校在读研究生，专注于 Java 后端开发与多模态情感计算。💬 欢迎点赞、收藏、评论，你的反馈是我持续输出的最大动力！

我的博客即将同步至腾讯云开发者社区，邀请大家一同入驻： https://cloud.tencent.com/developer/support-plan?invite_code=9wrxwtlju1l 当前加入还有惊喜相送！