归档

为什么我们卡在 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 的查询，根本分不清谁是元凶。那时候我们的慢查询治理还是"出问题了才去看日志"，属于事