防御性编程实战：别让对方的“宕机”，变成你的“殉情”

防御性编程实战：别让对方的“宕机”，变成你的“殉情”

在软件开发，尤其是涉及数据同步、第三方接口对接的场景中，我们常听到一句话：“永远不要信任外部系统”。

但在实际代码中，很多程序员却写出了最“轻信”的逻辑。最典型的惨案就是：对方系统（B系统）宕机了一小时，结果你（A系统）把这一小时内积压的 10 万条业务数据，全部标记为“永久失败”，导致数据全毁，需要人工修库。

这就是典型的**“因对方宕机，导致自己数据被刷死”**。今天我们来聊聊，如何通过防御性编程，避免这种“系统级殉情”。

一、 悲剧是如何发生的？（反面教材）

假设你有一个定时任务（Quartz），负责把本地的“档案”推送到“档案局系统”。

❌ 错误的逻辑：一视同仁的“三振出局”

Java

// 这是一个危险的代码逻辑 try { callRemoteSystem(); // 调用远程接口 } catch (Exception e) { retryCount++; // 重试计数 if (retryCount > 3) { // 💀 只要重试3次失败，不管什么原因，直接判死刑 updateStatus("5"); // 5 = 永久失败，不再处理 } }

💣 灾难推演

1. 突发状况：档案局系统的光缆被挖断了，或者服务挂了（HTTP 502/Timeout）。
2. 你的系统：尝试第1次（超时），第2次（超时），第3次（超时）。
3. 判决：重试3次均失败 ->标记为状态 5（永久失败）。
4. 连锁反应：你的定时任务每秒处理一条数据。在对方宕机的 1 小时里，你的代码勤勤恳恳地把3600 条正常的、仅仅是因为连不上网的数据，全部判了死刑。
5. 结局：对方网络恢复了，但你的数据库里全是“5”。你不得不熬夜写 SQL 脚本把它们改回“4”。

这就是防御性编程的反例：由于缺乏对错误的“辨识能力”，将“临时的环境问题”误判为“永久的数据问题”。

二、 核心心法：区分“病”与“伤”

防御性编程的第一条准则：错误分类（Error Classification）。

你必须在代码中精准区分两类错误，并采取截然不同的处理策略：

三、 战术落地：三道防线

第一道防线：异常类型的“精准体检”

不要只catch (Exception e)然后打印一行日志就完了。你需要一个“体检医生”方法，去分析异常的根本原因（Root Cause）。

• 如果是SocketTimeoutException：医生诊断为“由于交通堵塞没赶上车”，建议：下一班车再走（保留状态 4）。
• 如果是NullPointerException：医生诊断为“也没带身份证”，建议：回去拿好了再来，别在车站瞎排队（刷成状态 5，踢出队列）。

Java

// 伪代码：精准判断 if (isNetworkError(e)) { log.warn("路不通，休息一会儿再试"); keepStatus(4); // 保持等待 } else if (isBusinessError(e)) { log.error("数据有毒，剔除！"); updateStatus(5); // 判死刑 }

第二道防线：天然熔断（利用“队头阻塞”）

在单线程或串行任务中，“队头阻塞”（Head-of-Line Blocking）有时反而是保护机制。

• 场景：对方宕机。
• 动作：你的线程卡在第 1 条数据上，重试 -> 失败 -> 休息 -> 重试。
• 效果：虽然第 1 条数据发不出去，但后面的 9999 条数据也没有被处理。
• 结论：这保护了后面的数据没有被错误地标记为“失败”。一旦网络恢复，第 1 条通了，后面的也就都通了。

千万不要在网络故障时，仅仅为了“不卡住”，就快速把当前数据刷成 5 然后去处理下一条。这叫“送死流”处理法。

第三道防线：指数退避（Exponential Backoff）

如果对方系统已经喘不过气了（超时），不要用死循环疯狂重试，那样会变成 DDoS 攻击，把对方彻底打死。

• 第 1 次失败：睡 2 秒。
• 第 2 次失败：睡 4 秒。
• 第 3 次失败：睡 8 秒。
• …

给对方系统喘息的时间，也给自己系统减少无意义的 CPU 空转。

四、 总结：防御性编程的“生存法则”

1. 不轻信：默认外部系统随时会挂，代码要做好“兜底”准备。
2. 不误杀：
   • 断网/超时/宕机=“请稍候”（状态不变，通过日志报警）。
   • 参数空/校验挂=“请回炉”（状态变 5，人工介入）。
3. 不殉情：对方挂了，你就挂起任务休息，千万别把自己的数据池给污染了。

记住：数据状态（Status）的变更必须是神圣的。只有当你 100% 确定这条数据“本身有问题”时，才能宣判它的死刑；否则，请给它一个“死缓”。