Graviton4 的 r8g 实例来了，Java 应用迁移实测 +35% QPS
上个月被安排降 EC2 账单。查了下 Cost Explorer，r6i 系列占大头。刚好亚马逊云科技 5 月放出 Graviton4 的内存优化实例 r8g，试了一把。
迁移过程
容器化 Java 21 应用，改一行 Dockerfile 基础镜像从 x86 换成 arm64，部署到 r8g.4xlarge。
压测结果：
| 指标 | r6i.4xlarge | r8g.4xlarge | 变化 |
|---|---|---|---|
| QPS | 12,400 | 16,800 | +35% |
| P99 延迟 | 45ms | 28ms | -38% |
| CPU 使用率 | 78% | 52% | -33% |
内存带宽 STREAM 测试 Copy 从 38,200 MB/s 跳到 66,800 MB/s，+75%。
灰度切换
# ASG 混合实例策略，先 50/50
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name prod-pool \
--mixed-instances-policy '{
"LaunchTemplate": {
"Overrides": [
{"InstanceType": "r8g.4xlarge"},
{"InstanceType": "r6i.4xlarge"}
]
}
}'
跑一周无异常后全切。
踩坑记录
- JNI 原生库没有 arm64 版本 → 在 Graviton 实例上
make ARCH=aarch64重编译 - ARM 实例只能用 arm64 AMI → 用错 x86 AMI 直接报
UnsupportedOperation - Spot 池子不稳定 → r8g 刚 GA，先用 On-Demand 扛两周
建议
- 容器化应用优先迁（改一行 Dockerfile 的事）
- 先 Cost Explorer 看 r6i/r6a 占比，超 15% 就动
- Java 注意首次 JIT 预热可能比 x86 慢几秒
来源：亚马逊云科技 2026/5 月 Graviton4 实例族 GA
