性能分析工具链：从底层到前端的全景视角
做性能调优这么多年，我最大的感触就是——工具不在多，在于会用。很多人电脑里装了一堆监控软件，真到排查问题时却无从下手。说白了，你得先搞清楚：问题出在哪一层？
这一章，我带你把整个工具链捋一遍。从操作系统、Java虚拟机、数据库，再到前端，每个层面我都会挑几个趁手的工具来讲。嗯，都是我实际项目中反复验证过的。
核心思路：性能分析不是一上来就抓数据，而是先定位瓶颈层，再选对工具。我习惯用「分层排查法」——从硬件到应用，逐层缩小范围。
Linux 性能工具集：系统层面的「听诊器」
先聊聊操作系统层面。我个人习惯，任何性能问题排查，第一步永远是看系统资源。你想想看，如果 CPU 都跑满了，应用层再优化也是白搭。
1. top —— 实时系统监控
top 是我用得最频繁的命令，没有之一。它能告诉你：CPU 使用率、内存占用、负载情况，还有每个进程的资源消耗。
我的小技巧：按 P 键按 CPU 排序，按 M 键按内存排序。排查问题时，我一般先看 %CPU 和 %MEM 两列，哪个异常高就先查哪个。
2. vmstat —— 系统整体健康度
vmstat 1 5 是我排查内存和 IO 瓶颈的标配。每 1 秒输出一次，共 5 次。重点关注 si 和 so 两列——如果这两个值持续不为 0，说明内存不够用了，系统在疯狂换页。
我曾经踩过的坑：有一次线上服务响应变慢，我看 top 发现 CPU 不高，内存也够，百思不得其解。后来用 vmstat 一看，wa（等待 IO）列飙到 40% 以上。原来是磁盘 IO 成了瓶颈。嗯，从那以后我排查问题必看 vmstat。
3. iostat —— 磁盘 IO 的放大镜
当 vmstat 显示 wa 偏高时，就该 iostat -x 1 上场了。重点关注：
%util—— 磁盘繁忙程度，超过 80% 就要警惕await—— IO 请求的平均等待时间，毫秒级svctm—— 实际服务时间，如果远小于 await，说明排队严重
4. netstat —— 网络连接诊断
排查网络问题，netstat -anp | grep :8080 可以看某个端口的连接状态。我特别关注 TIME_WAIT 和 CLOSE_WAIT 的数量——这两个值如果持续增长，说明连接没有正常释放。
5. perf —— 性能剖析的终极武器
perf 是 Linux 内核自带的性能分析工具，功能非常强大。它能告诉你 CPU 到底在忙什么——是执行用户代码，还是在内核里打转？
# 采样 10 秒，记录 CPU 事件
perf record -a -g -- sleep 10
# 查看热点函数
perf report我记得有一次排查一个 Java 应用 CPU 飙高的问题，用 perf top 一看，发现热点竟然在 java.lang.String.indexOf 上。顺着这个线索，很快定位到代码里有个 O(n²) 的字符串匹配逻辑。你看，工具用对了，问题就藏不住。
Java 性能工具：深入 JVM 内部
系统层面没问题，那就该看应用层了。Java 应用的性能分析，我主要靠这三件套。
1. JMC (Java Mission Control) + JFR (Java Flight Recorder)
JFR 是 Oracle 官方提供的低开销采样工具，对生产环境影响极小。我个人习惯：先开 JFR 录制 5-10 分钟，然后用 JMC 打开分析。
重点关注几个 Tab：
- 内存 —— 看 GC 频率和暂停时间，有没有内存泄漏迹象
- 代码 —— 热点方法、锁竞争、线程阻塞
- IO —— 文件读写、网络 IO 的耗时分布
避坑指南：JFR 默认只保留最近 5 分钟的数据。如果你要排查偶发问题，记得把录制时长设长一些，或者用 -XX:StartFlightRecording=duration=60m 启动时就开始录制。
2. JProfiler —— 可视化分析利器
JProfiler 是商业工具，但确实好用。它的 CPU 视图和内存视图非常直观。我特别喜欢它的「堆遍历」功能——可以实时查看每个对象占用了多少内存，谁引用了它。
举个例子，有一次我怀疑某个缓存导致内存泄漏。用 JProfiler 一看，HashMap 里有个 key 一直没被回收，顺着引用链找到了一个静态变量。嗯，问题就出在「忘记移除过期缓存」上。
数据库性能工具：SQL 层面的「体检报告」
数据库往往是性能瓶颈的重灾区。我见过太多「代码写得挺好，SQL 写得稀烂」的案例了。
1. 慢查询日志
第一步，打开慢查询日志：
-- 开启慢查询日志
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1; -- 超过 1 秒的 SQL 记录然后用 mysqldumpslow 分析日志，找出执行次数多、耗时长的 SQL。我一般先看「总耗时排名」和「平均耗时排名」两张表。
2. EXPLAIN —— 执行计划解读
拿到慢 SQL 后，用 EXPLAIN 看它怎么执行的。重点关注：
| 字段 | 含义 | 危险信号 |
|---|---|---|
| type | 访问类型 | ALL（全表扫描） |
| rows | 预估扫描行数 | 远大于实际返回行数 |
| Extra | 额外信息 | Using filesort、Using temporary |
我的经验：看到 Using filesort 或 Using temporary，十有八九是索引没建好，或者查询语句需要优化。我曾经帮一个团队优化过一条 SQL，加了个联合索引，查询时间从 8 秒降到了 0.02 秒。你想想看，这差距有多大。
3. Performance Schema
MySQL 5.7+ 自带的性能监控，比慢查询日志更细粒度。可以监控：
- 哪些 SQL 消耗了最多的 IO
- 哪些锁等待时间最长
- 哪些表被访问最频繁
-- 查看 IO 消耗最高的 SQL
SELECT * FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;前端性能工具：用户体验的「最后一公里」
后端再快，前端加载慢，用户照样骂娘。前端性能分析，我主要用这两个。
1. Lighthouse
Google 出品的自动化审计工具，直接给页面打分。重点关注：
- First Contentful Paint (FCP) —— 首次内容绘制，建议 < 1.8s
- Largest Contentful Paint (LCP) —— 最大内容绘制，建议 < 2.5s
- Cumulative Layout Shift (CLS) —— 布局偏移，建议 < 0.1
Lighthouse 还会给出具体的优化建议，比如「启用文本压缩」「移除阻塞渲染的资源」等。我一般按它的建议优先级从高到低改。
2. Chrome DevTools —— Performance 面板
Lighthouse 是「体检报告」，DevTools 的 Performance 面板就是「CT 扫描」。录制一段操作，然后看：
- Main 线程 —— 哪些函数执行时间最长
- Network —— 每个请求的耗时分布（DNS、TCP、SSL、TTFB）
- Frames —— 帧率是否稳定，有没有掉帧
我曾经犯过的错：有一次优化一个后台管理系统，我用 Lighthouse 跑分很高，但用户还是说卡。后来用 DevTools 的 Performance 面板一录，发现有个表格渲染函数每次执行要 200ms，页面滚动时频繁触发，导致掉帧。你看，自动化工具不能替代人工分析。
小结
这一章我带你走了一遍性能分析工具链的全景。记住一个原则：从底层到上层，逐层排查。系统资源不够，先解决系统问题；系统没问题，再看应用；应用没问题，再看数据库；最后才是前端。
工具只是手段，思路才是核心。你把这些工具用熟了，遇到性能问题就不会慌了。