SpringBoot 2核2G能跑多少QPS？

这是一个非常经典但没有标准答案的问题。Spring Boot 在 2核2G配置下的 QPS（每秒查询率）取决于极其复杂的变量，从 几十 QPS到几千 QPS都有可能。

为了给你一个更有价值的参考，我将从影响因素、典型场景估算、优化建议三个方面进行详细分析：

一、 核心影响因素（为什么差异巨大？）

1. 业务逻辑复杂度

   • Hello World / 静态接口：几乎无计算，QPS 可高达 5000~10000+。
   • 简单数据库查询：如查一张表的主键，QPS 可能在 500~2000。
   • 复杂业务逻辑：涉及多次 DB 查询、Redis 调用、外部 HTTP 请求、JSON 序列化/反序列化、复杂计算等，QPS 可能降至 50~200。

2. JVM 参数与 GC 策略

   • 2G 内存对 JVM 来说比较紧张。如果堆内存设置过大（如 -Xmx1.5g），会导致频繁 Full GC，严重拖慢性能。
   • 使用 G1GC 或 ZGC（Java 11+）比默认的 Parallel GC 更稳定。

3. 并发模型

   • Spring Boot 默认使用 Tomcat，线程池大小默认为 200。
   • 如果大量线程阻塞（如等待 IO），会迅速耗尽线程资源，导致 QPS 下降甚至 OOM。

4. 依赖组件

   • 是否启用 Actuator？
   • 是否使用 AOP、事务管理？
   • 是否连接远程数据库/Redis？网络延迟会显著降低 QPS。

二、 典型场景 QPS 估算（参考值）

以下是在 Linux 服务器、合理 JVM 参数、非极端压测 条件下的经验估算：

⚠️ 注意：以上数据仅为单机极限压测的理想情况。生产环境中需保留 30%~50% 的资源余量，因此实际可用 QPS 应打 5~7 折。

三、 如何提升 2核2G 的 QPS？（优化建议）

1. JVM 调优（关键！）

# 推荐参数示例（根据实际调整）
-Xms512m -Xmx512m          # 堆内存不宜超过物理内存的 1/3，避免 Swap
-XX:MetaspaceSize=64m       # 元空间初始值
-XX:MaxMetaspaceSize=128m   # 元空间最大值
-XX:+UseG1GC                # 使用 G1 垃圾收集器，停顿时间更可控
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/tmp/heap.hprof

2. 应用层优化

• 减少序列化开销：使用 Protobuf 替代 JSON（如果内部通信）。
• 异步处理：非核心逻辑使用 @Async 或消息队列解耦。
• 连接池优化：
  • HikariCP：确保 maximum-pool-size 不超过 (CPU核心数 * 2) + 有效磁盘IO数，通常设为 10~20 即可。
  • Redis 连接池：合理设置最大连接数。
• 缓存热点数据：使用本地缓存（Caffeine）或 Redis 减少 DB 压力。

3. 部署架构优化

• Nginx 反向X_X + 负载均衡：如果单台 2G 不够，横向扩展多台 2G 实例。
• 动静分离：将静态资源托管到 OSS/Nginx，减轻 Spring Boot 负担。
• 容器化部署：使用 Docker/K8s，限制容器内存上限，防止单个应用拖垮整个节点。

4. 监控与诊断

• 使用 Micrometer + Prometheus + Grafana 监控 QPS、响应时间、GC 频率。
• 使用 Arthas 在线诊断线程阻塞和 CPU 热点方法。

四、 总结与建议

• 如果你的系统是 C 端高并发入口：2核2G 只能承载极少量用户，建议至少 4核8G 起步，或通过 K8s 弹性伸缩应对流量高峰。
• 如果你的系统是 B 端后台或低频 API：2核2G 完全足够，甚至可以跑多个微服务实例。
• 最佳实践：不要只看 QPS，更要关注 P99 响应时间 和 错误率。一个稳定的 100 QPS 优于波动剧烈的 1000 QPS。

✅ 行动建议：
在生产环境上线前，务必使用 JMeter 或 Wrk 进行真实压测，模拟你的实际业务逻辑和并发模型，才能得到准确数据。