从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 第一本很适合开栏：《金钱心理学》（The Psychology of Money），摩根·豪泽尔。 它的核心
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
升级背景：单核 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：紧凑字符串
现象：堆才用了一半，容器就被 OOMKilled 10 月 28 号晚上，网关服务的一个 Pod 被 K8s 杀了。 $ kubectl describe pod api-gateway-5f8b7c9d4-xt2n9 Last State: Terminated Reason:
现象：翻到第 1000 页要 8 秒 运营反馈"订单列表翻页越往后越慢"。我们复现了一下，第一页 23 ms，第 100 页 340 ms，第 1000 页 8.2 秒。 SQL 长这样（每页 20 条）： SELECT * FROM t_order WHERE user_id = 100372
现象：每次发版，消费停 47 秒 9 月底做容量复盘时，我发现一个奇怪的规律：每次发布，Kafka 消费 lag 都会先涨后落，中间有大约 45 到 60 秒消费完全停住。看消费者日志，那段时间全是这个： 2021-09-28 14:22:31.407 WARN [Consumer client
告警：Pod CPU 987% 10 月 8 号下午，告警： [P1] order-service CPU 使用率 987% (limit 800%) 持续 20 分钟 CPU 是 8 核 limit，987% 意味着快跑满了。接口 P99 从 120 ms 涨到 3.4 秒，部分请求超时。 这类
目标：大促前把商品详情接口压到 8000 QPS 9 月 20 号拿到大促的容量需求：商品详情接口要扛 8000 QPS，P99 控制在 300 ms 以内。第一次压测跑下来只有 2000 QPS，P99 1.2 秒，差了 4 倍。 前后两周五轮优化，最后压到 8200 QPS、P99 178 ms
背景：一个新服务要不要上 WebFlux 9 月中旬要起一个新服务，作用是"详情页聚合"：前端调一次接口，我们并行调商品、库存、价格、营销、评价五个下游，聚合后返回。组里有人提议用 WebFlux，理由是"调用多、IO 密集，响应式最合适"。 我当时持保留态度，就花了一周做了个 POC，两边都实现一
为什么又搞了一套 Prometheus 我们本来有 SkyWalking 8.6，链路追踪和拓扑都挺好用。但它有两个地方不满足需求：一是数据默认只存 7 天（ES 成本摆在那），二是加自定义业务指标比较麻烦，我更习惯"自己埋点 + 自己配告警"这套。 于是给核心的几个服务加了 Prometheus
起因：压测时前 3 分钟的数据全不能看 9 月初给一个轨迹计算服务做压测，用 JMeter 压 10 分钟，发现吞吐曲线很怪：第 1 分钟 3200 QPS，第 3 分钟 7100 QPS，之后稳定在 8900 QPS 左右。同样的机器、同样的并发，吞吐差了 2.8 倍。 这其实就是 JIT 预热的
