从 JDK 21 切到 25，同样的服务堆占用降了 19% 我们一个文档问答服务在 JDK 21 上跑了快两年，堆峰值 4.8 GB，一直想降但找不到好办法——该做的代码优化都做了，GC 参数也调过了。 四月份我们把它切到了 JDK 25，只加了一个参数，堆峰值降到 3.9 GB。这个改动是 JEP
给 AI 服务调 JVM，我原来的经验全部失效了 我做 JVM 调优大概六年，给订单、支付、库存这些服务调过不下三十次，形成了一套肌肉记忆：Young 区给 1/3，MaxGCPauseMillis 设 100，开字符串去重，老年代增长超过 50 MB/min 就要警惕。 2025 年下半年开始接
HPA 扩容跟不上流量，问题出在启动要 8 秒 10 月初做了一轮容量压测，暴露了个之前没重视的问题。我们的 AI 网关在 K8s 上配了 HPA，CPU 超过 60% 就扩容。压测时流量从 500 QPS 拉到 3000 QPS，HPA 在 15 秒内触发扩容，但新 Pod 从调度到 Ready
我们的内部知识库 RAG 上线第一周，产品拿了个真实问题测试："年假怎么休？"模型一本正经地答了去年的旧政策。查下来，召回的文档里既有新政策也有旧政策，模型没分清哪个是现行有效的。RAG 的难点从来不在"接上模型"，而在"召回准不准、排得对不对"。 第一板斧：切分策略 最初按固定 500 字符硬切，
我们的一个内部工具服务，部署在 Serverless 上，每次冷启动要 8 秒。函数计费按运行时长，8 秒里一半在"加载类、初始化 Spring 上下文"，用户已经走了。老板问能不能压到 2 秒内，于是有了这次冷启动专项优化。 先量化，再动手 不量就优化是瞎猜。我用 -Xlog:class+load
不想为了监控拖垮生产 之前用 VisualVM 连生产抓采样，JMX 一开 CPU 就飘，GC 行为都变了，抓到的数据还不可信。后来发现 JDK 11 起的 JFR（Java Flight Recorder）开销极低，而且 JDK 14 起的 Event Streaming 能实时订阅事件，不用等
背景：大促前的压测暴露了长尾 八月底大促压测，核心的下单查询接口平均 RT 只有 120ms，看着挺好，但 P99 飙到 800ms，监控里偶发还有 1.5 秒的尖刺。平均好看掩盖了长尾，而用户体验恰恰被那 1% 的慢请求毁掉。我接了这活，目标是把 P99 压到 150ms 以内。 全链路耗时分析：
一次奇怪的吞吐量瓶颈 大促前给订单流水 topic 扩分区，从 12 个加到 48 个，本以为吞吐能线性提升，结果生产端 P99 延迟不降反升，监控上看到 broker 端请求队列开始堆积。翻了半天才意识到：分区数过了拐点就是负担，不是越多越猛。 这事其实之前踩过一次。那回我们是 consumer
压测时 CPU 打满，top 却看不出热点 上个月我们对订单导出服务做容量评估，用 JMeter 打 800 并发。奇怪的是：应用进程 CPU 占用 760%（8 核几乎跑满），但业务代码里我自认为的"重计算"那段——一个金额汇总循环——在抽样栈里占比不到 8%。同事在群里问："你那个汇总到底慢在哪
告警：Pod CPU 987% 10 月 8 号下午，告警： [P1] order-service CPU 使用率 987% (limit 800%) 持续 20 分钟 CPU 是 8 核 limit，987% 意味着快跑满了。接口 P99 从 120 ms 涨到 3.4 秒，部分请求超时。 这类
