spring boot perf - modric2jeff/archive GitHub Wiki

下面给你一套实用、立刻可用的Spring Boot 性能优化资源清单 + 基于指标的瓶颈排查流程（中文优先、并附权威英文文档）。先给结论式总览，再把步骤、关键指标、工具和参考资料都列清楚，方便你马上落地。

要点速览（结论）

  • 先做好可观测性（metrics + traces + logs），再去调优实现或 JVM 配置。用 Micrometer → Prometheus → Grafana 做指标可视化；用 OpenTelemetry / tracing 做分布式调用链；用 JFR / async-profiler 做低开销生产剖析。([Grafana Labs]1)

推荐学习资料（官方/权威）

  • Spring 官方关于运行时效率与升级带来的性能改善（为什么优先升级到较新 Spring Boot/Framework 有益）。([Home]2)
  • Micrometer + Prometheus + Grafana：如何把 Spring Boot 的 actuator 指标暴露给 Prometheus 并在 Grafana 可视化。实战文章/教程很丰富（Grafana 官方/社区示例）。([Grafana Labs]1)
  • Java Flight Recorder (JFR) / Java Mission Control：用于低开销的生产/近生产剖析（CPU/memory/GC）教程与实践。([Baeldung on Kotlin]3)
  • async-profiler & flame graphs：对 CPU/allocations 的高精度采样、生成 flamegraph，非常适合定位热点方法。([Baeldung on Kotlin]4)
  • JVM GC 调优：Oracle/HotSpot 的官方 GC tuning 帮助你理解不同 GC 的权衡（G1/ ZGC / Shenandoah 等）。GC 调优应在确认为瓶颈后再做。([docs.oracle.com]5)

必备工具（可以立刻装/试）

  • 可观测性：Spring Boot Actuator + Micrometer（带 micrometer-registry-prometheus），Prometheus，Grafana。([Grafana Labs]1)
  • 分布式追踪：OpenTelemetry Java agent / Spring Boot starter（可零改造/自动采集）或 Zipkin/Sleuth（历史方案）。([OpenTelemetry]6)
  • 低开销剖析：JFR + Java Mission Control、async-profiler、YourKit / VisualVM（开发/预发场景）。([Baeldung on Kotlin]3)
  • 堆/线程分析：Eclipse MAT（heap dump）、jstack/jmap、jcmd。
  • APM 选项：Elastic APM、SkyWalking、Pinpoint、NewRelic 等（根据公司预算与需求选）。

关键指标（必须在 dashboard 上可视化）

（指标类别 → 为什么关注 → micrometer/Prometheus 常见表现）

  1. 请求层

    • 吞吐（requests/s）和错误率（4xx/5xx）——看服务是否超载或有错误激增。
    • P50/P95/P99 响应时（直方图/summary）——用于发现尾延迟（micrometer 暴露为 http_server_requests / seconds histogram）。([Grafana Labs]1)

  2. 资源与 JVM 指标

    • CPU 使用率（process + system）、load average、线程数（process_cpu_seconds_total, jvm_threads_live）
    • 堆内存/非堆内存（jvm_memory_used_bytes），GC 次数与耗时（jvm_gc_pause_seconds_*）——判断是否是 GC 或内存问题导致延迟。([Grafana Labs]1)

  3. I/O / 系统级

    • 网络带宽、磁盘 I/O、上下文切换（必要时用 node exporter / host metrics）

  4. 下游依赖（DB / Redis / HTTP）

    • DB 查询时延、连接池使用率（HikariCP 的 hikaricp_connections_*）、慢查询率

  5. 应用内部

    • 线程池队列长度、任务等待时间、锁/同步等待（通过 tracing 或 thread dump 观察）

  6. 自定义指标

    • 关键业务计数器（比如队列长度、批处理大小、缓存命中率）

指标驱动的排查流程（实战步骤）

  1. 建立基线：在正常时段采集 24–72 小时指标（吞吐 / 响应时 / GC / CPU / mem）。

  2. 高层快速三问（根据监控回答）

    • 是 CPU 占满还是 IO/GC/等待造成延迟？（看 process_cpu + system + io + gc pause）
    • 是否是单个 endpoint / SQL 导致？（看 P99 标签按 endpoint / sql）
    • 是资源短缺（连接池/线程池/内存）还是热点代码？

  3. 若 CPU 高 → 采样剖析（async-profiler / JFR）生成 flame graph，查出热点方法并优化。([Baeldung on Kotlin]4)

  4. 若 GC 高 / 内存不足 → 抓 heap dump（jmap / jcmd），用 Eclipse MAT 分析泄漏或大对象占用，并参考 GC tuning 指南做堆/GC 策略调整（不要盲改）。([docs.oracle.com]7)

  5. 若是请求排队/线程饱满 → 导出 thread dump（jstack）查看是否有 BLOCKED / WAITING，检查线程池/连接池配置与调用模式（同步/阻塞）。

  6. 若是下游变慢 → 用 tracing（OpenTelemetry）看调用链中哪个服务/DB/远程依赖耗时最多；按调用链逐层优化或增加并发度/超时与隔离。([OpenTelemetry]8)

  7. 修复后验证：发布改动到 Canary/灰度，观察关键指标是否改善，确认没有回归。

直接可用的配置示例（立刻打开 Prometheus endpoint）

在 pom.xml / build.gradle 加：

  • spring-boot-starter-actuator
  • io.micrometer:micrometer-registry-prometheus

application.properties 示例：

management.endpoints.web.exposure.include=health,info,prometheus,metrics,threaddump
management.endpoint.prometheus.enabled=true
management.metrics.export.prometheus.enabled=true

（把 Prometheus 指向 /actuator/prometheus 拉取指标。）([Grafana Labs]1)

关于生产剖析的安全注意

  • 优先用低开销工具：JFR 与 async-profiler 在现代 JVM 上都可以做到低开销采样；在高压生产环境做长时间剖析前先做短采样并在预发/灰度验证。([Baeldung on Kotlin]3)
  • 堆转储（heap dump）通常会暂停应用或消耗大量 IO，谨慎在高负载环境中触发。

快速参考清单（下一步你可以做的 3 件事）

  1. 在服务中启用 Actuator + Micrometer + Prometheus（按上面示例），搭一个 Grafana dashboard（基本面板：吞吐、P95/P99、CPU、heap、GC、线程数、DB 连接池）。([Grafana Labs]1)
  2. 若遇到 CPU/延迟问题，先用短时间的 async-profiler/CMD JFR 采样生成 flamegraph，快速定位热点。([Baeldung on Kotlin]4)
  3. 若怀疑 GC/内存问题，抓 GC 日志与 heap dump，参考 Oracle/HotSpot 的 GC tuning 指南做验证性实验（逐项改参数并观察）。([docs.oracle.com]5)

如果你愿意，我可以马上为你做其中一项具体工作（任选其一）并直接输出执行细节/脚本/dashboard 模板： A）Prometheus + Grafana 的最小 dashboard（包括查询表达式模板）； B）给出 async-profiler/JFR 在生产环境的采样命令与解析流程（含 flamegraph 示例命令）； C）按你当前应用的指标（或 application.properties / 堆配置）帮你做一次快速诊断清单并指出优先级调整项。

你选一个（A、B、或 C）或者直接发你的 pom.xml / 部署配置片段，我就按你当前环境立刻给出可执行的步骤与命令（不需要等待）。