性能与可观测性

• 各 GC 的定位与特性
• 延迟与吞吐的权衡
• 生产选型依据

G1 是默认 GC，面向中等规模堆，兼顾吞吐与可预测停顿，适合大多数应用。ZGC 目标是极低停顿（亚毫秒级），支持超大堆（TB 级），通过染色指针与并发整理实现，适合对延迟敏感、堆大的服务。Shenandoah 也是低延迟 GC，通过并发整理与转发指针降低停顿，适合大堆、低延迟场景，与 ZGC 竞争。Epsilon 是 no-op GC，不进行任何回收，只适合内存一次性分配、生命周期极短的测试/短命程序，或配合外部回落。生产选型关键：默认场景用 G1；低延迟 + 大堆用 ZGC 或 Shenandoah；Epsilon 仅限特定测试。需结合堆大小、停顿目标、吞吐要求与 GC 调优成本做压测验证。

GC 选型是"延迟 vs 吞吐 vs 堆规模"的权衡：G1 均衡、ZGC/Shenandoah 低延迟、Epsilon 无回收。选型后必须压测验证，避免"理论最优"在实际中不达标。

• Async-Profiler 的低开销采样能力
• Continuous Profiling 平台的作用
• 与 JDK 25/26 的集成方式

Async-Profiler 基于 AsyncGetCallTrace 与事件采样，能以极低开销持续采样 CPU、分配、锁等，生成火焰图，是生产剖析的主力工具。在 JDK 25/26 上，Async-Profiler 4.x 支持通过 JFR 事件流与 JVM 的增强采样接口，并利用虚拟线程的采样支持。Continuous Profiling 平台（Pyroscope、Conprof）将长期采样的 profiling 数据持续采集、聚合、存储并可视化，形成"持续剖析"；Java 应用通过 agent 或 JFR 事件流把数据定期上报到平台，可按时间、服务、标签聚合分析。集成要点：部署 async-profiler agent（或 JFR 流模式）、配置上报端点、控制采样开销、与告警/容量联动。JDK 25/26 的改进使采样更精确、对虚拟线程更友好。

持续剖析的价值是"把低频的临时剖析变成持续的生产观测"：Async-Profiler 负责低开销采样，平台负责聚合与可视化。集成关键是控制开销与数据量。

• 指标降采样与基数控制
• 日志采样策略
• 追踪采样与存储策略

可观测性数据量大，成本治理是关键。指标降采样：控制指标采集频率（如 60s→300s）、限制高基数标签（cardinality）与聚合维度，避免指标爆炸。日志采样：按级别/采样率（如保留 1% 的 DEBUG 日志）、按错误必留、按请求采样，控制日志量与存储。追踪采样：采用头部采样（head sampling，按请求比例）与尾部采样（tail sampling，按结果/延迟条件保留关键 trace），只保留有代表性的 trace，避免全量存储。存储策略：分层存储（热数据短周期、冷数据归档）、设置保留期与 TTL、压缩与聚合。目标是"保留足够信息，控制成本"。

可观测性成本治理的本质是"用采样与聚合换取信息密度"：降采样控量、按需采样保关键、分层存储降成本。治理需在"诊断能力"与"成本"间平衡。

• TCP 参数调优（缓冲区、Nagle、KeepAlive）
• 零拷贝（sendfile、DirectBuffer）
• 连接复用与连接池

Java 网络性能优化涉及多层面。TCP 参数：调整发送/接收缓冲区（SO_SNDBUF/SO_RCVBUF）、关闭 Nagle 算法（TCP_NODELAY）以减少小包延迟、设置 SO_KEEPALIVE 与合适的超时，减少空闲与重连成本。零拷贝：通过 FileChannel.transferTo（sendfile）让数据在内核直接传输，避免用户态拷贝；用 DirectBuffer 减少堆内/堆外拷贝，配合 FFM 的堆外内存减少 GC 与拷贝开销。连接复用：使用连接池复用 TCP/TLS 连接，避免每次请求建连（TLS 握手成本高），HTTP/2 多路复用进一步减少连接数。对延迟的影响：减少建立连接与拷贝次数能显著降低 P99 延迟；但需在吞吐与延迟间权衡（如 Nagle 关闭适合小消息交互）。

网络延迟优化聚焦"减少拷贝、减少建连、减少等待"：零拷贝省 CPU 与拷贝、连接复用省握手、TCP 参数省等待。三者结合显著降低网络延迟。

• JFR 事件流的实时能力
• async-profiler 与 JFR 的配合
• 云原生下的集成与采集

JFR（JDK Flight Recorder）是内建的低开销诊断框架，JEP 349 引入 JFR 事件流（JFR Streaming），使应用可实时订阅 JFR 事件（不落盘），便于与其他监控系统集成。async-profiler 提供更细粒度的 CPU/分配/锁采样，可与 JFR 结合（其数据可导出为 JFR 格式）。云原生下集成：通过 JFR 事件流把 JVM 指标（GC、分配、线程、CPU）与 profiling 数据实时推送到 OTel/Prometheus/持续剖析平台；结合容器环境自动发现、sidecar 采集、Kubernetes 生命周期管理。趋势是让 JFR 与 async-profiler 数据"可流式、可远程、可聚合"，替代传统"事后落盘再分析"的离线模式。

工具链新变化的核心是"从离线到实时"：JFR 事件流让数据可实时订阅，async-profiler 补充采样细节，云原生集成让数据可汇聚分析。理解这一趋势是构建现代 JVM 可观测的关键。

• cgroup 内存限制与 JVM 堆
• CPU 限流（throttling）与 JVM 线程
• JVM 自适应参数（UseContainerSupport）的相互作用

容器环境下 JVM 需感知 cgroup 限制。-XX:+UseContainerSupport（默认开启）让 JVM 读取 cgroup 的 CPU/内存限制来自适应设置堆区、GC 线程数、默认的并行度等。当 cgroup 限制内存时，JVM 堆应小于容器内存（预留堆外与系统开销），否则 OOMKilled；当 CPU 被限流（CPU quota）时，JVM 需感知 CPU 配额，避免配置过多 GC/并行线程导致 CPU 争用与 throttling。可观测需监控：容器内存使用率、GC 频率、CPU throttling 时间（cpu.stat）、JVM 堆与容器限制的匹配。相互作用的关键是"JVM 自适应参数 + 容器限制 + 应用负载"共同决定性能，需用容器内 JVM 指标（JFR、与 cgroup 联动）综合分析。

容器与 JVM 的相互作用核心是"JVM 感知容器限制"：UseContainerSupport 让堆与线程自适应 cgroup，但需监控堆外内存、CPU throttling 与堆大小匹配，避免 OOM 与限流。

• JFR 事件流的能力
• JVM 指标到 Prometheus/OTel 的映射
• 采集与集成架构

JFR 事件流（JEP 349）允许应用实时订阅 JFR 事件，无需落盘。把 JVM 指标接入 Prometheus/OTel 的常见方式：1) 使用 JFR 事件流 + 自定义采集器（如 async-profiler 的 JFR 导出、或 jfr-exporter），将 JFR 事件（GC、分配、线程、CPU、锁）转换为指标；2) 使用 Micrometer 的 JVM 指标（jvm.gc.*、jvm.memory.*、jvm.threads.*）通过 Prometheus Registry 暴露 /metrics；3) 通过 OTel Java agent 的 JVM 指标 instrumentation 直接输出 OTLP。云原生集成架构：sidecar 或应用内采集器抓取 JFR 事件流/指标，Prometheus 或 OTel Collector 拉取/推送，最终接入监控平台。关键在于"事件→指标"的降采样与聚合，避免数据量过大。

JVM 指标接入的关键是"采集 + 转换 + 汇聚"：JFR 事件流提供细粒度事件，Micrometer/OTel 转换为标准指标，Prometheus/Collector 汇聚。理解数据管道是落地核心。

• JFR 事件流的深度指标
• OTel JVM 指标的标准性
• eBPF 的系统级观测

JVM 可观测性趋势是多种手段互补。JFR 事件流提供 JVM 内部深度指标（GC、JIT、分配、锁、线程状态），是"JVM 视角"最细粒度的数据。OTel JVM 指标提供标准化的 JVM 运行时指标（通过语义约定），便于与统一监控体系对接。eBPF 则从"系统/内核视角"观测：CPU、内存、网络、系统调用、甚至 JVM 的用户态行为（如通过 JVM 的 eBPF 探针），无需侵入应用。互补关系：JFR 看 JVM 内部，OTel 提供统一标准，eBPF 看系统与内核，三者结合能覆盖"应用→JVM→内核"的完整链路。趋势是 eBPF 补充 JVM 观测无法覆盖的系统层细节，而 JFR 与 OTel 提供 JVM 与应用语义。

JVM 可观测的互补是"视角互补"：JFR 深度、OTel 标准、eBPF 系统。理解各层覆盖范围，才能构建完整、高效的可观测体系。

• AI 长连接流式响应的内存特征
• 虚拟线程在 AI 场景的适用性
• 与 GC 的交互

AI 工作负载（如 LLM 网关、流式接口）有特定性能特征。长连接流式响应：每个请求持有长连接，逐 token 输出，会造成大量短生命周期对象与持有连接的内存占用，需关注 GC 对"生成大量中间对象"的回收；同时长连接占用 FD 与连接资源，需管理连接数。虚拟线程在 AI 场景适用：流式响应常为阻塞式 IO（等待 token），虚拟线程可承载大量并发长连接，无需大量平台线程，缓解线程数与内存压力。GC 交互：流式生成的中间对象（buffer、token 拼接）产生大量分配，若使用大对象缓冲区或字节流，需关注 GC 压力与停顿；虚拟线程本身不增加 GC 对象（载体线程复用），但多线程并发增加分配压力。优化方向：使用 DirectBuffer 减少拷贝、控制缓冲大小、选择合适 GC（如 ZGC 处理大堆低延迟）。

AI 工作负载的关键是"高并发长连接 + 大量中间对象"：虚拟线程承载并发，GC 需处理流式生成的分配压力。理解这些特征才能正确选型 GC 与线程模型。

• HPA 弹性伸缩与 JVM 启动
• CDS/AOT 启动优化
• 就绪探针与启动时序

云原生弹性伸缩（HPA）要求 JVM 应用能快速启动、快速就绪，否则扩容时流量进入会超时。JVM 启动优化手段：CDS/AppCDS（Class Data Sharing）共享类元数据，减少类加载；AOT（Spring AOT、Native Image）把 Bean 与字节码预编译，显著缩短启动；分层 jar 减少加载量。就绪探针（readiness probe）用于检测应用是否可接收流量，配合 JVM 启动优化让"就绪时刻"更早。工程上：设置合理的启动/就绪探针阈值（含 JVM 预热时间）、用 CDS 与 AOT 加速启动、对启动慢的模块做预热（连接池、JIT 热点）。HPA 与启动优化结合：启动快则扩容更及时、更省资源。

弹性伸缩的前提是"又快又稳地启动"：CDS/AOT 缩短启动，就绪探针协调接入时序，HPA 依赖这些能力实现快速扩缩容。理解启动链路是云原生 Java 的关键。

• JFR 事件流的实时订阅机制
• 与 SRE 监控体系的集成
• 事件选择与开销控制

JFR 事件流（JEP 349）允许应用在运行时实时订阅 JFR 事件，无需 JFR 落盘，通过 RecordingStream API 注册事件监听器，实时处理 GC、分配、线程、异常等事件。SRE 集成实践：应用内启动 RecordingStream，订阅关键事件（如 GC 停顿、OOM、长锁），在事件触发时上报指标或告警；或因将 JFR 事件流汇聚到 Prometheus/OTel/持续剖析平台。工程要点：谨慎选择事件与阈值（避免订阅高频率事件导致低开销优势丧失）、控制缓冲区与消费频率、处理事件流异常与重连、将事件与业务 traceId 关联。价值是让 JVM 诊断数据"实时可观测"，辅助 SRE 快速定位。

JFR 事件流让"诊断数据实时化"成为可能，但其低开销优势依赖"选择性订阅"。SRE 集成时需控制事件量、合理映射为指标与告警。

• AsyncGetCallTrace 的原理
• 低开销采样与火焰图
• 生产剖析的实践

AsyncGetCallTrace 是 JVM 提供的采样接口，用于获取线程调用栈，async-profiler（以及 JFR 的 CPU 采样）利用它进行低开销的周期采样，无需暂停线程或注入代码，开销通常低于 1%。采样时按固定频率（如 100Hz）获取线程栈，统计各栈帧的采样占比，从而定位 CPU 热点，生成火焰图（flame graph）直观展示调用路径与耗时分布。生产剖析实践：在低峰期或持续小比例采样，用 async-profiler 抓取 CPU 火焰图，分析热点方法与锁竞争；结合 JFR 事件关联 GC 与分配。关键在于采样开销可控、采样周期合理、以及将火焰图与业务链路关联。

AsyncGetCallTrace 的价值是"低开销、无侵入"的采样，火焰图让 CPU 热点可视化。生产剖析需控制采样频率与时长，避免影响在线服务。

• 流式响应与高并发长连接的特征
• 对 GC 的新要求
• 对线程模型的新要求

AI/LLM 场景（如 LLM 网关、流式对话接口）有独特性能特征：流式响应每请求持有长连接、逐 token 输出；高并发长连接意味着大量并发连接与阻塞等待。这对 GC 提出新要求：流式生成产生大量中间对象（buffer、token 拼接），需 GC 高效回收，减少停顿；大堆 + 低延迟场景（如 ZGC）更合适。对线程模型：传统"每连接一平台线程"在成千上万长连接下成本高，虚拟线程能承载大量并发长连接，阻塞等待时自动让渡载体线程，从而以极低线程成本支撑高并发流式。还需注意：长连接占用 FD 与内存、需连接与空闲超时管理；流式缓冲需控制大小避免内存压力。整体上，AI 场景需要"虚拟线程承载并发 + 低延迟 GC 处理分配"的组合。

AI 场景的挑战是"高并发长连接 + 大量中间对象"：虚拟线程解决线程成本，低延迟 GC 解决分配压力。理解这两点才能正确设计线程模型与 GC。

• 虚拟线程的剖析挑战
• async-profiler 对虚拟线程的采样支持
• 剖析实践

虚拟线程数量巨大且可挂起/恢复，剖析虚拟线程面临挑战：传统按平台线程采样难以覆盖挂起中的虚拟线程，且虚拟线程栈可能与载体线程分离。async-profiler 4.x 增强了对虚拟线程的采样支持：能够感知虚拟线程，采集其调用栈（即使在挂起状态）、记录虚拟线程的创建/调度事件，并支持按虚拟线程维度分析火焰图与 CPU 时间。剖析实践：用 async-profiler 的虚拟线程感知模式，配合 JFR 的虚拟线程事件，分析虚拟线程的阻塞、调度延迟与负载不均衡。理解采样支持有助于定位虚拟线程场景下的性能瓶颈（如钉住、调度开销）。

虚拟线程剖析的难点是"线程数量巨大 + 挂起态"，async-profiler 的虚拟线程感知弥补了传统按平台线程采样的盲区。掌握这一能力是虚拟线程性能优化的前提。

• 持续剖析的部署方式
• 采样开销控制
• 与告警的联动

持续剖析（Continuous Profiling）在 Java 服务中落地：通过 async-profiler agent 或 JFR 事件流持续采样，周期上报到 Pyroscope/Conprof 等平台，长期保存并聚合。采样开销控制：采用低采样率（如 CPU 1-4Hz）、按需开启/关闭、限制采样时长与维度，把开销控制在 1-2% 以内；对高热点阶段可提高采样。告警联动：将 profiling 数据与指标关联，当 CPU 利用率、GC 停顿、延迟异常时，可结合 profiling 数据定位热点并触发告警/分析；也可针对"CPU 热点突变""锁竞争上升"设置规则。落地要点：采样降噪、数据存储策略、与现有监控体系（Prometheus/OTel）打通、以及 profiling 结论回写为性能优化项。

持续剖析落地要平衡"信息充分"与"开销可控"：低采样率控制开销，多渠道采样保证覆盖，告警联动让剖析数据服务于运维决策。它是性能优化的长效机制。

• 压测基线的建立
• 业务增长模型
• 资源规划与余量

Java 应用容量预测的核心是"压测基线 + 业务增长模型"。压测基线：通过压测确定单实例在不同负载下的吞吐、延迟、资源（CPU/内存）与 GC 表现，建立"请求量→资源需求"的映射，并找出瓶颈（CPU、线程、内存、GC）。业务增长模型：用历史数据与业务趋势预测未来请求量（如日活、峰值、季节性），作为容量需求的输入。资源规划：结合基线与增长模型计算所需实例数/资源，并预留余量（如 50-100% 缓冲）应对峰值与故障；同时考虑弹性伸缩作为兜底，而非依赖静态规划。需持续校准：容量预测不是一次性，需按实际压测与线上数据迭代。工程上还需考虑 GC 内存、连接数、依赖下游容量等边界。

容量预测的本质是"用数据建立需求映射"：压测给出单实例能力，增长模型给出未来需求，两者结合得到资源规划。余量与弹性兜底是稳健性的关键。

• UseContainerSupport 的作用
• JVM 堆与 cgroup 内存限额
• CPU 限额与线程/GC 自适应

-XX:+UseContainerSupport（默认开启）让 JVM 读取容器 cgroup 的 CPU 与内存限额，自适应设置堆大小、GC 线程数、默认并行度等。内存匹配：JVM 依据 cgroup 内存限额计算默认堆（如内存的 1/4），需预留堆外内存（元空间、线程栈、DirectBuffer、JIT 代码）与系统开销，否则易 OOMKilled；可显式用 -XX:MaxRAMPercentage 微调。CPU 匹配：JVM 依据 cgroup CPU 配额确定 GC/并行线程数，避免 CPU 配额小于线程数导致过度限流（throttling）。工程上需验证 JVM 实际读取的限额与容器配置一致，监控堆外内存与 CPU throttling，并在限额变更时动态调整。匹配的关键是"JVM 感知限额 + 预留开销 + 线程与配额一致"。

UseContainerSupport 让 JVM 自适应容器限额，但"感知"不等于"最优"：需显式预留堆外、微调堆比例、控制线程数与 CPU 配额匹配。理解这点是容器 Java 调优的核心。

• 虚拟线程生态对并发性能的影响
• FFM 对原生交互与内存的影响
• Valhalla 对内存与计算的影响

JVM 技术路线对未来性能优化有深远影响。虚拟线程生态：让高并发 IO 场景以极低线程成本实现，影响线程模型与并发调优方向（从"线程池大小调优"转向"虚拟线程 + 结构化并发"）。FFM（Foreign Function & Memory API）：提供安全、高性能的原生函数调用与堆外内存管理，替代 Unsafe/JNI，影响涉及原生库、高性能计算、网络栈的优化，减少拷贝与 GC 压力。Valhalla（值类型与泛型特化）：通过扁平化布局消除对象头与指针间接寻址，显著降低内存与缓存开销，影响数据处理、集合、数值计算的性能路径。整体上，这些技术路线推动 Java 从"对象导向"走向"更接近原生性能"，性能优化需提前布局以利用这些能力。

JVM 技术路线指向"利用现代硬件与并发模型"：虚拟线程优化并发、FFM 优化原生、Valhalla 优化内存。性能优化应跟踪这些演进，选择适合的时机采用。