16 性能分析、压测与诊断工具

性能问题不能靠“感觉有点慢”定位，也不能靠一张高 QPS 截图证明容量。一次可信实验需要两条相互校验的证据链：JMeter、k6、wrk、ab、hey 制造受控负载；JFR、JMC、VisualVM、JDK CLI、Arthas、async-profiler 和 Chrome Performance 分别解释负载落到系统后发生了什么。JDK 能力与桌面产品会互相读取产物，但安装、状态、权限和退出责任仍各自独立。

工具能启动，只证明执行入口存在。容量结论还依赖业务模型、生产压测授权、停止条件、限流与扩缩容策略、值班接管、服务端观测和业务目标。架构、研发、测试、平台与运维必须在实验前签清目标、流量上限、数据处置和止损责任，不能让一个压测脚本替团队做风险决策。

先分清三个问题

一次性能实验必须依次回答：流量是否符合真实业务模型，发压端是否先到瓶颈，被测系统的哪一层出现了可重复的饱和或等待。只回答其中一个，结论都不完整。

并发数、连接数、虚拟用户数和请求到达率不是同一个概念。平均耗时也不能替代 P95、P99、错误率和吞吐。测试开始前先写清开放或闭环负载模型、预热阶段、稳态阶段、测试数据、最大流量、立即停止条件，以及压测机自身 CPU、网络、文件句柄和临时端口的观测方法。

阅读顺序

文章	先解决的问题	架构师继续判断
JMeter	用测试计划、线程组、断言和 CLI 报告跑通复杂协议测试	分布式 Engine、结果回传、数据分片和性能门禁
k6	用代码定义场景、Check 和 Threshold	到达率模型、Operator、Cloud 数据边界和 CI 分层
wrk	建立高连接 HTTP/1.x 闭环吞吐基线	线程/连接模型、LuaJIT 与生成器饱和
ApacheBench	做请求总量、并发与 Keep-Alive 冒烟	长度失败、两项 Time per request 与客户端限制
hey	做 worker 限速与 HTTP/2 轻量对照	每 worker QPS、连接复用、多核和 CSV 证据
JDK Flight Recorder	持续或短时录制 JVM 事件	事件成本、滚动窗口、repository 和敏感文件治理
JDK Mission Control	用规则、事件浏览和时间窗分析 JFR	规则边界、JMX、插件、工作区和版本复现
VisualVM	在开发机观察、采样并浏览线程或堆	Sampler/Profiler 扰动、远程 JMX 和插件边界
jcmd、jstack 与 jmap	导出线程、类和堆证据	attach 权限、停顿风险、容器 PID 和事故取证
Arthas	对限定类和方法做在线观察	字节码增强扰动、审计、恢复和生产边界
async-profiler	采集 CPU、wall、alloc 或 lock 事件并生成可解释视图	事件选择、采样偏差、容器权限和跨证据验证
Chrome Performance 与 Web Vitals	把页面长任务和体验指标接进性能实验	实验室与真实用户边界、前后端证据相关性

性能审计基线见 Lighthouse，运行时 trace 的具体采集回到 Chrome DevTools。采集完成后，还要用发布版本、实验阶段、请求 ID、Trace ID 和统一时钟把页面长任务、网络瀑布、服务端延迟、线程栈与资源饱和放回同一条时间线；否则前端截图和服务端压测报告仍是两组无法互证的材料。

一次可接受的性能实验

团队归档不能只有报告截图，至少要保存：被测版本和配置、目标环境、脚本版本、测试账号与数据策略、负载模型、预热和稳态时段、发压机规格与利用率、客户端原始结果、服务端指标、日志或 Trace、必要的 JVM/火焰图证据、停止条件是否触发、结论、限制和负责人。

性能结论必须带有效期。代码、JDK、依赖、实例规格、数据量、索引、网络拓扑或限流配置任一关键条件变化后，旧数字只能作为历史基线，不能继续承诺新系统容量。

共通安全底线

边界	默认要求
目标	目标必须白名单化，默认只允许 localhost、专用测试域名和明确批准的环境
数据	写请求使用隔离租户和可清理数据，不把压测数据混入真实订单、消息和审计报表
止损	从小流量阶梯升压，错误率、尾延迟、资源池、队列、数据库或业务告警越线即停止
凭证	认证信息不进入脚本、命令历史、JTL、Trace、heap dump、火焰图标签和 CI 日志
产物	线程栈、JFR、heap dump、方法参数和浏览器 Trace 采集前确定审批、位置、访问者和删除时间
诊断	attach、字节码增强、heap dump 或长时间采样必须有 owner、期限、停止动作和恢复验证