1. 优化思维启蒙：什么是性能优化？

大家好，我是这门课的主讲人。在正式开始之前，我想先聊聊一个看似简单的问题：到底什么是性能优化？

我见过太多人把优化当成「玄学」。代码跑慢了，就随手加个缓存；页面加载卡了，就盲目压缩图片。结果呢？缓存命中率低得可怜，图片压缩后反而更模糊了。

说白了，性能优化不是碰运气，而是一套系统性的工程方法。它的本质是：在有限的资源约束下，找到系统响应速度与资源消耗的最佳平衡点。

1.1 优化的核心思想

做优化这么多年，我总结出两个最底层的思维模型。你掌握了它们，就抓住了优化的「牛鼻子」。

二八定律（帕累托法则）

这个定律在优化领域简直无处不在。它告诉我们：80% 的性能问题，往往是由 20% 的代码或模块引起的。

我记得刚入行时接手过一个后台管理系统。整个页面加载要 8 秒，我一开始像个无头苍蝇一样到处改。后来用 Profiler 一分析，好家伙，一个未优化的 SQL 查询就占了 6.5 秒。改完这个查询，页面直接降到 1.5 秒。

所以我的建议是：别急着动手，先找到那 20% 的瓶颈。怎么找？用数据说话。

优化阶段	关注点	常用工具
定位瓶颈	找出最耗时的 20% 环节	Chrome DevTools、JProfiler、Arthas
量化评估	确定优化前后的性能指标	Lighthouse、JMeter、wrk
针对性改进	集中精力解决核心瓶颈	代码重构、算法优化、缓存策略
验证效果	确认优化是否达到预期	A/B 测试、性能回归

局部性原理

这个原理听起来有点学术，其实特别接地气。它包含两个层面：

• 时间局部性：刚刚访问过的数据，很可能马上还会再访问。比如循环里的变量。
• 空间局部性：访问了一个数据，它附近的数据很可能也会被访问。比如数组的连续遍历。

你想想看，CPU 的缓存、操作系统的预读、数据库的缓冲池，底层都是靠这个原理工作的。我曾在项目中遇到过一个问题：一个数据处理任务跑了一个小时都没结束。排查后发现，代码里用链表来存储中间结果，导致 CPU 缓存命中率极低。改成数组后，任务时间直接缩短到 12 分钟。

1.2 优化与重构的区别

这个问题我经常被问到。很多人觉得优化就是重构，重构就是优化。其实不然。

我画了一张图，帮你快速理解它们的关系：

我再用一个表格帮你对比清楚：

维度	性能优化	代码重构
核心目标	提升运行速度、降低资源消耗	改善代码结构、提升可维护性
关注点	时间、空间、吞吐量、延迟	可读性、扩展性、复用性、低耦合
常用手段	缓存、索引、并发、算法优化	提取函数、消除重复、设计模式
衡量标准	QPS、RT、CPU 使用率、内存占用	圈复杂度、代码行数、重复率
典型风险	可能降低代码可读性	可能引入新的性能问题

1.3 优化思维启蒙：从「能跑」到「能跑得快」

做优化这么多年，我最大的感触是：优化是一种思维习惯，不是一项孤立的技术。

很多人写代码只关心「能不能跑通」，这是最低标准。一个优秀的工程师，会时刻问自己三个问题：

1. 这段代码在极限情况下会怎样？（比如 100 万条数据、1000 个并发）
2. 有没有更省资源的方式？（比如用位运算代替取模、用预计算代替运行时计算）
3. 这个方案能支撑未来 6 个月的增长吗？（考虑业务量的自然增长）

我刚开始带团队时，有个同事写了一段代码，功能完全正确。但我问他：「如果用户量翻 10 倍，这个接口还能扛住吗？」他愣住了。后来一压测，果然，QPS 刚到 200 就崩了。我们花了一下午，把核心逻辑从 O(n²) 优化到 O(n log n)，QPS 直接飙到 5000+。

这就是优化思维的价值——不是等出问题了再救火，而是在设计阶段就埋下高性能的基因。