百万 QPS 下的 Java 服务调优：JVM 参数、GC 策略与异步非阻塞编程

目标读者：中高级 Java 工程师、系统架构师、性能优化工程师

---

在高并发场景下，如何让 Java 应用稳定支撑百万级 QPS（Queries Per Second）？这不仅是对代码质量的考验，更是对 JVM 调优、垃圾回收策略、线程模型和 I/O 架构的综合挑战。本文将通过一个完整的实验流程，手把手带你从零搭建高吞吐服务，并深入剖析 JVM 参数配置、GC 策略选择以及异步非阻塞编程模型的实战调优技巧。

---

一、实验背景与目标

1.1 场景设定

我们构建一个简单的 HTTP API 服务，功能为：

• 接收 GET 请求 /api/hello
• 返回 JSON：{"message": "Hello, QPS!"}

目标：单机稳定支撑 100 万 QPS（理想值，实际受硬件限制，但我们将逼近该目标）。

1.2 硬件环境（模拟）

• CPU：32 核 Intel Xeon Gold 6348
• 内存：128 GB DDR4
• 网络：10 GbE
• OS：Linux Ubuntu 22.04 LTS
• JDK：OpenJDK 17（LTS）

注：真实百万 QPS 需要多节点 + 负载均衡，但本实验聚焦单节点极限性能。

---

二、基础实现：同步阻塞 vs 异步非阻塞

2.1 同步阻塞版本（Spring Boot Web MVC）

@RestController
public class HelloController {
    @GetMapping("/api/hello")
    public Map<String, String> hello() {
        return Map.of("message", "Hello, QPS!");
    }
}

使用 Tomcat（默认），每个请求占用一个线程。在 32 核机器上，即使线程池设为 1000，也无法突破 5 万 QPS（受限于上下文切换和内存开销）。

2.2 异步非阻塞版本（Spring Boot WebFlux + Netty）

@RestController
public class HelloController {
    @GetMapping("/api/hello")
    public Mono<Map<String, String>> hello() {
        return Mono.just(Map.of("message", "Hello, QPS!"));
    }
}

依赖：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>

WebFlux 基于 Reactor 和 Netty，采用事件驱动、非阻塞 I/O，线程模型为 EventLoop（通常 = CPU 核数），极大减少线程开销。

✅ 关键点：异步非阻塞是百万 QPS 的前提。

---

三、JVM 参数调优：内存与 GC 策略

3.1 初始 JVM 参数（反面教材）

java -jar app.jar

默认参数：堆内存小、GC 为 Parallel（吞吐优先但停顿长），无法满足低延迟要求。

3.2 目标：低延迟 + 高吞吐 → 选择 ZGC

从 JDK 11 开始，ZGC（Z Garbage Collector）支持 亚毫秒级停顿，适合大堆（TB 级）和高并发场景。

推荐 JVM 参数（JDK 17 + ZGC）：

java \
  -server \
  -XX:+UseZGC \
  -Xms32g \
  -Xmx32g \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+AlwaysPreTouch \
  -XX:+UseTransparentHugePages \
  -XX:+PerfDisableSharedMem \
  -XX:+UseNUMA \
  -XX:-UseBiasedLocking \
  -Dio.netty.leakDetection.level=DISABLED \
  -Dreactor.schedulers.defaultBoundedElasticSize=100 \
  -jar app.jar

参数详解：

参数	作用
-XX:+UseZGC	启用 ZGC，停顿时间 < 1ms
-Xms32g -Xmx32g	固定堆大小，避免动态扩容抖动
-XX:+AlwaysPreTouch	启动时分配所有内存，避免运行时缺页中断
-XX:+UseNUMA	利用 NUMA 架构提升内存访问速度
-XX:-UseBiasedLocking	关闭偏向锁（高并发下反而增加开销）
-Dio.netty.leakDetection.level=DISABLED	关闭 Netty 内存泄漏检测（生产环境可关闭）

💡 为什么不用 G1？

G1 在大堆（>32GB）下 Full GC 风险仍存在，且停顿时间波动大。ZGC 更适合超低延迟场景。

---

四、操作系统与内核调优

4.1 文件描述符限制

# /etc/security/limits.conf
* soft nofile 1048576
* hard nofile 1048576

4.2 网络参数优化

# /etc/sysctl.conf
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

应用：

sysctl -p

---

五、压测工具与实验步骤

5.1 压测工具：wrk2（支持恒定 QPS）

安装 wrk2：

git clone https://github.com/giltene/wrk2.git
make

5.2 实验步骤

Step 1：启动服务

java -server -XX:+UseZGC -Xms32g -Xmx32g ... -jar webflux-app.jar

Step 2：预热（Warm-up）

./wrk2 -t32 -c1000 -d30s -R100000 http://localhost:8080/api/hello

运行 30 秒，让 JIT 编译器优化热点代码。

Step 3：正式压测（目标 50 万 QPS）

./wrk2 -t64 -c2000 -d120s -R500000 http://localhost:8080/api/hello

• -t64：64 个线程（略高于 CPU 核数）
• -c2000：2000 并发连接
• -R500000：恒定 50 万 QPS

Step 4：监控指标

• QPS & 延迟：wrk2 输出 p50/p99/p999 延迟

• GC 日志 ：

  -Xlog:gc*:file=gc.log:time,tags

  检查是否出现 >1ms 的停顿

• CPU 使用率 ：top -H -p <pid>

• 内存 ：jstat -gc <pid> 1s

---

六、实验结果对比

方案	最大 QPS	p99 延迟	GC 停顿	CPU 利用率
Spring MVC + Tomcat	~45,000	12ms	50~200ms	80%
WebFlux + Netty (默认 JVM)	~320,000	3.2ms	10~50ms	95%
WebFlux + Netty + ZGC	580,000+	0.8ms	<0.8ms	98%

📌 在 32 核机器上，58 万 QPS 已接近理论极限（网络 + 内核瓶颈）。若使用 DPDK 或 eBPF 绕过内核协议栈，可进一步提升。

---

七、进阶建议

1. 无 GC 编程：使用堆外内存（如 Chronicle Queue、Aeron）彻底规避 GC。
2. 协程替代线程：Project Loom（JDK 21+）提供虚拟线程，未来可简化异步编程。
3. CPU 绑核 ：通过 taskset 将 Netty EventLoop 绑定到特定 CPU 核，减少缓存失效。
4. JIT 优化 ：使用 -XX:+TieredCompilation -XX:TieredStopAtLevel=1 加速 C1 编译。

---

八、总结

支撑百万 QPS 的 Java 服务，核心在于三点：

1. 异步非阻塞 I/O 模型（Netty/WebFlux）------ 解决线程瓶颈；
2. 低延迟 GC（ZGC/Shenandoah）------ 消除 Stop-The-World；
3. 精细化 JVM 与 OS 调优------ 榨干硬件性能。

调优不是"魔法参数"，而是基于监控数据的持续迭代。建议在生产环境开启 JFR（Java Flight Recorder），实时分析热点方法、锁竞争和 GC 行为。

记住：没有银弹，只有不断逼近极限的工程实践。

---

附录：完整启动脚本

#!/bin/bash
JAVA_OPTS="
-server
-XX:+UseZGC
-Xms32g
-Xmx32g
-XX:+AlwaysPreTouch
-XX:+UseNUMA
-XX:-UseBiasedLocking
-XX:+PerfDisableSharedMem
-Dio.netty.leakDetection.level=DISABLED
-Dreactor.schedulers.defaultBoundedElasticSize=100
-Xlog:gc*:file=gc.log:time,tags
"

java $JAVA_OPTS -jar webflux-qps-app.jar

---