从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 第一本很适合开栏：《金钱心理学》（The Psychology of Money），摩根·豪泽尔。 它的核心
为什么我们卡在 JDK 8，却决定直接跳 17 团队基础组件升级评审会上，有人提议"升到 JDK 11 过渡一下"。我投了反对票：既然要动，不如直接到 JDK 17——它是继 8 之后第二个长期支持版本（LTS），2021 年 9 月发布，生态已经足够成熟，而 11 到 17 之间没有第二个 LTS
一个 ES 查询，把节点 CPU 打到了 95% 运营后台有个"订单检索"接口，平时挺快，某天加了"按创建时间排序 + 关键词模糊"后，单查询 CPU 占用飙升，集群一个节点到了 95%，其他查询全被拖慢。我用 profile API 抓了执行计划，发现罪魁是把本该放 filter 的条件写进了 q
GC 选型的争论：Shenandoah 还是 ZGC 我们一个时延敏感的交易网关，之前用 G1，业务高峰 P99 偶尔冲到 400 ms，排查发现是 G1 的 Mixed GC 有 100~200 ms 的停顿。组里就"换哪个低延迟 GC"吵开了：有人挺 Shenandoah，有人挺 ZGC。我干脆
面试被问：REQUIRES_NEW 到底开了几个连接 前阵子面一个五年经验的候选人，我随口问："方法 A 用 REQUIRED 调方法 B，B 用 REQUIRES_NEW，这俩用的是同一个数据库连接吗？"对方答"应该是同一个吧，都在一个事务里"。这其实是个很常见的误解。REQUIRES_NEW 会
冷启动 3 秒，Serverless 上却要等 30 秒 我们的一个图片处理函数被搬上了函数计算（FaaS），按调用计费、闲置回收。问题来了：JVM 冷启动要 3 秒，加上函数平台拉镜像、建实例，一次冷启动用户要等 30 秒以上，体验很差。同事问能不能"像 Go 那样秒起"。我试了 GraalVM
凌晨告警：服务起不来了，日志只有一行 一个深夜，我们的风控服务在发布后反复重启失败。Pod 日志最后一行永远是这句话： java.lang.OutOfMemoryError: unable to create new native thread at java.base/java.lang.
对账发现：账户余额和流水对不上 3 分钱 做交易系统最怕"状态对不上"。我们有个积分账户服务，某天对账脚本报：用户 A 的余额是 1200，但流水累加只有 1199.97。差 3 分钱，谁也说不清是哪笔操作漏了。传统的"改余额 + 插流水"两条写，因为中途异常出现过不一致。痛定思痛，我把核心域改成了
分库分表后，运营要查"跨商家跨库的订单" 我们订单库按 user_id 哈希分了 16 个库、每库 64 张表。单用户的订单查询很顺，因为都在同一个分片。直到运营提了个需求："给我看最近 30 天、金额大于 5000、状态是退款中的所有订单"——这个查询跨了所有库所有表，没有分片键可路由。组员在周会
注册中心抖动，推送延迟到了 8 秒 去年我们把配置中心/注册中心从 Nacos 1.x 升到 2.0，起因是一次线上抖动：一个服务下线，但网关隔了 8 秒才感知到，期间一大波请求打到了已死的实例。翻 Nacos 1.x 的源码才知道，它用的是客户端 10 秒一次 HTTP 轮询去拉变更，服务端有了新
慢查询告警响了，但我不知道是哪条 SQL 有天早上 Prometheus 报了一条 mysql_slow_queries 突增，我登录数据库一查 SHOW PROCESSLIST，满屏都是 Sending data 的查询，根本分不清谁是元凶。那时候我们的慢查询治理还是"出问题了才去看日志"，属于事
一次误删 ConfigMap，让我重新想发布这件事 年初我们还是"人肉发布"：本地打镜像、kubectl set image、改几个 ConfigMap。有次同事手滑把生产环境的 ConfigMap 改错了一个 value，Pod 起来就读不到正确配置，故障持续了 12 分钟。事后复盘，我意识到问题
读源码时的一句注释，让我重新审视响应式 前阵子读 Spring Data R2DBC 的源码，看到 R2dbcEntityTemplate 里一句话："JDBC blocks the calling thread; R2DBC does not." 我当时手头正有个网关服务，Tomcat 的线程池经
消费组重平衡，队列堆积了 30 万条 我们一个交易通知服务用 RocketMQ 4.9 做消费，某天上午扩容，新增 2 个消费者实例。按理说扩容应该更快，结果监控上"消费积压"从 0 飙到 30 万条，持续了 20 多分钟才消化完。组员在群里贴了张图："加机器反而更慢了？" 根因在老架构上：Rock
压测时 CPU 打满，top 却看不出热点 上个月我们对订单导出服务做容量评估，用 JMeter 打 800 并发。奇怪的是：应用进程 CPU 占用 760%（8 核几乎跑满），但业务代码里我自认为的"重计算"那段——一个金额汇总循环——在抽样栈里占比不到 8%。同事在群里问："你那个汇总到底慢在哪
RSS 涨到 5.8 GB，但堆才用了 1.2 GB，也没 OOM 4 月底值班，监控告警：订单服务一个实例的容器内存（RSS）从 2 GB 缓慢涨到 5.8 GB，持续了四天还在涨，但没有抛 OutOfMemoryError。K8s 的内存 limit 是 6 GB，再涨就要被 OOMKilled
