本文永久链接 – https://tonybai.com/2026/05/07/aws-guru-slams-go-concurrency-as-a-joke-vs-jvm
大家好，我是Tony Bai。
过去十年，如果要在后端技术圈选出一个“金字招牌”，那无疑是 Go 语言的并发。
凭借其极简的 go 关键字和优雅的 channel，Go 将并发编程的门槛从“博士级”拉到了“入门级”。在云原生和微服务的浪潮中，Go 几乎就是“高并发”的代名词。
但就在前几天，AWS 的资深布道师 James Ward，在 X 平台上突然向 Go 语言的这个“优势高地”发起了猛烈炮轰：
“开发者普遍认为 Go 在并发方面很出色。但事实并非如此。JVM 的方案要优越得多。当你把虚拟线程、结构化并发和 Effects 加进来时，它甚至是全行业最好的方案之一。”
为了证明自己的观点，他还引用了前 Google 工程师 Ahmetb（以其在 K8s 社区的贡献而闻名）设计的一道极其刁钻的并发编程“考题”——实现一个工业级的、线程安全的网络连接池。
这道题，像一块试金石，炸出了 Go 并发模型背后那些被“易用性”所掩盖的无数“天坑”。
这场由大神发起的“语言战争”，瞬间引爆了技术圈。从前 Uber 工程师到 Victoria Metrics 的核心开发者，无数 Gopher 下场“护驾”。
今天，我们就来复盘这场神仙打架，看看当 Go 的“平民法拉利”遭遇现代 JVM 的“德系重装甲”时，到底谁才是真正的并发之王？
让我们先来看看点燃这场战争的导火索，Ahmetb 设计的这道“连接池”考题：
你需要实现一个线程安全的、有界连接池。
1. Acquire()：当池中无可用连接时，必须阻塞。必须响应 context 的超时和取消。
2. Release()：归还连接。如果池已满或连接已损坏，则关闭连接而不是泄漏。
3. Close()：必须干净利落地关闭整个池。停止接受新请求，立即关闭所有空闲连接，并等待所有正在被使用的连接被归还后，再关闭它们。
4. IdleTimeout：自动清理超过空闲时长的连接。
这道题，看似简单，实则布满了“杀机”。
它几乎涵盖了并发编程中所有最令人头疼的场景：资源限制、优雅启停、生命周期管理、超时与取消、后台清理……
Ahmetb 坦言：
“如果你享受 Go 的并发原语，那就挑战一下自己去实现它。这里面的边缘情况，比我最初想象的要多得多。”
而 James Ward 正是借着这道题，打出了他的第一炮：用 Go 的原生 channel 和 select 去完美地解决所有这些问题，其代码量和心智负担，将远超现代 JVM 的解决方案。
面对 James 的炮轰，评论区迅速分裂成两大阵营。
Go 阵营（以实战派为首）的反击：
前 Uber 工程师 Ovais Tariq 现身说法：
“Go 在高并发工作负载下更优越——这是我在 Uber 运营大规模 Go 服务的实践经验。”
另一位开发者则指出了 Go 的核心优势：
“我完全同意（Go 更优）。这个工具（Go）被创造出来，就是为了无缝处理成千上万个大部分时间都在‘等待’I/O 的任务。在这个角色上，Go 至今仍然表现卓越。”
Go 阵营的核心观点是：Go 的并发模型（Goroutine + Channel），就像一把简单、锋利的匕首。它足够轻、足够快，虽然需要使用者自己具备高超的技巧，但在真实的、海量的 I/O 密集型场景下，它的实战表现就是最好的证明。
JVM 阵营（以理论派为首）的降维打击：
James Ward 则对这些“实践经验”嗤之以鼻：
“真的吗？像 Scala ZIO 这样的 Effect 调度器和虚拟线程，在安全处理非阻塞任务时，看起来比 Goroutine 要容易得多。”
JVM 阵营的核心观点是：Go 的并发原语太“低级”了。 它把所有关于取消、超时、错误传播、资源清理的复杂性，全部甩给了开发者。而现代 JVM 生态，通过虚拟线程、结构化并发（Structured Concurrency）和函数式 Effect 系统（如 ZIO, Arrow Fx），已经从语言和框架层面，为你提供了一套“三位一体”的、体系化的解决方案。
这场争论的本质，是“游击队”与“正规军”的对决。Go 提供了最灵活的单兵作战武器，而 JVM 则提供了一整套陆海空协同作战的军事体系。
在这场混乱的口水战中，Victoria Metrics 的工程师 Phuong Le 的一篇复盘长文，将整个讨论提升到了哲学的高度。
他没有去争论谁快谁慢，而是深刻地剖析了两种技术路线背后的设计哲学差异：
“Go 在并发方面并不差。一个更真实的说法是：Go 擅长让并发变得廉价、显式和易于上手，尤其是在常见的后端模式中。”
Phuong Le 指出，Go 的核心优势在于“平民化（Approachable）”。
它用极其简单的原语，让一个普通的开发者，也能快速地写出“看起来能用”的并发代码。但这种“简单”的代价是，它把大量的“正确性”责任，下放给了开发者自己。
“Go 给了你相对低级的原语。大量关于取消、任务生命周期、清理、错误传播和背压的正确性保证，都留给了我们程序员自己去处理。”
而现代 JVM 生态，则走向了另一个极端——“专家系统”。
它试图在框架和语言层面，构建一个极其复杂、但理论上绝对安全的“象牙塔”。开发者需要学习大量的概念（Monad, Functor, Fiber…），但一旦学会，就能获得极高的安全性保障。
Phuong Le 的结论是：
“所以，公平的比较不是‘Go vs JVM，谁赢？’，而是：Go 优化的是简单的、实用的并发；而现代 JVM 生态，拥有更强大的工具来处理结构化的、资源安全的并发。 到底哪个更好，取决于你面临的并发问题有多复杂。”
这场神仙打架，最终没有赢家。但它为我们所有后端架构师，提供了一次极其宝贵的“架构选型”公开课。
1. 承认 Go 的“天花板”
我们必须承认，Go 的原生并发原语，在处理极其复杂的、需要精细化资源管理的场景时，确实存在“天花板”。Ahmetb 的那道“连接池”考题，就是一个完美的试金石。如果你团队的业务复杂到这种程度，直接引入一个成熟的第三方库（或者评估 JVM 生态），可能比自己手搓 Channel 要明智得多。
2. 警惕 JVM 的“学习曲线”
虚拟线程虽然抹平了 JVM 在并发“数量”上与 Go 的差距，但结构化并发和 Effect 系统，依然是较为陡峭的学习曲线。在一个追求快速迭代、人员流动频繁的团队里，引入这些“重型武器”的培训成本和心智负担，是必须被严肃评估的。(注：不知道有多少Java开发至今也没有使用过虚拟线程)
3. “足够好”也许就是最好的
评论区里，Jacob Voytko 的观点极具代表性：
“Go 的并发原语并非在所有方面都理想，但对于终端用户（业务开发者）大多数时候写的那些东西来说，它们是完美的。管理 fan-in/fan-out、处理带超时的异步任务……对于这些 80% 的场景，Go 的‘足够好’方案已经足够了。”
这场由 James Ward 发起的“Go 并发之战”，最终以一场关于“架构权衡（Trade-offs）”的深刻反思而告终。
它像一面镜子，照出了我们这个行业最真实的底色：从来没有“最好的”语言，只有“最适合的”场景。
Go 的成功，在于它用最简单的武器，解决了云原生时代最大多数的并发问题。它的哲学，是牺牲一部分理论上的“完美”，去换取工程上的“极致效率”。
而现代 JVM 的进化，则代表了另一种可能：通过不断叠加更高级的抽象，去追求一个理论上“绝对安全”的并发乌托邦。
作为架构师，我们的终极使命，不是去争论哪条路更高贵，而是在理解了所有路径的代价之后，为我们的团队、我们的业务，选择那条最务实的、能活着走到终点的路。
资料链接：
今日互动探讨：
你如何看待 James Ward“Go 并发不行”的观点？在你的实战中，Goroutine+Channel 是否真的“够用”？或者你更期待 Go 能引入类似 JVM 的“结构化并发”？
欢迎在评论区分享你的看法！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
Related posts:
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。