Java 排障专题

线上 CPU 高时，很多排查会先集中在一个非常具体的目标上：

线上经常会碰到一种很别扭的现场：应用侧数据库调用 RT 明显抬高，接口 RT、超时率、连接池压力也在变差，但慢日志里又看不到特别扎眼的大慢 SQL。难点往往不在于找不到 SQL，而在于 RT 里混进了多少锁等待、事务停留、连接排队和 I/O 波动。数据库 RT 变高，并不等于 SQL 执行本身一定变慢。

数据库等待链最难受的地方，不是数据库一眼打满，也不是某条 SQL 明晃晃地慢到藏不住。

19:27，库存中心的几个接口一起开始发抖。

分布式锁最难排的，不是锁直接报错，而是系统慢下来时看上去一切都还在工作：请求也能拿到锁，服务也没挂，错误率也不高，但吞吐就是一格一格往下掉。

很多团队看到 GC 图时，注意力都会先落在 Full GC 上。

19:47，一条投诉进来：用户说客户端 2 秒就报超时。几乎同时，网关面板上 504 抬头，应用里也开始出现下游 Read timed out。

Heap Dump 到手时，最容易产生一种错觉：证据终于齐了，接下来只要找“最大对象”就行。