从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 这个栏目不打算做成读书笔记的搬运。我做了八年 Java 和 AI，又自己跑过出海盘子、也清零过两次，读这些书
提前迁移 Spring Boot 3.0：踩在 GA 前的准备 Spring Boot 3.0 要在 2022 年 11 月正式 GA，但我司有几个新服务打算直接基于 3.0 起项目，不想上线半年就面临大版本升级。于是我在 9 月就基于3.0 的里程碑/RC 候选版本做了一次迁移验证，把要改的点摸了
「线程数加到 800 了，还是上不去」 1 月中旬看压测报告，开放平台那个网关服务的并发一直卡在 4000 左右。压测的同学在群里说：「Tomcat 线程数已经从 200 加到 800 了，加不动了，再加 Full GC 就开始频繁。」 这个症状太典型了——线程成了并发的天花板。我把之前攒的 Loo
背景：一次排查花了三个小时 六月一次线上下单失败，从接到告警到定位根因花了三个小时。不是问题复杂，是信息散——日志在 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（当时到
复盘：一次被迫停更的迭代 四月那次版本上线前夜，我盯着依赖图发呆——一个订单核心模块被 27 个地方引用，改一处要回归 40 个用例，测试同学直接摆烂说「这版先别动它」。这不是第一个被技术债拖住的需求。入行第六年，我越来越觉得，技术债不是写烂代码，是「明知该改但一直没改」的累积。 债务识别：先把账算
问题代码：第一版大模型调用把线程池打满了 四月我们想给工单系统接一个大模型做自动摘要。第一版我图省事，用 RestTemplate 直接 POST 到 OpenAI 兼容接口，同步等返回。压测一上来就出问题：模型平均响应 3 秒，线程池 200 个线程 10 秒就被占满，QPS 卡在 60 上不去。
告警：凌晨三点的慢查询邮件 四月某天早上，运维把一封告警邮件转给我：「日志检索接口 P95 超过 8 秒，ES 集群 CPU 打满」。我们的应用日志一直存在 Elasticsearch 里，单日写入约 30 亿条，随着业务量涨，ES 的堆内存和查询延迟都快撑不住了。老板提了个方向：能不能把明细日志搬
每天 300 万条的对账 财务对账原来用 crontab + 一个 main 方法跑，失败了从头来，半夜崩了没人管。最惨的一次，任务跑到一半数据库连接断了，已处理的 150 万条没记录，重跑又重复处理了一遍，对账差了几十万。换成 Spring Batch 后，断点续跑和重试才真正可控，凌晨的 job
消费组重平衡，队列堆积了 30 万条 我们一个交易通知服务用 RocketMQ 4.9 做消费，某天上午扩容，新增 2 个消费者实例。按理说扩容应该更快，结果监控上"消费积压"从 0 飙到 30 万条，持续了 20 多分钟才消化完。组员在群里贴了张图："加机器反而更慢了？" 根因在老架构上：Rock
