分类： 面试题

使用 @Async 把耗时任务丢到线程池执行，是 Spring 项目里最常见的异步改造手段。但很多人第一次接入时会遇到一个诡异现象：方法明明加了 @Async，日志里的线程名却还是 http-nio-8080-exec-1，接口照样被阻塞，异步等于没加。更麻烦的是，这个问题在单元测试里往往测不出来，上线压测时才暴露。 根本原因几乎都指向同一件事：@Async

这道题在面试里出现的频率不低，但绝大多数候选人的回答停留在「脑裂就是两个 master，会丢数据」这个层面，再往下问「丢多少、什么时候丢、窗口多长、怎么算」就答不上来了。实际上 Redis 本身并不具备自动的脑裂防护（Sentinel 的 quorum 只能降低概率，不能消除），数据丢失窗口是有明确数学边界、可以被量化和判定的。这篇文章把窗口的构成拆开算清楚

线上排查一个 Go 服务的错误日志时，发现所有经过 defer 包装的错误，errors.Is 全都返回 false，日志里的 %+v 也看不到原始堆栈。代码长这样： func LoadConfig(path string) (cfg *Config, err error) { defer func() { if err != nil { err = fmt

面试里问 Promise，最常见的翻车点不是 new Promise 怎么写，而是被问到「上一个 then 里 return 了个东西 / throw 了个错，下一个 then 到底走 onFulfilled 还是 onRejected」时开始含糊。这个问题之所以容易答错，是因为它同时牵扯三件事：then 的返回值如何被 Promise.resolve 包装

线上一条订单落库接口偶发 Lock wait timeout exceeded; try restarting transaction，日志里死锁检测输出 insert intention lock 与 gap lock 互相等待。开发同学第一反应是"我插的是新数据，没人锁它"。这正是间隙锁最常见的认知盲区：间隙锁锁的是范围，而 INSERT 需要的插入意向