Java 排障专题

当你看到写接口 RT 抬高、事务接口偶发超时、连接池等待时间也开始变长时，第一反应通常会先去看数据库 CPU、慢 SQL 数量和 explain。但这类现场里，最容易被漏掉的一条主线其实是： 数据库没有全面打满，不代表数据库等待链没有先把应用拖慢。

那晚先出问题的接口，是 /coupon/available/list。

GC overhead limit exceeded 这类报错，最容易让人做出一个过早、也最省事的结论：

很多“内存问题”真正最好查的时候，不是已经 OutOfMemoryError 的那一刻，而是它还没把服务打死、却已经露出完整判断链的时候。

线上出现 OOM，最容易发生的不是“大家不会排查”，而是 真正该留的现场，在最开始几分钟里就被弄丢了 。

很多人一听“先查最近一次变更”，会下意识想到一句有点空的话：

代码里已经切了线程，接口体验却还是像同步一样慢，这类异步问题在线上很常见。最容易误判的地方，是把所有现象都压成一句“@Async 没生效”。

自动配置这件事，平时不太会有人专门去想它。