Ai拆代码的曹操 - Java性能调优·线上问题排查

Nginx Content-Length 与实际 body 不匹配导致 upstream keepalive 池中毒与连接泄漏

Nginx Content-Length 与实际 body 不匹配导致 upstream keepalive 池中毒与连接泄漏场景：Nginx 反代部分请求 502 / body 错乱 / 上游报"invalid header field" | 路径：tcpdump → keepalive 连接请

两端连接都是 ESTABLISHED，中间层却悄悄断了——conntrack 超时引发 RST

两端连接都是 ESTABLISHED，中间层却悄悄断了——conntrack 超时引发 RST 场景：连接空闲 30 分钟后复用报错 | 路径：ss → tcpdump → conntrack → sysctl 上篇我们分析了 TCP RST 包的常见原因——端口未监听、防火墙拦截、应用层主动关闭。

GROUP BY 查询性能骤降的根因分析

GROUP BY 查询性能骤降的根因分析场景：月度 Top 消费用户查询从 0.12 秒变 4.7 秒，加了索引也没用路径：EXPLAIN → Using temporary → 临时表磁盘溢出 → 组合覆盖索引上篇讲了索引失效的 10 种场景，这次我们来看一个更隐蔽的坑——索引没失效，查询照

RocketMQ 消息堆积了怎么办？从消费者源码到 OS 层排查

RocketMQ 消息堆积了怎么办？从消费者源码到 OS 层排查场景：业务端到端耗时从 200ms 涨到 5s，消息堆积 50 万条。业务方怀疑生产者慢，链路追踪发现消费端才是根因——20 个消费者线程全部卡在同步 DB 写入上，形成 rebalance 死亡螺旋路径：消费 lag 监控 → 消

一行代码导致 RocketMQ 大量消息发送失败

一行代码导致 RocketMQ 大量消息发送失败场景：订单服务灰度上线，消息发送成功率骤降 0%，Broker 端一切正常路径：应用日志 → 端口特征 → 网络排查 → 源码追查本文所有日志时间已统一到 UTC+8 上篇我们分析了 RocketMQ Broker 高负载下的 SYSTEM_BU

CMS GC 频繁 promotion failed 排查

CMS GC 频繁 promotion failed 排查场景：6GB 堆的订单服务持续 promotion failed，调大堆后次数反而翻倍。路径：GC 日志定位 → 碎片化/并发周期跟不上的双根因判断 → CMS 参数微调方案 → 迁移 G1/ZGC 的长期路径上篇讲了 Metaspac

ScheduledThreadPoolExecutor 定时任务未按时执行排查

ScheduledThreadPoolExecutor 定时任务未按时执行排查场景：每 5 秒执行一次的定时任务，实际间隔变成了 8 秒、15 秒、30 秒——越来越慢路径：检查执行时间 → 区分 fixedRate vs fixedDelay → 验证异常处理 → 监控线程池状态上篇讲了核心

核心线程数设错了：过大引发资源竞争、过小导致队列积压

核心线程数设错了：过大引发资源竞争、过小导致队列积压场景：8C16G 容器，线程池 200 个核心线程，CPU 50% 但 P99 延迟从 50ms 涨到 800ms 路径：判断任务类型 → 公式计算 → 压测验证 → 持续监控上篇讲了拒绝策略选型失误导致任务静默丢失，这篇我们来看线程池配置里另

上篇我们深入了 project/workspace 管理——当一切正常时，opencode 如何组织工作单元。这篇来看另一面：当出问题时，一条错误从源码到用户终端的完整链路。

上篇我们深入了 project/workspace 管理——当一切正常时，opencode 如何组织工作单元。这篇来看另一面：当出问题时，一条错误从源码到用户终端的完整链路。如果你要设计一个 AI Agent 的错误处理——模型超时、配置格式错、权限不足、插件崩溃——你会怎么组织？一个直观的想法是

project/workspace 管理：工作单元的组织方式

project/workspace 管理：工作单元的组织方式场景：Agent 打开一个目录就开始工作了——但 opencode 怎么知道这是个什么项目、是不是 git 仓库、之前有没有 session？路径：packages/opencode/src/project/ → instance-co