Java被喷了30年"笨重"，但银行系统还在用它扛住每秒12万笔交易

2024年Stack Overflow调研显示，Java仍占据企业后端开发35%的份额——这个数字和十年前几乎没变。可打开技术社区，你看到的是另一幅画面：新手教程里它被当成"legacy语言"一笔带过，面试题里"如何避免Java代码臃肿"成了必考点。

问题从来不是Java没用了。是大多数人评价编程语言的标准，和严肃软件要解决的实际问题，早就脱节了。

那场永远在重复的辩论

某个开发者用Java写了基础课作业，或者抄了几段冗长的示例代码，再拿它和为快速原型优化的脚本语言对比——结论总是雷同：过时、啰嗦、太"企业级"。像是被迫使用，而非主动选择。

这个判断在三个前提下成立：追求语法新鲜感、迷恋极简符号、只关心单个文件里的编码快感。

前提一变，结论就崩。

银行不会告诉你的事

全球前50大银行的核心交易系统，超过80%基于Java构建。不是因为他们怀旧，是因为当每秒要处理12万笔并发交易、且不允许丢一条数据时，"啰嗦"的显式类型声明和严格的编译期检查，从负担变成了保险。

作者Rupan Prasai打了个比方：用脚本语言快速搭个Demo，像用胶带和硬纸板做飞机模型；而Java的设计哲学，是假设你最终要造一架真的能飞的客机。胶带在风洞里会融化，硬纸板扛不住气压差——这些在桌面演示时根本看不见。

真正的问题从来不是语法行数，是故障发生时你能不能定位到具体哪一行。

"正确"使用Java的隐藏条件

Prasai的核心观点是：Java的口碑崩塌，源于大量使用者根本没按它的设计意图来。Spring Boot让启动项目变得太容易，结果一堆人把本该拆成微服务的单体应用硬塞进去；Stream API被用来写一行式"聪明代码"，可读性反而比传统循环更差。

语言给了工具，使用者选了最省力的那把，然后抱怨工具太重。

这有点像抱怨单反相机不如手机拍照快——如果你只发社交媒体，确实如此。但当你需要打印两米宽的户外广告时，手机的那点像素会暴露一切。

一个被忽略的时间线

Java近年的更新节奏在加快：每六个月一个特性版本，模式匹配、虚拟线程、值类型逐一落地。Project Loom让高并发编程的代码复杂度大幅下降，而保持类型安全这个底线不动。

换句话说，它正在吸收其他语言的优点，同时拒绝放弃自己安身立命的东西。

社区里有个老梗：Java程序员35岁不会失业，因为维护那些跑了二十年的系统需要人——而且得是能读懂当年设计意图的人。这个梗讽刺了两件事：一是Java系统的长寿，二是行业对"能长期运转"这件事的复杂情绪。

Prasai在文末留了句话：「选择语言时，先想清楚你要解决的问题是会存在六个月，还是十六年。」

你的项目打算活多久？