努力
奋斗

SpringBoot 2核2G能跑多少QPS？

2026-10-27 06:05:24 分类：阿里云ECS
服务器价格表

直接给结论：别问“能跑多少”，要问“在什么场景下、怎么配、测出来是多少”。

2核2G（2C2G）是典型的入门级或测试环境配置。Spring Boot 本身是个比较“重”的容器，JVM 默认堆内存设置在这台机器上如果调优不好，甚至可能启动都费劲，或者稍微有点并发就 OOM（OutOfMemoryError）。

为了给你一个有参考价值的数字，我们需要把问题拆解成三个维度：应用类型、数据库交互、代码质量。

1. 纯静态/简单接口（无 DB 操作，本地计算）

如果你的接口只是返回一个 JSON，里面没有查库，只是做点简单的字符串拼接或数学运算：

  • 优化前（默认 JVM 参数）：QPS 大概在 50 – 150 左右。GC 停顿会非常频繁，响应时间抖动大。
  • 优化后（调整 JVM，使用 G1GC，减少对象创建）：QPS 可以跑到 300 – 600。
  • 极限情况：如果你连 Spring MVC 都嫌重，直接上 Netty 写个 Hello World，那能到 2000+，但这就不叫 Spring Boot 了。

2. 常规 CRUD 业务（有 MySQL 查询）

这是最常见的场景。假设你有一个标准的 Controller -> Service -> Mapper -> MySQL 流程。

  • 瓶颈不在 CPU，而在 IO 和连接池。
  • 单线程串行执行：QPS 可能在 20 – 50。因为 Tomcat 默认线程数有限，且每个请求都要等待 DB 响应。
  • 合理调优后：
    • 连接池（HikariCP）配置合理。
    • SQL 走索引，不走全表扫描。
    • JVM 堆内存设为 1G-1.5G，预留 OS 缓存。
    • QPS 大概在 80 – 150。
  • 注意：如果 SQL 写得烂（比如 N+1 问题），QPS 可能直接跌到 10 以下。

3. 高并发读写混合或复杂业务

  • 如果涉及分布式锁、Redis 缓存穿透、复杂事务，2C2G 基本就是“玩具”级别。
  • QPS 很难稳定在 50 以上，且 P99 延迟（99% 的请求耗时）会非常高，偶尔出现超时。

为什么不能只看 QPS？看这三个关键点：

1. JVM 参数是生死线

2G 内存，JVM 默认可能分配 1/4 作为堆内存（约 512M），剩下给 Metaspace 和线程栈。对于 Spring Boot 来说，这太紧了。

  • 推荐参数：-Xms1g -Xmx1g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m
  • GC 选择：务必用 -XX:+UseG1GC。默认的 Parallel GC 在低内存下停顿时间长，影响吞吐量。
  • 线程数：Tomcat 的 maxThreads 不要设太大，2C2G 建议设置在 50-100 之间。设多了上下文切换开销比处理请求还大。

2. 数据库是最大瓶颈

2C2G 的服务器通常搭配的是同规格的 RDS 或自建 MySQL。

  • 如果 MySQL 也在同一台机器上？别想了，QPS 接近于 0。
  • 如果 MySQL 独立部署，但网络延迟高或慢查询多，Spring Boot 这边再快也没用，线程会被阻塞在 getConnection() 或 executeQuery() 上。
  • 关键指标：看 MySQL 的 Threads_running 和 Queries。如果这里爆了，你的 Spring Boot 根本扛不住。

3. “伪高并发”陷阱

很多测试工具（如 JMeter）压测时，如果没有模拟真实的用户行为（比如思考时间、随机延迟），只是死命发请求，那么：

  • 前期 QPS 直线上升。
  • 一旦超过系统处理能力，CPU 飙升到 100%，线程堆积，QPS 瞬间断崖式下跌，甚至服务雪崩。
  • 真正的有效 QPS 是指：在响应时间可接受（比如 < 200ms）的前提下，系统能持续处理的请求数。

给你的实操建议：

  1. 先别猜，先测。用 JMeter 或 wrk 打一下你的核心接口。从 10 QPS 开始加，每次加 10，直到响应时间超过阈值或错误率 > 1%。那个拐点就是你这台机器的真实能力。
  2. 监控是关键。部署 Prometheus + Grafana，重点看：
    • JVM Heap Usage（是否频繁 Full GC？）
    • CPU Load（是否长期 > 80%？）
    • Thread Count（是否线程耗尽？）
    • DB Connection Pool Active（连接池是否打满？）
  3. 如果是生产环境：2C2G 只适合跑一些非核心的后台任务、内部管理系统、或流量极小的 C 端应用。对于任何对外暴露的高流量 API，请至少升级到 4C4G 或更高，并考虑集群化。
  4. 代码层面优化：
    • 避免在 Request 中创建大量临时对象。
    • 使用异步处理（@Async）解耦非核心逻辑。
    • 开启 GZIP 压缩，减少网络传输时间。

总结：
在 2C2G 上，一个写得中规中矩的 Spring Boot 应用，稳定 QPS 在 100 左右是比较现实的预期。如果能做到 300+，说明你的代码极其轻量、SQL 极其高效、JVM 调优到位；如果低于 50，大概率是代码或配置有问题。

别迷信理论值，压测数据才是唯一真理。