1. 性能分析基础
大家好，我是你们的老朋友。今天咱们正式开讲《性能分析与代码优化技巧》的第一章。
说实话，性能分析这件事，我做了十几年。刚入行那会儿，我也觉得代码能跑就行，管它快不快呢？直到有一次线上事故——用户量一上来，系统直接挂了，老板拍桌子问我怎么回事。我查了三天三夜，最后发现就是一个循环里多了一次无意义的数据库查询。嗯，从那以后，我再也不敢忽视性能了。
1.1 什么是性能分析？
性能分析，说白了就是回答三个问题：
- 你的系统跑得快吗？
- 它还能跑得更快吗？
- 瓶颈到底在哪？
我个人习惯把性能分析比作「体检」。你想想看，人每年都要体检，查查血压、血糖、心率。系统也一样，需要定期检查它的「健康指标」。只不过系统的指标是响应时间、吞吐量、资源利用率这些。
为什么要做性能分析？我遇到过太多团队，上线前不做压测，结果一上线就崩。性能分析不是锦上添花，而是保命手段。它能帮你：
- 提前发现瓶颈，避免线上事故
- 合理规划资源，别花冤枉钱买服务器
- 提升用户体验，用户可没耐心等3秒
核心观点：性能分析不是一次性的工作，而是贯穿整个开发周期的持续活动。从设计阶段就要考虑，到编码、测试、上线、运维，每一步都不能落下。
1.2 三大核心性能指标
聊性能指标，我一般只看三个维度。多了记不住，少了不够用。咱们一个一个说。
1.2.1 响应时间
响应时间就是用户发出请求到收到响应的时间。你打开一个网页，等了2秒才显示出来，这2秒就是响应时间。
这里有个坑，我踩过。很多人只看平均响应时间，觉得平均100ms挺好啊。但平均会骗人。你想想看，如果90%的请求都是10ms，剩下10%是1秒，平均下来才109ms，看起来不错。但实际体验呢？那10%的用户已经骂娘了。
我建议你看百分位数：
- P50（中位数）：一半请求比这个快，一半比这个慢
- P95：95%的请求比这个快，重点关注
- P99：99%的请求比这个快，这是你的「最差体验」
我的经验：线上监控重点关注P99。如果P99超过1秒，说明有少量请求严重拖慢了整体体验。这时候别急着优化平均，先查那1%的慢请求是怎么回事。
1.2.2 吞吐量
吞吐量是单位时间内系统能处理的请求数量。常见的单位有：
- QPS：每秒查询数，常用于数据库、API接口
- TPS：每秒事务数，常用于交易系统
- RPS：每秒请求数，更通用的说法
吞吐量和响应时间是什么关系？很多人以为它们是一回事。其实不是。我举个例子：
你开了一家奶茶店。响应时间就是顾客从下单到拿到奶茶的时间。吞吐量就是每小时能卖多少杯。这两个指标互相影响——顾客多了，排队时间就长，响应时间就上升。但你不能说「我只要响应时间快，不管卖多少杯」，那生意还做不做了？
所以，性能优化的目标往往是：在保证响应时间可接受的前提下，尽可能提升吞吐量。
1.2.3 资源利用率
资源利用率就是CPU、内存、磁盘、网络这些硬件被用了多少。我见过最离谱的事：某团队买了128核的服务器，结果代码是单线程的，CPU利用率只有1%。这不是浪费钱吗？
常见的资源瓶颈：
| 资源 | 正常范围 | 危险信号 | 常见原因 |
|---|---|---|---|
| CPU | 40%-70% | >90% 持续 | 死循环、密集计算、GC频繁 |
| 内存 | 60%-80% | >90% 或频繁Swap | 内存泄漏、大对象、缓存过大 |
| 磁盘I/O | 利用率 < 60% | 等待时间 > 10ms | 日志过多、数据库慢查询 |
| 网络 | 带宽 < 40% | 丢包率 > 1% | 带宽不足、连接数过多 |
注意：资源利用率不是越低越好。CPU长期低于10%，说明你的机器买贵了，资源在闲置。理想状态是资源利用率稳定在60%-80%，留出余量应对突发流量。
1.3 性能分析工具概览
工具这东西，贵精不贵多。我这些年用下来，真正好用的就那几个。咱们按场景分分类：
1.3.1 系统级工具
- top / htop：看CPU、内存、进程，Linux必备。我每天上班第一件事就是跑一下top，看看有没有异常进程。
- vmstat：看系统整体状态，包括CPU、内存、I/O、上下文切换。排查性能问题时，我第一个用它。
- iostat：专门看磁盘I/O。有一次我发现磁盘利用率不高但响应很慢，一查是磁盘队列太深，iostat直接告诉我了。
- netstat / ss：看网络连接状态。排查端口占用、连接数过多时很有用。
1.3.2 应用级工具
- JProfiler / YourKit：Java应用性能分析，能看CPU热点、内存分配、线程状态。我习惯用它们定位代码级别的瓶颈。
- gprof / perf：C/C++应用的性能分析工具。perf是Linux内核自带的，功能强大，但学习曲线陡。
- Chrome DevTools：前端性能分析，看网络请求、渲染性能、JS执行时间。做Web优化的同学一定要会用。
1.3.3 数据库级工具
- EXPLAIN：分析SQL执行计划。我见过90%的慢查询都是没加索引，EXPLAIN一眼就能看出来。
- 慢查询日志：记录执行时间超过阈值的SQL。线上开启后，定期分析，能发现很多隐藏问题。
- Redis MONITOR：实时查看Redis命令。排查缓存穿透、热点key时很有用。
1.3.4 全链路监控工具
- Prometheus + Grafana：监控和可视化。我习惯把CPU、内存、QPS、响应时间都画在同一个仪表盘上，一眼就能看出问题。
- SkyWalking / Zipkin：分布式链路追踪。微服务架构下，一个请求经过十几个服务，没有链路追踪你根本不知道慢在哪。
- ELK（Elasticsearch + Logstash + Kibana）：日志分析。把错误日志、慢日志集中起来，搜索分析很方便。
我的建议：别一上来就上高大上的工具。先学会用top、vmstat、EXPLAIN这三个，能解决80%的性能问题。工具是辅助，思路才是核心。
1.4 本章知识体系
说了这么多，咱们用一张图把本章的核心内容串起来。这张图是我自己画的，你看完应该能对性能分析有个整体认识。
这张图把本章内容分成了三块：什么是性能分析、三大性能指标、工具概览。你看，其实没那么复杂。核心思路就是先定位瓶颈，再针对性优化。别一上来就瞎优化，那是浪费时间。
好了，第一章就到这里。内容不多，但都是干货。你先把这些基础概念吃透，后面咱们再深入讲具体的分析方法和优化技巧。
可可精品资料库