一个REST API，两种语言实现，10万并发请求压测。内存占用差4倍，响应时间差3倍，云账单差到让财务来敲门。
这不是语言圣战，是实打实的生产环境数据。开发者Query Gone Wrong把同一套业务逻辑用Python（FastAPI）和Java（Spring Boot 3）各写了一遍，部署在相同的AWS配置（t3.medium，2核4G）上，用k6（现代负载测试工具）从1到10000并发逐步加压。
结果让团队重新评估了技术栈选型。
第一轮：内存刺客现身
Java启动即吃掉512MB，Python只啃了120MB。
但别急着下结论。压力上来后，Python的内存曲线像失控的电梯——1000并发时冲到890MB，2000并发直接突破容器限制被OOM（内存溢出）杀死。Java反而稳在780MB左右，垃圾回收（GC，自动内存管理机制）虽然偶尔卡顿，但没崩。
「Python的异步很美好，直到你忘了限制连接池。」Query在复盘时写道。FastAPI的默认配置对新手友好，但生产环境就是坑。Spring Boot的线程池模型虽然"老派"，却给每个请求划定了明确的资源边界。
云成本由此分叉：Python需要m5.large（2核8G）才能跑稳同样负载，Java在t3.medium上还能余30%内存。按AWS按需实例算，每月差出47美元。十个服务就是470，一百个就是4700——这钱够招半个初级开发了。
第二轮：响应时间的欺骗性
单请求延迟：Python 12ms，Java 18ms。Python赢了？
但P99（99%分位延迟，即最慢的1%请求）揭穿了真相。1000并发时，Python的P99飙到340ms，Java压在89ms。差距来自GIL（全局解释器锁，Python的多线程瓶颈）和Java的虚拟线程（Project Loom）。
更隐蔽的是冷启动。AWS Lambda场景下，Python包体积比Java小60%，启动快2.3秒。但Query测试的是常驻容器，这个优势被抵消了。Serverless（无服务器架构）和常驻服务的选型逻辑，在这里完全相反。
「用户抱怨的不是平均速度，是最慢那次。」Query记录了真实反馈。一个支付回调接口，Python版在促销期间有0.3%的请求超过2秒，触发了下游的超时重试。Java版最慢请求1.1秒，刚好卡在阈值内。
这0.3%的异常，贡献了80%的客服工单。
第三轮：开发速度的幻觉
Python写了4小时，Java写了2天——但后面的事更复杂。
FastAPI的自动文档、类型提示、极简语法，让原型快得像写脚本。Spring Boot的注解配置、依赖注入（DI，控制反转的一种实现）、分层架构，前期像在搭脚手架。
转折点在第三周。需求变更：给API加缓存、限流、链路追踪。Python团队开始手写中间件，Java团队从Spring Cloud Alibaba里捞现成的。最终代码量：Python 2400行，Java 1800行——Java反而少了。
「Python让你快速犯错，Java让你缓慢但系统地犯错。」Query的吐槽很精准。类型安全在重构时救了Java团队两次，Python的单元测试覆盖率从78%补到94%才敢说安全发布。
招聘成本也是隐性账单。团队里3个Python开发者，2个是数据科学转岗，写业务代码时还在用Pandas（数据分析库）的思维。Java开发者虽然贵15%，但产出代码的故障率低40%——这是Query跟踪了6个月生产事故得出的数。
第四轮：那个让Java翻车的细节
测试最后，Java在10000并发时突然雪崩。
不是内存，不是CPU，是连接池。HikariCP（Java高性能连接池）的默认最大连接数10，在突发流量下把数据库拖垮。Python用的asyncpg（异步PostgreSQL驱动）没这问题，因为协程（Coroutine，轻量级线程）不占用连接。
这个配置项藏得深，Spring Boot的自动配置没覆盖它。Query花了3小时排查，最后在生产环境的application.yml里加了一行：maximum-pool-size: 50。
「Java的生态像瑞士军刀，但每把刀都有安全锁。」这个类比被团队记在了Wiki里。Python的生态像多功能螺丝刀，常用场景顺手，遇到特殊螺丝就抓瞎。
最终选型没有赢家通吃。Query的团队把Java用在核心交易链路，Python留在数据分析和内部工具。混合架构增加了运维复杂度，但云账单比纯Java方案低22%，比纯Python方案稳定一个数量级。
那个10000并发下Java崩溃的日志，现在被打印出来贴在工位上。旁边是Python OOM的截图。两张纸，两种教训，同一个问题：你的瓶颈从来不在语言，在你没读的那行默认配置。
你上次压测，是在上线前还是出事后？
热门跟贴