从马拉松百公里越野赛看业务代码的中断能力

在 一文中老吕谈到了业务代码的中断能力，有人问了，什么情况下需要接口方法具备中断能力，我们平时听到更多的是“取消任务”、“中断任务”，没错，老吕认为 在任务调度接口、异步任务和重接口中最好预留中断的能力，便于及时终止错误的操作，错误的指令，减少损失，否则你可能只能拉闸断电了。

马拉松百公里越野赛，我们把选手看做CPU，100公里的赛道就是任务(代码指令)，CPU（选手）跑完所有指令（赛道）才算成功完成任务，选手跑起来（CPU运行指令）就形成了线程，各个CP点都有一个显示器，上面可以显示是否终止比赛的信息（中断信号），选手过CP点时都会看大屏幕信息，赛事组委会（程序员）可以根据情况选择是否发送终止比赛的信号（中断信号.()），赛事组委会向各个选手发送中断信号后，CP点显示屏上就会出现中断信号信息。

任务在没有CP点（不检查中断信号）的情况下，选手就是一旦从起点出发，就像脱缰的野马，一发不可收拾，根本无法让他停下来，哪怕道路崎岖，环境险恶。

在有CP点的情况下，选手每过一个CP点都会看下大屏幕，有没有中断信号，看到中断信号后是否继续比赛，不过决定权还是在选手手里，选手可以无视中断信号，继续跑下去，也可以选择终止比赛，打道回府，减少损失。

可能有的选手觉得组委会比较扯淡，我觉得能跑完，我就是想跑完，我不怕环境恶劣，我不理你的中断信号，继续向下一个CP点出发。组委会综合评估后觉得恶劣天气对选手伤害很大，绝对不能再比赛了，就使出了杀手锏（.stop（））,强行把跑道拆了。

所以说在一个重接口或者由多个阶段组成的异步任务中，我们的业务代码中最好设置 CP点，检查并且重视中断信号

（.().()？），这样在某些情况下可以及时止损。