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

> 场景：CronJob 定时备份凌晨没执行 + Job 重试耗尽（K8s v1.25）

场景：CronJob 定时备份凌晨没执行 + Job 重试耗尽（K8s v1.25）路径：kubectl describe cronjob → kubectl get job -o yaml → kubectl get pods 上篇讲了 DaemonSet 优雅终止，核心是通过 PDB 和 pr

Reflection 与 Self-Critique：Agent 的自我纠错能力场景：Agent 输出了一个错误的 SQL 查询——没有人类介入，它自己能发现并修正吗？路径：黑盒 → 入口 → 核心机制 → 三层实现 → 锚点前三篇我们做了三件事：给 Agent 装上了大脑（ReAct 的推理

Plan-then-Execute：让 Agent 先规划再行动场景：ReAct 每一步都做"推理→行动"循环，Token 消耗大、执行慢。Plan-then-Execute 把推理集中到规划阶段，一次性制定完整计划再执行。路径：理解了"规划与执行分离"，你就知道为什么有些场景 Token 可以

ReAct 不是循环——是 LLM 的调试器场景：LLM 能回答问题但无法完成多步任务——ReAct 给 LLM 装上了"思考→行动→验证"的试错循环路径：一个答不出的问题 → 最简实现 → 每轮 Token 账单 → 决策框架 → 一句话锚点上篇我们提到 ReAct 是 Agent 最核心的

第三章总结：三源合流——opencode 为何选扁平不选分层上篇我们跟了错误从 throw 到用户提示的完整路径，这篇跳出单篇视角看第三章的全景。如果你要设计一个 AI Agent 的命令系统——斜杠 /review、MCP 工具 prompt、skill 文件定义的模板——它们来自不同源头，放

ConcurrentHashMap 面试八股 vs 生产环境踩坑实录叙事框架：面试题 → 标准答案验证 → 三个翻车现场 → 边界分析 → 升级版答案上篇讲了线程池参数面试和生产场景的落差，这篇我们来看另一道高频面试题——ConcurrentHashMap。线程安全？标准答案背得滚瓜烂熟，但组合

Dubbo 服务版本管理不善导致灰度失败场景：灰度发布流量全量走到旧版本，新版本 Provider 零流量，registry 机器齐全却路由不到路径：DynamicDirectory.doList() → RouterChain.route() → ConditionRouter.route()

日志凭空消失？Filter 顺序错了——Dubbo 一个 order 值让 ExceptionFilter 成了摆设场景：Provider 端 SecurityFilter 拦截了非法请求，返回了错误——但 ExceptionFilter 没写那行日志路径：ProtocolFilterWrapp

一个 Listener 注册了两次——Dubbo 版本升级把掩盖去掉了场景：Spring Boot 2.1.5 + Dubbo 2.7.6，启动报 BeanDefinitionOverrideException，bean 名称 'dubboBootstrapApplicationListener'

LeastActive 把新节点打满了？Dubbo active 计数的反直觉陷阱场景：三台 Dubbo Provider 配置 LeastActive 负载均衡，灰度重启后新节点 CPU 冲到 90%、流量占 72%，其余两台仅 30% 路径：AbstractClusterInvoker.inv