一、背景与问题概述

1.1 业务与技术背景

随着信创改造推进，应用系统整体向国产化环境迁移：操作系统换为国产 Linux 发行版，基础设施以容器方式交付，Java 服务运行在 JDK 17 之上，由容器编排平台统一调度。迁移完成后进行全链路压力测试，目标有两个：一是验证功能在国产环境下的正确性，二是确认性能与稳定性没有因环境变化而退化。

1.2 暴露的两类典型问题

• 问题一：Java 服务只要开始压测，一小时内容器必然重启，长时间稳定性验证无法进行；
• 问题二：部分接口响应耗时明显过长，且波动大。

两个问题指向同一个深层原因：环境变了——操作系统、内核参数、CPU 架构、JDK 大版本、容器资源模型全部变化，但原有的观测手段、JVM 配置和运维脚本没有同步迁移，导致出问题时“既看不到现场，也说不清原因”。

二、问题一：压测中容器反复重启

2.1 现象与初步定位

现象链路如下：

1. 压测启动后，容器平台监控显示 Java 进程消失，健康检查失败，平台随后重建实例——这就是“服务重启”的真实过程；
2. 重启前的资源曲线显示：CPU 使用率 100%，内存使用率 98% 以上，且持续了一段时间；
3. 最关键的疑点：进程是“无声消失”的，没有留下任何 Java 层错误日志或转储文件。

内存逼近上限时，通常存在两条走向：

• 路径 A：JVM 堆内发生 OOM。若未配置退出策略，JVM 可能陷入长时间 Full GC 循环，表现为 CPU 打满、进程假死，最终被健康检查判定不健康；
• 路径 B：容器内存超过限额，内核的 OOM Killer 直接向进程发送 SIGKILL（典型退出码 137）。这种情况下进程瞬间消失，不会有任何 Java 层日志，更不会生成堆转储。

两条路径在当时都无法证实，因为证据链完全缺失——这才是排查路上的第一堵墙。

2.2 日志与配置检查

按清单逐项核查：

1. 是否生成 heapdump（堆转储）文件 → 未发现；
2. 是否有 GC 日志 → 没有；
3. 容器编排配置 → 未配置任何 GC 日志相关参数；
4. 容器启动脚本 → 配置了 heapdump 路径，但该路径指向容器内部本地目录，并未挂载为持久卷。

结论：不是“没有问题”，而是“没有证据”。诊断产物要么从未开启，要么落在容器销毁后会一起消失的临时路径上。这个教训非常典型：可观测性配置必须在问题发生前就位，事后补是毫无意义的。

2.3 JVM 参数改造：补齐事后取证能力

调整启动脚本 run.sh，确保包含以下 JVM 参数（所有路径统一使用容器挂载路径，即容器编排中声明的挂载点目录）：

# 发生 OOM 时，JVM 立即终止退出，交由平台健康检查与重建机制自愈
-XX:+ExitOnOutOfMemoryError
# 发生 OOM 时自动生成 Java 堆转储
-XX:+HeapDumpOnOutOfMemoryError
# 堆转储文件保存位置（必须是容器挂载路径）
-XX:HeapDumpPath=/logs/${NAMESPACE}/${APP_NAME}/heapdump_start_$(date +"%Y-%m-%d_%H%M%S").hprof
# JVM 发生致命错误时，错误日志保存位置
-XX:ErrorFile=/logs/${NAMESPACE}/${APP_NAME}/${HOSTNAME}-hs_err_pid%p.log
# 开启 GC 日志（JDK 9+ 统一日志语法），滚动保留
-Xlog:gc*:file=/logs/${NAMESPACE}/${APP_NAME}/gc-%t.log:hostname,time,uptime,pid:filecount=5,filesize=10M

逐条说明设计意图：

• ExitOnOutOfMemoryError：快速失败。传统虚拟机上“OOM 后苟活”便于人工介入，但容器场景没有人在终端旁等待，假死实例只会持续消费流量并放大超时。让 JVM 立即退出，配合平台的健康检查与重建机制自愈，是最合理的选择。
• HeapDumpOnOutOfMemoryError + HeapDumpPath：保留现场。文件名中拼接启动时间戳，避免多轮压测的转储互相覆盖；务必提前在脚本中 mkdir -p 相关目录，并确认运行账号有写权限。
• ErrorFile：JVM 自身崩溃（如本地库段错误）时输出错误文件。首次更换架构与 JDK 大版本时，这类底层问题出现概率上升，必须留痕。
• -Xlog:gc*：JDK 9 之后的统一日志语法，输出全部 GC 细节；通过 filecount 与 filesize 滚动，防止日志写满磁盘引发次生故障。

这里有一个容易踩的坑：如果堆转储路径写在容器本地写层而非挂载卷，即使成功生成了文件，也会随容器重建一起被清空，等于白做。因此“路径必须是挂载路径”不是可选项，而是硬性要求。

2.4 启动脚本改造：保活与日志治理

在 start_java_server 函数中补充后台清理逻辑：

start_java_server() {
  echo "---- start java process ----"
  mkdir -p "${LOG_PATH}"
  touch /app/bin/test.log
  # Java 进程后台启动
  eval java $JAVA_OPTS -jar $appname &
  while true; do
    # 清理两天前的 GC 日志等文件
    find "${LOG_PATH}" -mtime +2 -type f -name "*.log*" -exec rm {} \;
    # 清理 7 天前的消息中间件故障转移目录，排除当前实例仍在使用的目录
    find "${LOG_PATH}" -mtime +7 -maxdepth 1 -type d -not -name "*${HOSTNAME}*" -exec rm -rf {} \;
    # 每 24 小时执行一轮
    sleep 86400
  done
}

设计要点：

1. Java 进程后台启动，主脚本进入清理循环。容器要求主进程保持存活，脚本一旦退出整个容器就会结束；用 while 循环同时承担“保活”与“定时清理”两个职责，是最简洁的写法。
2. 清理策略与保留周期匹配：GC 日志保留两天，配合滚动参数上限 5 个文件、单个 10M，磁盘占用可控；消息中间件的故障转移目录保留七天，并通过 -not -name “${HOSTNAME}“ 排除当前实例正在使用的目录，避免误删。
3. 删除原来 tail -f 跟踪日志的写法：容器场景下日志应由平台侧统一采集，不应在启动脚本里做前台跟踪，否则会阻塞主流程或造成重复输出。
4. eval 的作用：将 JAVA_OPTS 中以空格分隔的多个 JVM 参数正确拆分展开，避免整体被当成一个参数。
5. sleep 86400 表示清理循环每 24 小时执行一次，与文件保留天数处于同一量级。

2.5 复测验证与证据分析

参数补齐后重新压测，成功在挂载路径下捕获到堆转储与 GC 日志，问题定性终于有了依据。分析时的通用思路：

• 堆转储：借助通用的内存分析工具查看支配树，重点关注无界增长的缓存集合、大对象数组、未释放的资源句柄、类加载器泄漏等常见模式；
• GC 日志：观察 Full GC 频率、老年代晋升速度与单次停顿时长，区分“内存泄漏”与“堆容量不足”两类原因；
• 对应处理：泄漏则修复代码；容量不足则调整堆参数与容器内存配比。

关于容器内存配比再补充一点：JDK 17 默认开启容器感知能力，可通过 MaxRAMPercentage 按容器内存限额的百分比设置堆上限，比手工写死 -Xmx 更可靠。同时注意容器内存限额要覆盖“堆 + 元空间 + 线程栈 + 堆外直接内存”的总和并留出余量，否则即使堆内不 OOM，也可能触发内核层面的 OOM Kill——这正是 2.1 节中路径 B 的由来。

三、问题二：接口响应耗时过长的分层排查

重启问题收敛后，压测中仍暴露出接口耗时过长的问题。容器化 Java 服务的耗时问题建议按“由外到内”的分层框架排查，避免凭感觉调参。

3.1 第一层：容器资源限流

• 若 CPU 限额设置过低，高峰期进程会被内核周期性限流，表现为吞吐上不去、尾延迟周期性飙升；
• 优先观察容器平台提供的 CPU 限流类指标，而不是只看平均使用率；
• 实践建议：先做单实例容量摸底，确定单实例安全水位，再据此推导副本数与资源限额。

3.2 第二层：JVM 与 GC 停顿

• 从已开启的 GC 日志中提取单次停顿时长与发生频率，估算 GC 对接口耗时的贡献上限；
• JDK 17 默认使用 G1 收集器，关注大堆场景下停顿目标等参数是否合理；
• 区分两种情况：对象分配速率过高（代码问题，如循环内频繁创建大对象）与回收不动（内存泄漏或堆过小）。

3.3 第三层：JIT 预热与架构差异

• 压测初期 JIT 尚未完成热点编译，耗时偏高属正常现象，正式采集数据前应充分预热；
• 信创环境常采用非 x86 架构处理器，JIT 编译产物与性能特征与既有 x86 环境不同，旧环境的性能基线不能直接套用，必须重新建立基线后再评估“耗时过长”是否真的异常。

3.4 第四层：应用与依赖

• 线程池、连接池打满会造成排队，接口耗时等于排队时间加处理时间，应监控队列长度与等待时长；
• 数据库慢查询、下游远程调用、锁竞争是三大常见来源，可通过链路追踪或耗时埋点将单接口拆段定位；
• 压测报告关注 P95、P99 等长尾指标，平均值会掩盖周期性抖动。

3.5 验证闭环

每次只调整一个变量，回归压测并与基线对比，确认改善后再进行下一项，避免多项改动叠加导致归因失败。

四、经验总结与最佳实践

1. 可观测性三件套默认内置：GC 日志、OOM 堆转储、致命错误文件，应固化到基础镜像或统一启动脚本中，而不是等出事再补；
2. 诊断产物必须落挂载卷：所有日志、转储路径必须是容器挂载路径，并保证目录存在与写权限；
3. 快速失败配合平台自愈：容器内进程异常退出不是故障，假死才是；ExitOnOutOfMemoryError 让故障实例尽快重建；
4. 内存统一规划：容器限额 ≥ 堆 + 元空间 + 线程栈 + 堆外内存 + 余量，优先使用容器感知的百分比参数；
5. 日志双轨治理：容器内定时清理控制磁盘占用，平台侧统一采集留存分析；
6. 环境迁移即基线重建：操作系统、CPU 架构、JDK 大版本任何一项变化，都意味着历史性能数据作废，需重新摸底；
7. 压测方法规范化：先预热、阶梯加压、关注长尾指标、单变量回归验证。

信创上云不是简单的“搬过去能跑”，而是观测体系、资源配置与运维脚本的整体重构。把取证能力前置、把每一次失败都变成可分析的信号，才能让压测真正沉淀为对国产化环境的可信度。