1. 性能调优概述：什么是策略执行点、性能瓶颈的常见表现、调优的核心目标与原则
各位同学，咱们今天聊点实在的。性能调优这事儿，我做了十几年，踩过的坑比走过的路还多。刚开始那会儿，我也以为调优就是加机器、扩内存，后来才发现——真正的瓶颈往往不在资源上，而在代码的执行路径上。
这一章，咱们先把基础打牢。搞清楚三个问题：什么是策略执行点？性能瓶颈长什么样？调优到底为了什么？
1.1 什么是策略执行点
说白了，策略执行点就是代码里那些做决策、走分支、触发动作的关键位置。你想想看，一个系统跑起来，总得在某个地方判断“要不要做这件事”、“走哪条路”、“用什么参数”。这些判断点，就是策略执行点。
我举个例子。一个支付系统，用户下单后要判断：
- 用户余额够不够？
- 风控规则是否触发？
- 优惠券能不能用？
- 走哪个支付渠道？
每一个判断，都是一个策略执行点。这些点如果设计得不好，性能就会出问题。
核心定义：策略执行点 = 代码中承载业务规则、条件分支、状态转换或资源分配的逻辑节点。它是系统行为的“决策中枢”。
我个人习惯把策略执行点分成三类：
| 类型 | 典型场景 | 性能风险 |
|---|---|---|
| 条件分支型 | if-else、switch-case、规则引擎 | 分支过多导致CPU分支预测失败 |
| 资源分配型 | 连接池获取、内存分配、锁竞争 | 等待时间长、上下文切换频繁 |
| 数据路由型 | 分库分表、消息路由、负载均衡 | 路由算法复杂、哈希冲突 |
嗯，这里要注意：不是所有代码都是策略执行点。纯数据搬运、简单赋值、日志打印这些，一般不归到策略执行点里。只有那些影响系统行为走向的代码，才值得你花精力去优化。
1.2 性能瓶颈的常见表现
性能瓶颈这东西，就像感冒——症状就那么几种，但病因千差万别。我在项目中遇到过太多类似的场景了，总结下来，常见的表现就这五类：
- 响应时间飙升：本来10ms的接口，突然变成500ms。用户开始骂娘。
- 吞吐量上不去：加机器也没用，TPS卡在某个值死活不动。
- CPU跑满：top一看，CPU 100%，但业务量并不大。
- 内存泄漏：GC越来越频繁，最后OOM。
- 线程阻塞：大量线程在等待锁、等待IO，系统像死了一样。
我的经验：遇到性能问题，别急着看代码。先看监控——CPU、内存、IO、网络，哪个指标异常，就往哪个方向查。我曾经花了两天追一个死锁问题，最后发现是数据库连接池配小了。嗯，从那以后我养成了先看资源指标的习惯。
为什么会这样？其实很多性能问题，根源都在策略执行点上。比如：
- 一个if-else里做了大量计算，导致CPU飙高。
- 一个锁的范围太大，导致线程排队。
- 一个路由算法用了哈希取模，数据倾斜导致单节点过载。
你想想看，如果这些策略执行点设计得合理，很多问题根本不会出现。
1.3 调优的核心目标与原则
调优不是炫技，不是为了把代码写得花里胡哨。调优的核心目标就三个：
- 降低延迟：让请求更快返回。
- 提升吞吐：让系统能处理更多请求。
- 保证稳定性：别动不动就挂。
这三个目标有时候是矛盾的。比如，为了降低延迟，你可能用缓存，但缓存会消耗内存，影响稳定性。所以，调优的本质是 trade-off。
我个人做调优，遵循这几个原则：
| 原则 | 说明 | 我的做法 |
|---|---|---|
| 先测量，后优化 | 没有数据，不要动手 | 先上APM，看火焰图，找到热点 |
| 二八原则 | 20%的代码消耗80%的资源 | 集中精力优化热点路径 |
| 保持简单 | 复杂的优化往往引入新问题 | 能用数组不用HashMap，能用int不用Integer |
| 可回滚 | 优化失败要能快速恢复 | 用配置开关、灰度发布 |
避坑指南：我曾经为了优化一个接口，把同步改成了异步，结果业务逻辑乱了，数据对不上。最后花了三天才修回来。所以，优化前一定要想清楚回滚方案。没有退路的优化，就是赌博。
好了，这一章的内容就这些。咱们把基础概念理清了，后面才能深入实战。记住一句话：策略执行点是系统的命门，性能调优就是给命门做体检。