Java 排障专题

我见过最典型的一次“止血做对了，后面还是出事”，不是因为动作本身错了，而是因为没人把它当成一笔带期限的借款。

线程池和数据库连接池，很多团队习惯分开配。线程池按 CPU 核数、任务类型和历史经验估，连接池按数据库连接上限、机器数量和框架默认值估，单看每一边都像有道理。

排线程池时，很多人第一眼就盯 active 和 queue。这没错，但线上最容易把人带偏的，恰恰是另一种看上去“没堆起来”的现场：

线程池参数是 Java 工程里最容易被“口诀化”的东西之一。

很多人第一次理解 ThreadLocal 风险时，想到的通常都是业务线程池：

很多接口线上出事，并不是因为团队完全没有配超时、重试、熔断，而是这三个参数从来没被当成一件事设计。

我见过最难做决定的一次超时风暴，不是在第一批 timeout 出来的时候，而是在第七分钟。

Spring Boot 服务一发慢，监控上最容易同时冒红的，往往就是 Tomcat busy threads 和业务线程池的 queue / backlog。