告警：一条 JOIN 把从库 CPU 拉满 七月五号，DBA 在群里 @我：「你那条报表 SQL 把从库 CPU 干到 100%，跑了 40 秒还没出」。这是一条订单表（8000 万行）和用户表（2000 万行）的关联查询，原本是凌晨跑的批，被临时拉到白天查。我拿 EXPLAIN 一看，问题很清楚。
背景：一个写了 60 行的排行榜 SQL 七月做运营后台，产品要「每个城市的销售 Top3」和「月度累计业绩」。第一版我用子查询嵌套，SQL 拉到 60 多行，GROUP BY 套 GROUP BY，执行计划里全是 DEPENDENT SUBQUERY，跑一次 3 秒多。同事提醒我：你们库早升 My
背景：一次排查花了三个小时 六月一次线上下单失败，从接到告警到定位根因花了三个小时。不是问题复杂，是信息散——日志在 ELK、指标在 Prometheus、链路在 SkyWalking，三套系统各看各的，人肉拼不出完整画面。那周我推动了可观测性体系重构，把三大支柱真正串起来。 三大支柱：日志、指标、
背景：一次全量构建喝了杯咖啡还没好 六月我们一个核心服务模块膨胀到 180 个 Maven 模块，mvn install 一次 6 分半。CI 排队严重，开发等得烦躁。我提议评估迁移 Gradle，但团队一半人不乐意——XML 写惯了，怕 DSL 学习成本。于是我做了个对照实验，用同一份源码分别用
面试被问住：线程池里的异常去哪了 五月面试一个候选人，他反过来问我：「用 ExecutorService 提交了三个任务，其中一个抛异常，另外两个还在跑，怎么保证它们被取消？」我脱口而出「写个 Future 判断」，但细想发现，传统线程池里任务生命周期是散的，取消一个不影响其他——这恰恰是结构化并发
背景：3.1 刚发布，3.2 在路上 五月十八号 Spring Boot 3.1 正式发布，我们组件库当天就升了。3.2 按计划十一月才来，但里程碑里已经能看出方向。趁热把两版新特性盘一遍，顺手在预发环境验证了几个最实用的。 Docker Compose 支持（3.1） 以前本地起依赖靠 testc
背景：一次冷启动慢到被运维吐槽 五月初我把一个内部配置中心客户端容器化，K8s 里副本从 0 扩容到 10 时，启动要 8 秒多，滚动发布期间总有几秒请求打不到。运维说你这 Java 应用太重了。我琢磨着试一把 Spring Boot 3 的原生镜像——GraalVM 把应用直接编译成机器码，启动该
读源码的动机：1 毫秒停顿到底是什么换来的 五月的 JDK 21 EA build 里，分代 ZGC 已经能跑了。官方说停顿能控制在 1 毫秒内。我好奇的是——不分代的 ZGC 已经够强，为什么还要分代？翻了 GC 源码和 JEP 439，才把这件事想明白。 分代假设：大多数对象活不过第一轮 分代回
事故：用户收到两笔重复的退款 五一后第一天，客服转来一个投诉：同一笔订单退了两次款。查 MQ 消费日志，发现退款消息被消费了两次。RocketMQ 的「至少一次」投递语义意味着重复消费必然发生，幂等没做好的锅，得我们自己背。 排查：为什么恰好重复 消息体里其实带了唯一的 refundId，但旧代码直
背景：为下半年的 JDK 21 LTS 提前做验证 四月我们开始评估下半年升级到 JDK 21 LTS 的可行性。GC 是这次升级最敏感的部分——ZGC 在 JDK 21 里终于要兑现「亚毫秒停顿」的承诺，Shenandoah 也迭代到第三代。我拉了 JDK 21 的早期 EA build（当时到
