1、性能优化概述：为什么需要优化？
大家好，我是你们的老朋友。今天咱们聊聊性能优化这件事。
说实话，我刚开始做系统优化那会儿，也觉得这玩意儿挺玄乎的。不就是让程序跑快点吗？后来踩的坑多了，才明白——性能优化不是锦上添花，而是雪中送炭。
1.1 为什么需要优化？
你想想看，一个系统上线后，用户反馈「卡死了」「打不开」「转圈圈」。这时候你怎么办？加服务器？扩内存？
我遇到过最夸张的一次，某电商平台大促期间，CPU直接飙到 99%，页面加载要 8 秒。用户早跑了。后来一查，是某个日志打印线程在疯狂占资源。说白了，优化不到位，再好的硬件也白搭。
优化的核心目标就三个：
- 响应更快：用户点一下，1 秒内要有反馈
- 资源更省：同样的机器，能扛住更大的流量
- 成本更低：少买几台服务器，老板开心，你也省心
核心观点：性能优化不是「没事找事」，而是系统稳定运行的底线。你不优化，用户就会用脚投票。
1.2 CPU 与内存的工作原理简介
要优化，先得知道 CPU 和内存是怎么干活的。我简单说说，不扯太深。
CPU：计算的核心
CPU 就像工厂里的工人。它不停地从内存里拿指令，然后执行。每个指令都要经过：
- 取指：从内存拿到指令
- 译码：看懂指令要干啥
- 执行：真正干活
- 写回：把结果存回去
我习惯把 CPU 比作「流水线」。如果某个环节卡住了，整条线都得等。比如频繁的上下文切换，就像工人不停换工具，效率能高才怪。
内存：数据的仓库
内存是 CPU 的「材料仓库」。CPU 干活需要数据，数据就在内存里。但问题是——CPU 太快，内存太慢。
举个例子：CPU 执行一条指令只要 0.3 纳秒，但从内存读数据要 100 纳秒。差了 300 倍！所以 CPU 内部有缓存（L1/L2/L3），就是为了减少去内存的次数。
个人经验：我在做数据库优化时，发现很多慢查询不是因为 SQL 写得烂，而是因为数据不在缓存里，每次都要去磁盘读。说白了，缓存命中率是性能的关键。
1.3 性能瓶颈的常见类型
性能瓶颈说白了就是「短板」。我总结了几种最常见的：
| 瓶颈类型 | 表现 | 常见原因 |
|---|---|---|
| CPU 密集型 | CPU 使用率长期 > 90% | 死循环、大量计算、频繁上下文切换 |
| 内存密集型 | 内存占用高、频繁 GC | 内存泄漏、大对象分配、缓存过大 |
| I/O 密集型 | 磁盘读写慢、网络延迟高 | 日志刷盘、数据库查询慢、网络带宽不足 |
| 锁竞争 | 线程等待时间长 | 锁粒度太大、死锁、热点资源争抢 |
我遇到过最坑的一次，是某个服务 CPU 不高，内存也不高，但就是慢。查了半天，发现是日志框架在每次请求时都去获取系统时间，而这个操作居然加了锁！一个锁毁所有，这话一点不假。
避坑指南：我曾经以为性能瓶颈一定是 CPU 或内存，后来发现 I/O 和锁才是真正的「隐形杀手」。尤其是锁，你很难从监控上直接看出来，但系统就是慢。
1.4 知识体系总览
下面这张图，是我自己总结的性能优化知识体系。你可以把它当作「地图」，后面每一章都会对应到其中的一个模块。
这张图里，我把性能优化分成了四大块。每一块后面都会详细讲。你记住一句话：优化不是玄学，是有章可循的工程方法。
1.5 小结
这一章我们聊了：
- 为什么需要优化——说白了就是为了用户体验和成本
- CPU 和内存怎么工作的——理解原理才能对症下药
- 常见的性能瓶颈——CPU、内存、I/O、锁，一个都不能忽视
我个人觉得，性能优化最难的其实不是技术，而是「定位问题」。你找不到瓶颈在哪，再牛的优化技巧也没用。所以后面几章，我会重点讲怎么「找」问题，然后再「解」问题。
嗯，今天就到这儿。记住：优化不是一次性的，而是持续的过程。