Java的中年危机:从基础设施到云原生时代的生态博弈

上周跟某股份制银行的核心系统架构师吃饭,他吐槽说团队12个开发,8个是写了五到十年Java的老炮,现在要迁云原生,一半人对着Spring Cloud Alibaba的源码挠头——这不是个例。 很多人说Java老了,没用了,现在都用Go写微服务,用Rust写底层,Python写AI。但你去翻国内的核心系统,从银行的交易核心到运营商的计费系统,从电商的订单中台到政务的社保平台,跑的最多的还是Java。这东西就像公司里的老员工,平时没人注意,一旦出问题,全公司都得停摆。

从“一次编写到处运行”到字节码的隐形枷锁

当年Sun推出Java的时候,打的旗号是“Write Once, Run Anywhere”,在那个操作系统五花八门,硬件平台也乱七八糟的年代,这个口号简直是降维打击。你写的Java代码,编译成字节码,不管是跑在Windows还是Solaris,还是x86还是SPARC,只要有JVM就能跑。 但很少有人提的是,这个跨平台的代价,是JVM这个中间层带来的隐形枷锁。 Java的核心不是语法,是JVM的内存模型和字节码执行机制。你写的代码不是直接跑在硬件上的,是先编译成字节码,交给JVM的解释器先跑着,后面再通过JIT编译成机器码,慢慢优化执行速度。
Java JVM运行时内存结构示意图
Java JVM运行时内存结构示意图
这就带来了两个天生的问题:启动慢,内存占的多。 别跟我扯什么GraalVM能解决。我试过,把一个中型的Spring Boot应用编译成原生镜像,光编译就耗了12分钟,中间还因为反射配置漏了三个第三方库直接崩了。谁爱用谁用。 对于那些需要秒级启动的Serverless应用,或者是边缘计算的小设备来说,Java这个毛病简直是致命的。Go写的应用编译完就是个几十兆的二进制文件,启动时间毫秒级,内存占个几十兆就能跑,Java呢?随便一个Spring Boot应用启动就要几秒钟,占个几百兆内存是家常便饭。 不过话说回来,Java的这个“缺点”,在那些对稳定性要求极高的核心系统里,反而成了优点。因为JVM帮你挡了很多底层的问题,内存泄漏了有垃圾回收器帮你擦屁股,跨平台出问题了有JVM帮你兼容,你不用管底层的硬件和操作系统是什么,只要写业务逻辑就行。

2024年的Java生态:一半是存量护城河,一半是增量泥潭

现在的Java生态,说白了就是两个世界:一个是跑了十几年的存量系统,一个是正在折腾的增量云原生场景。 先说存量。公开的调研数据显示,国内金融行业核心交易系统的Java占比超过70%,电商领域的中后台服务Java占比甚至接近90%。这些系统跑了十几年,堆了多少历史包袱,只有维护的人知道。 我见过最离谱的一个项目,是某省的社保系统,用的还是Java 8,还是2019年的版本,连安全补丁都没打。问为什么不升?答曰“升了怕出问题,领导担不起责任”。 这就是Java存量市场的真实写照。不是技术好不好,是敢不敢动。 然后是生态的变化。Oracle当年靠Java赚了不少钱,后来越来越急,2019年之后直接把Oracle JDK的免费更新停了,只要你是商业用途,就得掏钱买许可。 这一下直接把企业给逼急了。原来大家用Oracle JDK用的好好的,现在要收钱,那干脆换免费的OpenJDK啊。
OpenJDK主流发行版生态对比图
OpenJDK主流发行版生态对比图
于是就出现了现在的发行版混战:亚马逊出了Corretto,阿里出了Dragonwell,微软出了自己的OpenJDK,华为出了毕昇JDK,连IBM都有自己的发行版。 说实话,这对企业来说不是好事。原来只有一个Oracle JDK,现在这么多发行版,每个都有自己的定制优化,你在Dragonwell上跑的好好的代码,迁到Corretto上可能就出问题。这不就是当年“一次编写到处运行”的讽刺吗?现在变成了“一次编写到处调试”。

云原生冲击下的Java:不是被替代,是被迫瘦身

很多人说Java要被Go替代了,尤其是在云原生的微服务场景下。但这两年Java的变化,其实比很多人想的要快。 比如Java 19推出的虚拟线程(也就是原来的Project Loom),直接把原来的线程模型给改了。 原来的Java线程是和操作系统的平台线程一一对应的,你开一个线程,操作系统就得给你分配栈空间,开个几千个线程还行,开个几万个就扛不住了。虚拟线程不一样,是JVM层面实现的轻量级线程,你开个百万级的虚拟线程,内存也占不了多少。
Spring Boot 3虚拟线程运行原理示意图
Spring Boot 3虚拟线程运行原理示意图
阿里在2023年双11的核心交易链路中大规模落地了虚拟线程,整体线程上下文切换开销降低了60%以上,单实例的并发承载能力提升了近两倍。 还有Spring Boot 3,直接适配了GraalVM的原生镜像,把原来需要几秒钟启动的Java应用,压缩到了几百毫秒。虽然现在还有很多兼容性问题,但至少方向是对的。 不过落地的障碍也不少。我上周帮朋友排查一个线上问题,用了虚拟线程之后,某个老的ORM框架居然出现了线程泄漏。翻了源码才发现,人家把平台线程的ID当唯一标识用了,虚拟线程ID那叫一个乱,直接给人家整懵了。 很多老代码都是这么写的,你要让所有的第三方库都适配虚拟线程,至少还得两三年。

Java的隐忧:生态分裂与人才断层

现在Java最大的问题,不是技术不行,是生态和人才的隐忧。 首先是生态分裂。刚才说的这么多OpenJDK发行版,每个都有自己的定制功能,比如阿里的Dragonwell有Wisp协程,亚马逊的Corretto有自己的垃圾回收优化,这些功能都是不通用的。你要是用了Dragonwell的Wisp,那你就只能跑在Dragonwell上,迁到别的发行版就用不了。 长此以往,Java的跨平台优势就没了。 然后是人才断层。去年某头部互联网公司的校招,Java方向的投递量比三年前降了40%,相反Go方向的投递量翻了三倍。 为什么?因为年轻人觉得写Java没前途。 现在大家都在谈云原生,谈AI,谈大数据,Go写的K8s,写的Docker,写的微服务,听着就酷。Python写AI,写大模型,听着就高端。Java呢?写CRUD?写老系统?太啰嗦,太老,没前途。 我接触过很多刚毕业的开发者,上来就问我学什么语言找工作好,我要是说学Java,人家都一脸不屑。 这不是危言耸听。现在的Java开发者,大部分都是有五到十年经验的老炮,刚毕业的年轻人越来越少。再过个十年,这些老炮都退休了,谁来维护那些跑在核心系统里的Java代码? 还有个更现实的问题,就是Oracle的许可坑。我见过一个做SaaS的小公司,年营收才几千万,被Oracle告了,说他们用了Oracle JDK没付费,要补200多万的许可费。最后只能咬着牙迁到OpenJDK,折腾了半年,差点把公司折腾没了。 很多中小企业根本不知道自己用的JDK是Oracle的还是OpenJDK的,等收到律师函的时候,已经晚了。 接下来三到五年,Java不会死。 那些对稳定性要求极高的行业,比如金融、政务、运营商,不可能把跑了十几年的核心系统换成Go或者Rust,迁移成本太高了,出一次故障的损失,比用Java多花的成本高多了。 Java会慢慢变成“基础设施的语言”。就像现在的C++,虽然很多年轻人不学,但底层的操作系统、数据库、游戏引擎还是离不开它。Java以后就是跑在核心系统、大数据平台、AI基础设施层的语言,不是年轻人用来写玩具项目的语言。 增量市场里,Java会在两个场景慢慢落地:一个是Serverless场景,靠GraalVM的原生镜像解决启动慢的问题;另一个是大数据和AI场景,毕竟Hadoop、Spark、Flink这些大数据框架都是Java写的,现在很多大模型的推理框架也有Java的绑定,生态优势还在。 至于那些说Java要被替代的人,大概率是没接触过真正的核心系统。你让他把银行的核心交易系统从Java换成Go试试?出一次交易故障,他担得起责任吗? Java的中年危机,不是它自己的危机,是整个行业的危机——当所有人都追着新技术跑的时候,谁来守住那些跑了十几年的、扛着整个社会运转的老系统?

作者|大讲堂

排版|大讲堂

审核|小准

免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。如有侵权请联系删除。
文章名称:Java的中年危机:从基础设施到云原生时代的生态博弈
文章链接:https://www.lfdjt.com/info_23_25674.html