你整天盯着慢查询日志，把索引建了又删，连接池调成天大的数字，却发现系统还是像老牛拉破车。别急着甩锅给数据库，后端性能调优的第一性原理，是找到真正被浪费的时间，而不是凭感觉优化那些听起来唬人的指标。这份清单不教你怎么用工具，只告诉你该往哪儿看，以及看到之后该做什么。
延迟分布的真相：别被平均值骗了
性能问题就像一座冰山，平均耗时只是水面上的尖角，真正杀死系统的往往是那1%的尾部延迟。如果你只看P50或者平均响应时间，那你永远不知道用户为什么会摔手机。建议用分位数把延迟拆开：P50、P95、P99、P99.9。P99飙升但P50正常，说明系统里存在间歇性阻塞——大概率是GC停顿、线程池饥饿或者外部依赖抖动。另一个被忽略的维度是延迟分解，每一次请求的耗时，必须按阶段拆解到网络、I/O、业务逻辑、序列化，否则你根本不知道瓶颈在哪个环节。装个OpenTelemetry，给每个请求打上时间戳，比看一百个监控大屏都有用。
线程池参数不是玄学，是数学题
很多人把线程池参数当成彩票号码，随手填个200就完事。线程池的大小应该由阻塞系数决定，而不是由CPU核数决定。公式很简单：N_threads = N_cpu (1 + wait_time / compute_time)。如果你的服务全是I/O操作，等待占比90%，那么4核机器开40个线程都嫌少；如果全是CPU计算，开4个就够。关键在于让每个线程始终有事干，而不是在那儿睡大觉。现代工具还有个隐形杀手——虚拟线程。如果还在用Java的synchronized锁，虚拟线程会被沙雕地钉在载体线程上，你开的百万协程瞬间变成百万线程池。所以先磨刀，再砍柴。
连接池：既要当貔貅，又要做漏斗
数据库连接池、Redis连接池、HTTP连接池……每个都是你系统的“流量闸门”。连接池不是越大越好，因为每个连接都在吃内存、占文件描述符，而且数据库端也会付出代价。通过压测找到最优的“水位线”，核心指标是“平均连接获取等待时间”。如果这个时间超过10毫秒，说明池子太小；如果池子里空闲连接经常超过30%，说明池子太大纯属浪费。别忘了设置“最小空闲连接数”，让你的服务在突发流量来临前就把连接预热好。连接池必须支持快速失败和超时中断，否则一个依赖卡死，你的连接池就被慢慢塞满，最终整条链路一起拖死。
I/O模型：你的线程到底在忙什么
同步阻塞式I/O（BIO）在简易场景下能跑，但在高并发下就是灾难。每个阻塞的线程都意味着一个被占用的内存栈（通常1MB左右），1000个并发就是1GB的默认栈空间。如果你还守着传统的Servlet容器，赶紧换用Netty、Vert.x或者WebFlux这类非阻塞框架。但非阻塞I/O也有陷阱：你的代码里绝对不能出现Thread.sleep()、阻塞式数据库驱动、或者任何同步锁，否则事件循环线程一阻塞，整个服务就瘫痪了。注意，使用响应式编程不等于性能提升，它只是让你能用更少的线程支撑更大的并发。如果业务逻辑本身是CPU密集型的，那用同步模型反而更简单高效。
内存与GC：把垃圾回收的时间还给业务
每个Java开发者都经历过GC调优的噩梦。最有效的调优策略就是换一块大的堆内存，然后让GC尽量别发生——这听起来像废话，但很多人的堆设得太小，导致GC频率离谱。把堆设置成机器物理内存的1/4或1/3，然后观察GC日志。如果Full GC持续超过1秒，别去疯狂调参数，先检查是不是内存泄漏：缓存里的对象无限增长，或者线程池里的ThreadLocal没有清理。绝大多数GC问题的根源是分配率太高，而不是GC算法不给力。想办法减少临时对象创建——把BigDecimal换成整数计算，复用buffer，避免字符串拼接。让堆内存的使用曲线保持平稳，比任何G1、ZGC参数的微调都管用。
缓存：分清真假热点
缓存是性能调优的万金油，但用错了就是毒药。缓存只适用于“读多写少”且“容忍一定的数据延迟”的场景，别把数据库的数据全都塞进缓存，那样只能让你的缓存成为数据一致性的负担。先根据业务数据统计热点比例：如果一个数据被反复读取，命中率超过70%，那值得缓存；如果你缓存了100万个key，但实际只用到其中100个，那纯粹是浪费内存。缓存必须设定过期策略和内存上限，否则它就是另一个慢速数据库。别忘了缓存穿透：用布隆过滤器挡掉无效请求，否则恶意用户疯狂请求不存在的key，直接把数据库打爆。真正的热点数据甚至可以放到本地内存（如Caffeine），减少一次网络往返，前提是你能接受多节点间的数据不一致。
数据库：索引立了功，也闯了祸
人人都知道要建索引，但很少有人注意到索引也是要付出写代价的。每次插入、更新，都要同步维护索引树。如果你的表写入吞吐量上不去，看看是不是索引建太多了。用EXPLAIN分析执行计划时，重点看有没有“Using filesort”和“Using temporary”，这俩是性能杀手。覆盖索引比普通的二级索引好得多——查询的字段都在索引里，单靠索引就能返回，不触碰聚簇索引和行数据。另外，分页深翻页（offset 1000000 limit 10）是灾难，改成基于游标的分页，用where id > last_id limit 10，性能提升是数量级的。不要把复杂的联查逻辑放在SQL里，先把数据查出来，在应用层做join，很多时候反而更快，因为数据库最怕高并发下的复杂执行计划。
并发：锁的粒度决定速度的天花板
你写了一个synchronized方法确保线程安全，结果所有请求串行执行了。锁的粒度每缩小一点，并发能力就上升一大截。能用原子类就别用锁，能用读写锁读多写少就别用重锁，能用分段锁就别用全局锁。ConcurrentHashMap为什么快？因为它把锁拆分到每个桶。在业务层面，尽量用最终一致性代替强一致性，比如库存扣减，先用Redis做预扣，再异步更新数据库，既快又稳。还有并发控制中容易被忽略的点——volatile关键字只能保证可见性，不保证原子性，用错了就是bug温床。对于热点资源的并发控制，要采用“无锁化”方案，比如使用LongAdder替代AtomicLong，在超高并发下计数器性能提升十倍不止。
异步化：让请求不再排队等大巴
同步调用就是“必须等大巴到站才能走”，异步就是“买好票，大巴不等你”。凡是那些不需要立即返回给前端的结果，全部异步化。比如发送邮件、推送通知、写日志、生成报表，这些操作丢到消息队列里，让后台消费者慢慢处理，主请求立即返回。但异步化也不是银弹：异步链路越多，排错越难，你需要链路追踪把整个调用链串起来，哪怕跨线程也要传播traceId。另外，异步化不等于“开了线程池就完事”，你要给每个异步任务设置超时、重试、死信队列，否则一个任务卡死，后续任务堆积，你的消息队列变成垃圾场。记住一个原则：用户等不了的都异步，用户要立刻看到的必须同步。
网络层：TCP调优的最后几毫秒
你应用侧调得再好，网络层一个抖动就把成绩拉垮了。开启TCP_NODELAY，禁用Nagle算法，减少小包合并带来的延迟。如果你的服务长连接众多，打开SO_REUSEPORT，让多个进程共用同一端口，实现内核级负载均衡。针对高并发短连接场景，用连接复用代替每次新建连接——这就是HTTP连接池存在的原因。还有tcp_keepalive_time调小，让内核及时清理僵尸连接。另外一个容易被忽略的坑是“首包延迟”，尤其跨机房调用，走公网和走专线延时差了十倍。是否考虑将服务部署节点靠近用户，或者用anycast/就近接入，比在代码里抠毫秒更管用。网络调优往往是在压测时用tcpdump抓包分析，看看SYN重传率、丢包率，而不是盲目加大缓冲区。
压测与上线：你的性能预算达标吗
没有压测就上线，等同于不试跳就玩蹦极。压测的目标是找出性能拐点，而不是证明系统很厉害。用压测工具（比如wrk、Gatling、Locust）逐步提高并发，记录吞吐量和响应时间的变化曲线。当吞吐量不再上升、延迟骤然升高的时候，就是系统的极限。这时候要分析是哪一个资源耗尽：CPU、内存、线程数、连接数还是文件描述符。根据压测结果制定“容量规划”：单机支撑多少QPS、集群需要几台机器、峰值流量下的SLA能打多少折扣。上线时使用灰度发布和自动回滚机制，如果新版本的P99延迟比旧版本多了20%，说明你引入了性能回归，立即回滚。不要等到用户投诉后再处理。
监控告警：没有数据，一切调优都是盲人摸象
最后，你需要一套完整的可观测性体系：指标（Metrics）、日志（Logs）、链路（Traces）。至少覆盖这几个核心指标：QPS、错误率、响应时间分位数、CPU、内存、GC频率、线程状态、连接池使用率、磁盘I/O。告警不是在指标超标时发个邮件，而是要设置动态阈值，比如P99连续5分钟超过基线值的20%才告警，避免抖动误报。把每一次性能优化都写成变更记录，附上优化前后的对比数据，这样你才会形成自己的调优“直觉”。记住，性能调优不是一次性工程，而是持续的质量内建。每一次版本迭代，都会引入新的性能债务，定期复盘和回归测试才能守住性能底线。
这份清单覆盖了从请求进入到你机器的每一层：线程、内存、I/O、数据库、缓存、网络、异步、并发。下次系统又慢了，顺着这条路径一层层排查，把“感觉”换成“数据”，把“调参”换成“定位根因”，你就是一个合格的性能调优工程师。优化无止境，先跑通再调好。动手吧。
