当大家在谈论一个系统的性能时，往往会提到 CPU 基准测试、延迟或启动时间等指标。
但这次，我们想抛出一个更直接也更残酷的问题：如果为每种编程语言分配相同的内存限制，它们会以怎样的方式“死亡”？
为此，我们设计了一项压力测试，具体限制如下：
- 每个容器仅限使用 1GB 内存
- 所有语言实现完全相同的业务逻辑
- 模拟真实的流量负载
- 不进行任何性能调优，也不使用任何技巧，纯粹比拼语言的“原始生存能力”
参与这次测试的语言包括：Go、Rust、Node.js、Python 和 Java（Spring Boot），用这五种语言分别模拟以下场景：
- 每分钟处理 10 万次请求
- 解析和处理 JSON 数据
- 执行小规模的数据库写入操作
- 随机触发 CPU 峰值
每个容器的资源配置如下：
- 1 个 CPU
- 1GB 内存
- 500MB 临时磁盘空间
- 禁用 swap
值得注意的是，我们使用的是 Docker 的硬性资源限制，而不是软性的 cgroup 配置。一旦某个语言超过资源限制，容器将会被直接 OOM 杀掉，没有任何例外。
测试结果
Go：稳定但有点小问题
在整个测试过程中，Go 的内存使用峰值大约维持在 780MB，随后随着垃圾回收（GC）的介入逐渐回落，没有内存飙升，没有崩溃，服务始终稳定运行。
不过也存在一个小问题：在高负载突发时，GC 的暂停时间逐渐拉长到 40–60 毫秒。这个范围对一般的 API 系统而言尚可接受，但如果是对延迟非常敏感的系统，这种延迟可能成为瓶颈。
尽管如此，Go 依然展现出了极强的稳定性：全程无崩溃，无重启。
Rust：稳得像没事人一样
Rust 的表现则稳得像什么事都没发生一样。
内存使用始终保持在 250MB 左右，延迟维持在 30 毫秒以内，CPU 负载也十分轻松。原因在于它没有垃圾回收机制，内存分配和释放完全可控，每一次 malloc 都有对应的 free。
在整个测试过程中，Rust 根本没有触碰到 1GB 的内存上限。
这感觉就像我们给它配了一辆超级跑车，但它却以每小时 40 英里的速度稳稳当当地开着，只为展示它的稳定性。
Node.js：死得很快，而且死了两次
Node.js 在测试刚开始不久，第 4 分钟内存就冲到了 950MB，第 6 分钟容器被 OOM 掉。我们尝试调整启动参数，加上了 --max-old-space-size=900，但结果依然一样：GC 完全跟不上节奏。
它不断尝试执行 GC，过程中出现卡顿，延迟飙升、随后恢复，如此反复，最终在第 9 分钟服务彻底崩溃。
Python：表面平静，最终崩溃
Python 表面上看起来风平浪静，但最终也未能幸免于难。
使用 Flask 搭配 Gunicorn 的 Python 服务坚持了 13 分钟。期间内存缓慢增长，最终接近 1GB。GC 没有起到作用，在内存达到约 980MB 时，延迟迅速飙升，服务随后完全卡死。
紧接着容器被 OOM 杀掉，过程异常安静，没有输出任何错误日志，就这样“悄无声息”地消失了。
这也说明了一个问题：Python 并不会显式崩溃，而是悄无声息地“蒸发”。
Java（Spring Boot）：努力过了……结局还算体面
我们为 Spring Boot 设置了 -Xmx1024m 的最大内存限制。
一开始前 7 分钟运行顺利，之后开始频繁触发垃圾回收，日志中充斥着 Full GC 的信息，CPU 使用也随之飙升。
最终，它坚持了 16 分钟，因 OutOfMemoryError 崩溃。
但值得一提的是，它“死得很优雅”——在崩溃前，还在日志中留下了一封体面的“告别信”。
最终排名（按“死亡”前存活时间）
存活时间排名如下：
- Rust：无限存活
- Go：无限存活
- Python：13 分钟
- Java：16 分钟（但早期就开始波动）
- Node.js：6 到 9 分钟之间
最终幸存者：Rust 和 Go，其余语言全部阵亡。
最后的思考
我们常常过于关注系统的执行速度，却忽略了系统在受限条件下的韧性，但是性能不只是看你跑得有多快，还要看在出问题时系统能撑多久。
当基础设施成本上升时，容器资源会被压缩，内存就变成了一种“硬通货”。在这种情况下，Rust 凭借极低的内存占用脱颖而出，Go 则表现出良好的内存管理能力，而其他语言只能寄希望于你为它们多分配一些内存。
因此在选择编程语言时，要根据具体限制和性能要求，而不是仅仅根据个人喜好：
- Rust：适合用于流式处理、遥测、事件分发等任务；
- Go：非常适合构建 API、控制面板以及任何面向用户的服务
- Node 和 Python：如果你手头有 4GB 内存可以挥霍，而且能容忍一些混乱，那它们也能胜任；
- Java：除非离不开它的生态体系，且非常了解如何进行调优，否则使用时需谨慎。