Native Image 生产运维

• Native 支持的 JVM 参数子集
• -XX 参数支持范围
• 内存默认值差异

Native Image 支持传统 JVM 参数的一个子集：常用参数如 -Xmx、-Xms、-Xss 等可用，但部分 JVM 参数（如 -XX:* 的多数选项）在 Native 中不受支持或被忽略。Native 的 -XX 支持范围有限，主要覆盖 GC 相关（如 -XX:+UseG1GC、-XX:+UseSerialGC）与少量诊断参数。内存默认值方面，Native 默认堆大小、栈大小可能与 JVM 不同，且需根据构建配置与运行环境调整。因此生产环境中应显式设置关键内存参数，避免依赖默认值。

差异源于 Native 没有 JIT 与完整的 JVM 运行时，参数子集是"被编译进镜像"的有限配置。理解支持范围可避免误用无效参数导致启动失败。

• Serial GC 默认的特性
• G1 GC 的支持与适用
• 内存与吞吐的权衡

Native Image 默认使用 Serial GC，它简单、内存占用低、适合小堆与单线程回收，但遇到大堆/高并发时停顿可能较长。G1 GC 在受支持的版本中可选用（-XX:+UseG1GC），吞吐与并发回收更好，适合大堆与多线程场景，但内存占用与实现复杂度更高。取舍在于：负载低、内存小的场景用 Serial GC 更省资源；负载高、堆大的场景选 G1 能降低停顿。需结合堆大小、延迟与吞吐要求选择。

GC 选择是 Native 生产调优的重点。Serial 的"省内存"与 G1 的"低停顿"是典型取舍，需经验证决定。

• 监控工具与指标的差异
• JFR/JMX 的支持
• 监控策略

传统 JVM 提供丰富的监控能力（JMX、JFR、jstat、jstack、jmap 等），而 Native Image 的监控能力更有限：JMX 支持受限，部分 JFR 事件在受支持版本可采集，jstack/jmap 等 JVM 专属工具不可用或需用替代手段（如 GDB、core dump）。实践中需依赖可用的指标（GC 日志、内存、JFR 事件、应用级指标）与外部监控（Prometheus/OpenTelemetry）来观测。因此监控策略需提前规划，把应用级指标与可用的 native 指标结合。

Native 的"轻量"也带来监控的"薄"，许多 JVM 内建工具失效。监控设计应围绕可用指标与外部可观测性展开。

• 冷启动优势
• 资源与内存模型
• Serverless 平台适配

Native Image 的秒级启动非常适合 Serverless（AWS Lambda、Azure Functions、Google Cloud Functions 等），可显著降低冷启动延迟，提升请求响应速度。其镜像小、启动快，适合按需扩缩容。注意事项：Serverless 平台对内存/超时/冻结/恢复有约束，Native 的内存模型（堆外内存）需适配；平台基础镜像（glibc/musl）需匹配；且部分平台对 native 二进制的大小与启动时间有限制。实践中需针对目标平台做针对性构建与调优。

Serverless 是 Native 冷启动优势的最佳场景。核心是"平台约束 + 内存模型 + 镜像适配"三者匹配。

• 依赖与漏洞扫描
• 镜像更新与版本管理
• 供应链安全

Native Image 的安全更新与漏洞管理包括：一是对依赖进行漏洞扫描（如 Snyk、OWASP Dependency-Check、Trivy），识别 CVE；二是及时更新 GraalVM 版本与相关依赖，因为 Native 把运行时编译进镜像，漏洞修复需重新构建镜像；三是维护 SBOM（软件物料清单）与镜像签名，确保溯源与完整性；四是遵循最小权限与最小功能原则，减少攻击面。由于 Native 是静态编译，修复安全漏洞必须重建镜像并重新部署。

Native 的"静态"特性意味着漏洞修复依赖重建，安全更新节奏与构建流水线强相关。SBOM 与扫描是保障供应链安全的关键。

• hs_err_pid 错误文件
• thread dump 的获取
• 与 JVM 排查的差异

Native Image 在崩溃时可能生成 hs_err_pid 错误文件，包含崩溃信息、寄存器、栈与线程信息，可用于定位 native 崩溃。thread dump 在 Native 中获取方式受限（缺少 jstack），可通过 GDB attach、JFR 线程事件或信号处理（如 SIGQUIT）获取有限线程信息。排查时需结合 core dump、日志与 JFR 事件。与 JVM 相比，Native 的排查手段更少、更原始，需依赖 native 层面工具。

Native 故障排查的难点在于缺少 JVM 自省工具，需借助 hs_err_pid、core dump 与 GDB。理解这些手段能提高排查效率。

• 日志框架的支持
• 构建期还是运行期配置
• 日志对性能的影响

Native Image 支持常用日志框架（Log4j、Logback、java.util.logging 等），但日志配置需在构建期或运行期正确设置，且日志框架的反射/配置类需纳入可达性配置。由于 Native 缺少 JIT，日志相关的字符串拼接与格式化开销会直接体现在运行期，因此应避免高开销的日志模式（如无谓的字符串拼接、过度使用占位符），并结合日志级别控制输出。性能方面，日志写入在高吞吐下可能成为瓶颈，需合理设置异步日志与缓冲。

日志在 Native 中既是功能也是性能考量。配置正确性（反射/资源）与日志开销优化是生产实践要点。

• 冷启动与 RSS 优势
• JIT 缺失的峰值性能差异
• 权衡与优化

Native Image 的优势在于极快的冷启动（无需 JVM 预热与 JIT 编译）与较低的内存占用（RSS 通常比 JVM 小，因为无类加载器、JIT 编译器等）。劣势在于缺少 JIT 的自适应优化，长时间运行或计算密集场景的峰值性能可能低于 JVM。权衡时：对启动敏感、内存受限、负载快速波动的场景（Serverless、短时任务）Native 优势明显；对长期稳定、计算密集的负载，需用 PGO 等手段弥补 JIT 缺失，或评估是否继续使用 JVM。

权衡的本质是"启动/内存"与"峰值性能"的取舍。Native 适合"多次启动、轻量常驻"的场景，JVM 适合"长驻、重计算"场景。

• startupProbe 的配置
• 优雅停机（SIGTERM）
• 流量摘除与滚动发布策略

Native 应用在 K8s 滚动发布时：配置 startupProbe 检测应用就绪，确保新 Pod 在流量进入前完成初始化；配合 readinessProbe 做流量摘除，发布期间先用 readiness 摘除旧 Pod 流量，再优雅停机；处理 SIGTERM 信号，在停机前完成资源释放与请求排空。由于 Native 启动快，滚动发布的收敛时间短，但仍需保证优雅停机与流量摘除的时序，避免请求中断。镜像体积小、启动快也利于快速扩缩容与回滚。

滚动发布的核心是"新就绪、旧摘除、优雅停"。Native 的启动快让发布更快，但优雅停机与探针时序仍需严谨设计。

• Micrometer 指标在 Native 中的支持
• Prometheus 指标导出
• JFR 事件采集

Native Image 支持 Micrometer 指标库，可导出 Prometheus 格式指标，用于应用级监控（请求量、延迟、内存等）。JFR（Java Flight Recorder）在受支持版本中可采集 GC、分配、线程等事件，用于性能分析。实践中常将 Micrometer/Prometheus 用于业务与运行指标，JFR 用于深度性能剖析。由于 Native 的 JMX 支持受限，字节码/运行时指标需通过应用级与 JFR 事件弥补。监控目标是覆盖可用性、性能与资源。

Native 的监控依赖"应用级指标 + JFR + 外部系统"的组合，Micrometer/Prometheus 提供可观测性，JFR 提供深度剖析。

• heap dump 的生成与局限
• core dump 的作用
• 诊断工具限制

Native Image 的 heap dump（-XX:+HeapDumpOnOutOfMemoryError 等）在受支持版本可生成，但堆转储格式与 JVM 不完全一致，且部分分析工具（如 MAT、jvisualvm）对 Native 堆格式支持有限，需用 GraalVM 提供的工具分析。core dump 在崩溃时生成，保存进程内存镜像，可用于 GDB 分析 native 崩溃，但分析难度大、未必能还原完整 Java 对象状态。局限在于：Native 缺少 JVM 的类加载与 JIT 信息，堆数据分析不如 JVM 直观，故障定位依赖 native 层工具。

Native 的堆/core dump 诊断能力弱于 JVM，需结合日志、hs_err_pid 与 GDB 综合判断，对格式兼容性有预期。

• 启动时间测量工具
• -XX:StartupTime 参数
• JFR 事件采集

测量 Native 启动时间可结合 JFR 与 -XX:StartupTime 参数：-XX:StartupTime 用于记录启动完成时间点，JFR 可采集启动过程中的事件（如类初始化、GC、应用就绪），从而精确分析启动耗时分布。标准化方法是指定统一的测量口径（如应用就绪信号、启动完成回调），在受控环境下重复测量，保证可对比。实践中将启动时间测量纳入 CI，作为回归指标，监控启动性能变化。

启动时间是 Native 的核心价值指标，标准化测量能客观评估优化效果并防止回归。JFR 与 -XX:StartupTime 是常用测量手段。

• 堆栈信息获取
• GC 日志
• JFR 支持限制

Native Image 的堆栈信息不缺可获取，但获取方式受限（如缺少 jstack，需借助 GDB、信号或 JFR 线程事件）。GC 日志可通过 -Xlog:gc 等参数输出，但事件字段与 JVM 略有差异。JFR 支持在受支持版本中可用，但覆盖的事件范围与深度不如 JVM。总体限制是：Native 的调试/诊断信息丰富度低于 JVM，需结合日志、JFR 与 native 工具综合判断，且部分能力依赖版本与平台。

Native 的调试信息"够用但不丰富"，理解限制可设计合理的诊断策略，避免依赖 JVM 特有工具。

• 日志框架支持
• 指标导出
• 崩溃转储（core dump）

Native Image 支持主流日志框架（Log4j、Logback、java.util.logging），需配置反射/资源；指标导出支持 Micrometer/Prometheus；崩溃转储（core dump）在崩溃时可生成，用于 native 层分析。整体上，日志、指标与崩溃转储能力均可使用，但均需相应配置与平台支持，且丰富度受限于 Native 的轻量特性。生产实践中应将这些能力纳入可观测性设计。

日志、指标、崩溃转储是运维三件套，Native 均支持但需配置与工具配合。设计时应明确各能力的边界与依赖。

• 镜像体积对发布的影响
• 启动探针配置
• 版本回滚策略

Native 应用的滚动发布实践包括：镜像体积小、启动快，发布带宽与收敛时间短，便于快速滚动；配置 startupProbe/readinessProbe 确保新版本就绪、旧版本摘除流量；版本回滚时，因镜像不可变且无运行时类加载，回滚只需切回旧镜像并重启，简洁可靠。实践中可将发布与回滚自动化，配合探针与健康检查保障发布质量。镜像体积还影响拉取耗时，精简镜像利于发布速度。

Native 的"不可变镜像+快启动"让滚动发布与回滚更简单可靠。核心是探针时序与回滚机制的自动化。

• 启动探针配置
• SIGTERM 信号处理
• 资源释放与排空

Native 镜像的启动探针用于检测就绪，优雅停机则依赖应用处理 SIGTERM 信号：在收到 SIGTERM 后停止接收新请求、排空进行中的请求、释放资源（连接池、文件句柄、线程），再退出。可配置 terminationGracePeriodSeconds 控制停机时长。Native 应用同样需要实现优雅停机，避免发布/销毁时请求中断或资源泄漏。实践中需确保信号处理逻辑被正确纳入镜像。

优雅停机是 K8s 生产稳定性的关键。SIGTERM 处理与资源释放需在应用层实现，与镜像类型无关，但 Native 的快启动让停机窗口更可控。

• 最小权限原则
• 依赖与漏洞扫描
• 运行时沙箱

Native 应用的安全加固包括：遵循最小权限原则（以非 root 用户运行、最小化文件系统权限、最小化暴露接口）；对依赖进行漏洞扫描（Trivy、Snyk 等）并及时重建镜像修复 CVE；由于 Native 常运行在精简容器中，可配合只读文件系统、seccomp 等运行时沙箱机制降低攻击面。同时利用镜像签名、SBOM 保障供应链安全。安全加固应从构建、分发到运行全链路覆盖。

安全加固是"纵深防御"，Native 镜像的小体积与静态性本身降低了攻击面，再配合最小权限、扫描与沙箱可进一步强化。

• SBOM（软件物料清单）
• 镜像签名
• 漏洞扫描

Native 二进制的供应链安全通过以下手段保障：一是生成并维护 SBOM（软件物料清单），记录应用依赖的组件与版本；二是对镜像进行签名（如 cosign、Notation），确保镜像完整性、防篡改；三是对依赖做漏洞扫描，发现并修复 CVE；四是构建产物可溯源（可复现构建、记录构建环境）。由于 Native 把依赖静态编译进镜像，SBOM 与扫描须基于构建产物而非源码，确保供应链可审计。

Native 的静态编译使供应链安全更依赖"构建产物级"的 SBOM、签名与扫描。这是生产发布合规性的基础。