今天服务巡检发现，研发在使用K8S部署Java微服务时，一些参数调优配置的不是很合理，容易引起生产应用被K8S驱逐。 整理了一个比较通用的参数配置，供后续查询使用。

1. 文档目的（Purpose）

为统一公司在 Kubernetes 环境下 Java 微服务的 JVM 配置策略，降低线上 OOM、GC 抖动、Pod OOMKilled 等高频问题，提升系统 稳定性、可维护性与事故可复盘性，特制定本规范。

本规范适用于公司 所有新建及存量 Java 微服务，作为 默认 JVM 配置基线（Baseline）。

2. 适用范围（Scope）

2.1 适用环境

• 容器平台：Kubernetes（含腾讯云 TKE / ACK 等）

• Java 版本：

  • Java 11 / Java 17（推荐）
  • Java 8 ≥ 8u191（可用）

• 服务类型：

  • Spring Boot
  • Web API / RPC / 网关 / 消息消费类服务

2.2 不适用场景（需单独评审）

• 极端低延迟系统（P99 < 50ms）
• 内存型计算服务（大对象 / Cache-heavy）
• 非 G1 GC（ZGC / Shenandoah）

3. JVM 配置设计原则（Design Principles）

原则 1：容器优先（Container First）

• JVM 行为必须以 cgroup limit 为边界
• 禁止以物理机思维配置 -Xms/-Xmx

原则 2：弹性优于一次性占满

• 允许 JVM 在运行期 逐步扩堆
• 禁止默认使用 Xms = Xmx

原则 3：参数可解释、可复盘

• 禁止“堆参数堆砌”

• 每一项参数必须能回答：

  “为什么要写这一行？”

4. JVM 标准配置模板（Baseline Template）

公司默认 JVM 配置，90% 服务直接使用，不允许随意修改

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

JAVA_OPTS="
# ===== 容器感知 =====
-XX:+UseContainerSupport

# ===== Heap（核心内存策略）=====
-XX:InitialRAMPercentage=30
-XX:MaxRAMPercentage=70

# ===== GC 策略 =====
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200

# ===== OOM 诊断 =====
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/app/dump/heapdump.hprof

# ===== GC 日志（JDK 8 写法）=====
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintTenuringDistribution
-Xloggc:/data/app/logs/gc.log

# ===== JVM 稳定性 =====
-XX:+AlwaysPreTouch
-Djava.security.egd=file:/dev/./urandom
"

5. 关键参数规范说明（Mandatory Rules）

5.1 Heap 内存配置规范（强制）

❌ 禁止配置：

1
2

-Xms = -Xmx
InitialRAMPercentage ≥ 80

5.2 GC 线程配置规范（强制）

❌ 禁止在标准服务中显式配置：

1
2

-XX:ParallelGCThreads
-XX:ConcGCThreads

原因：

• Kubernetes CPU limit ≠ 物理核数
• JVM 已基于 cgroup 自动计算
• 手动指定易导致业务线程饥饿

5.3 GC 调优参数规范（限制性）

除以下参数外，禁止随意增加 GC 相关参数：

1
2

-XX:+UseG1GC
-XX:MaxGCPauseMillis

如需新增参数，必须提供：

• GC 日志分析结论
• 明确的业务指标改善说明

6. Kubernetes 资源配置协同规范

6.1 Memory 配置（强制）

1
2
3
4
5

resources:
  requests:
    memory: XGi
  limits:
    memory: XGi

📌 request 必须等于 limit

6.2 CPU 配置（推荐）

1
2
3

resources:
  limits:
    cpu: ≥ 2

理由：

• G1 并发标记需要 CPU
• CPU < 1 core 极易出现 GC 抖动

7. 场景化变体（需技术负责人审批）

7.1 启动即高流量服务（网关 / MQ Consumer）

1
2

InitialRAMPercentage=45~50
MaxRAMPercentage=75

7.2 延迟敏感服务（需压测证明）

1
2
3

InitialRAMPercentage=40
MaxRAMPercentage=65
MaxGCPauseMillis=100

⚠️ 必须满足：

• CPU ≥ 2 core
• 内存 ≥ 4Gi
• 启用 GC 日志监控

8. 常见事故与反模式（Anti-Patterns）

❌ 反模式 1：Pod OOMKilled 无 HeapDump

原因：

• Heap 占比过高
• 非堆内存无空间

❌ 反模式 2：GC 参数“看起来很专业”

特征：

• 参数数量 > 15
• 多数为默认值覆盖
• 无 GC 日志支撑

9. 上线前 JVM 健康检查清单（Checklist）

上线前必须确认：

• JVM 启动后 Heap 非一次性到顶
• GC 日志目录可写
• HeapDump 路径为独立持久卷
• Pod 未出现 exit code 137
• GC Pause P95 < 500ms

10. 规范维护说明

• 本规范由 架构组 / 平台组 维护
• 所有偏离配置需备案
• 每半年结合 GC 数据复盘一次

版本：v1.0