微服务架构下GC需精准适配轻量实例与短生命周期对象，推荐G1回收器配50ms停顿目标，启用结构化日志并接入监控告警，同时通过代码优化降低对象分配速率。
微服务架构下，JVM 垃圾回收（GC）不再是“开箱即用”的后台任务，而是直接影响服务响应延迟、资源利用率和集群稳定性的重要环节。单体应用中可容忍的 GC 暂停，在高频、短时、强 SLA 约束的微服务场景里，可能直接引发超时熔断或雪崩。因此，GC 算法的选择与配置必须贴合微服务典型特征：轻量实例、快速启停、请求短平快、堆内存相对较小但波动频繁。
新生代算法要匹配微服务对象生命周期
微服务中绝大多数对象（如 DTO、Controller 局部变量、Feign 调用临时结构）存活时间极短，通常在一次 HTTP 请求内创建并丢弃。这正契合复制算法（Eden + Survivor）的设计前提——98% 对象朝生夕死。
- 保持默认的 8:1:1 Eden/S0/S1 比例 即可满足多数场景；盲目调大 Survivor 容易导致对象过早晋升老年代
- 避免设置过高的 -XX:MaxTenuringThreshold（如 >15），微服务对象极少需要经历多次 Minor GC 才死亡
- 若观察到大量对象在第一次 Minor GC 后就进入老年代（可通过
-Xlog:gc,age日志确认），需检查是否存在大对象直接分配（如 byte[] 缓存）、或 TLAB 过小导致逃逸
老年代回收器选型决定服务稳定性底线
微服务实例内存通常在 512MB–2GB 区间，Full GC 风险高、代价大。CMS 已被 JDK 14+ 废弃，G1 成为当前主流选择；ZGC/Shenandoah 更适合 4GB+ 大堆且对 P99 延迟有毫秒级要求的网关或核心服务。
- 中小堆（≤2GB）推荐 G1，启用参数：
-XX:+UseG1GC -XX:MaxGCPauseMillis=50（目标停顿，非硬性保证） - 禁用
-XX:+UseCompressedOops仅当堆 >32GB 且 CPU 支持指针压缩时才需考虑；微服务普遍无需关闭 - 警惕 并发模式失败（Concurrent Mode Failure）：G1 在并发标记未完成时老年代已满，会退化为 Full GC。可通过
-XX:InitiatingHeapOccupancyPercent=35提前启动标记（默认 45），避免临界触发
GC 日志是微服务可观测性的第一道防线
在容器化微服务中，GC 行为必须可采集、可聚合、可告警。依赖 System.gc() 或手动触发毫无意义，关键在于让 GC 自身“开口说话”。
- 统一启用结构化 GC 日志：
-Xlog:gc*,gc+heap=debug,gc+age=trace:file=/var/log/jvm/gc.log:time,tags,uptime,level（JDK 11+） - 将 GC 日志接入 Prometheus + Grafana：提取
pause_time_ms、gc_count、heap_used_after_mb等指标，对单实例 GC 频次 >5 次/分钟或平均暂停 >20ms 的 Pod 触发告警 - 结合 Arthas
vmtool --action getstatic --class-name java.lang.Runtime --field-name availableProcessors等命令，验证容器 CPU limit 是否被 JVM 正确识别（影响 GC 线程数）
代码层规避 GC 压力比调参更治本
再优的 GC 算法也无法拯救持续制造垃圾的代码。微服务高频调用下，对象分配速率（Allocation Rate）常比内存总量更关键。
- 禁用 JSON 库的动态反射解析（如 Jackson 默认的
ObjectMapper），改用编译期生成的JsonDeserializer或@JsonCreator构造器，减少临时 Map/List 创建 - HTTP 客户端复用连接池（OkHttp/Netty），避免每次请求新建 SSLContext、ByteBuffer 等重量对象
- 日志中慎用字符串拼接：
log.debug("user {} action {}", userId, action)优于log.debug("user " + userId + " action " + action)，前者由 SLF4J 延迟格式化，后者强制触发 StringBuilder 分配
