从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 这个栏目不打算做成读书笔记的搬运。我做了八年 Java 和 AI，又自己跑过出海盘子、也清零过两次，读这些书
「下单偶尔失败，刷新一下就好了」 1 月中旬，运营那边反馈：商家后台点"确认收货"有时候会失败，弹一个系统繁忙，再点一次就好了。我们查日志，一天里有 200 多条这样的错： com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException:
「为什么这个 DTO 里的字段改不动了」 1 月底，一个新同事在群里问：他给订单查询的返回 DTO 加了个 @Data，然后用 Jackson 反序列化的时候报了一堆奇怪的错，改成 record 之后就好了，问我能不能把所有 DTO 都换成 record。 我当时的回答是：DTO 可以用，但不是所有
重构一段 140 行的 if-else 链 1 月初接手支付网关的回调处理模块，打开 NotifyDispatcher 一看，是一个 140 行的 if-else 链。我们新服务用的是 JDK 17（ZGC + G1 都在测），正好可以试试新的语法。 原始代码长这样 public NotifyRes
发现：21 点 47 分，Pod 开始被 OOMKilled 2021 年 12 月 28 号晚上，年终大促的预热场。21:47 分监控群开始报： [P1] promotion-service 实例不可用 事件类型：ContainerOOMKilled 命名空间：prod Pod：pro
4.2 G 的 hprof，MAT 自己先 OOM 了 12 月 22 号，营销服务的一个 Pod 因为 java.lang.OutOfMemoryError: Java heap space 挂了。运维在容器被重启前抓到了堆转储，文件大小 4.2 G。我把文件 scp 到本地，双击打开 MAT，进
Code review 时那行 Arrays.asList 12 月底做代码评审，看到一个新同事写的状态判断： private static final List<String> PAID_STATUS = Collections.unmodifiableList( Arrays.a
周五晚上十点，安全组在群里丢了三个 CVE 编号 2021 年 12 月 10 号晚上 22:17，公司安全组群里一条消息，只有三行： CVE-2021-44228 Log4j2 RCE，影响版本 2.0-beta9 至 2.14.1，请各业务线今晚完成自查并反馈。 那时候这个漏洞还没被媒体炒起来，
日志里那句 IllegalMonitorStateException 12 月初，结算服务凌晨报警了几次，错误信息很眼熟： java.lang.IllegalMonitorStateException: attempt to unlock lock, not locked by current th
压测报告里那行 P99 把我叫住了 11 月中旬做双十一前的容量压测，商品详情接口 3000 QPS 下 P99 是 42 ms，还算好看。压到 6000 QPS 的时候 P99 直接跳到 180 ms，而且曲线是锯齿状往上爬，不是平稳的。同时 Redis 集群 CPU 到了 61%，带宽 780
8200 万行的订单表，加个索引要 6 小时 2021 年 2 月，我们的 t_order 表数据量到了 8200 万行，物理大小 68 GB（含索引）。 mysql> SELECT table_name, table_rows, -> ROUND(data_length/1024/10
8200 万行数据，怎么搬到 32 个分片里去 接上一篇。分片规则定好了、ShardingSphere 配好了，接下来的问题是：老库里那 8200 万行数据怎么搬过去，而且不能停服。 这篇文章写的是迁移本身，跟分片设计是两件事，但难度可能更大。 先算停机方案要多久 最省事的做法是挂维护页，导出导入。
升级背景：单核 CPU 打满了 11 月初我们把缓存集群从 Redis 5.0.9 升到了 6.2.5。起因很直接：大促前压测，某个分片的 CPU 到了 92%，但机器是 8 核的——也就是说 Redis 把一个核跑满了，剩下 7 个核在旁边看着。 $ redis-cli -h 10.0.4.11
同事的提问：改成构造器注入就启动失败了 11 月初，组里在推"统一用构造器注入"，小杨改完一个服务发现起不来了： org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with
起因：升级 JDK 11 之后堆少了 500 MB 前面那篇迁移记录里提过，订单服务从 JDK 8 升到 11 之后，稳定态堆占用从 2.6 GB 降到 2.1 GB。我当时只当是 GC 改进的附带效果，直到有同事问"为什么少了这么多"，我才认真去查了一下。 答案主要来自 JEP 254：紧凑字符串
风控服务被 Full GC 拖出的长尾 2021 年 1 月底，风控服务的 P99 突然变差。这个服务是同步调用链路上的一环，上游给的超时是 800 ms，一旦它慢了，整个下单流程都会受影响。 当时的配置：JDK 8u272，8 G 堆，CMS + ParNew。 $ jstat -gcutil 1
