Haskell中finally屏蔽异步异常的作用及无mask实现差异问题

问题背景 #

我始终未能透彻理解异步异常的屏蔽（masking）机制。
Control.Exception模块中的finally会对执行动作做异常屏蔽处理，其标准实现源码如下：

a `finally` sequel =
  mask $ \restore -> do
    r <- restore a `onException` sequel
    _ <- sequel
    return r

如果finally内部不做异常屏蔽处理，改为如下无mask的实现会产生什么行为差异？

a `finally` sequel = do
  r <- a `onException` sequel
  _ <- sequel
  return r

理解两者的差异，是掌握异步异常屏蔽机制设计逻辑与实际作用的关键。

核心差异：无mask版本无法保证清理动作sequel一定执行 #

异步异常的核心特性是：其他线程可以在当前线程执行的任意可中断点抛出异常，没有屏蔽保护的前提下，哪怕是do块中两条语句的绑定间隙，都可能被插入异步异常，直接中断后续流程。

无mask实现的致命竞态漏洞 #

很多人误以为Haskell中IO动作的组合是原子的，实际上GHC运行时在每次>>=绑定的位置都设置了异步异常投递点，只要线程不处于mask状态，异常就可以在这些位置打断流程。无mask版本存在明确的无保护窗口期，完全违背finally「无论主逻辑成功或失败，一定执行清理动作」的核心契约：

1. 主逻辑正常结束后的间隙：当主动作a执行成功、返回结果r时，onException挂载的异常处理器会被直接卸载（onException仅在包裹的动作抛出异常时才会触发后续处理）。此时程序刚退出a onException sequel的执行流程，还没来得及运行下一行的_ <- sequel，这个绑定间隙就是可中断点——如果此时有异步异常抛入，线程会直接终止，sequel完全没有执行机会。
2. 异常触发后的间隙：如果主动作a执行时抛出异常，onException需要先执行sequel再重新抛出异常，但在无mask状态下，从异常被捕获到sequel正式启动之间同样存在投递点，异步异常一旦命中，清理动作依然会被跳过。

这个竞态不是理论上的极端场景：高并发服务中如果用无mask版本的finally做文件句柄、数据库连接、锁资源的清理，跑久了必然会出现稳定复现的资源泄漏问题。

带mask的实现如何解决竞态 #

mask的作用不是禁止异步异常，而是暂时阻塞当前线程接收异步异常：被屏蔽期间发来的异步异常不会被丢弃，只会被暂存，直到线程退出mask作用域、或者调用restore恢复异常接收状态时才会投递。
整个finally的组合逻辑全程运行在mask的保护范围内，从根源上消除了内部逻辑的无保护间隙：

• 进入函数首先开启异常屏蔽，保证组合子本身的逻辑（挂载处理器、触发清理动作）不会被异步异常打断。
• 传入restore a执行主逻辑，是为了在主逻辑运行期间恢复正常的异常接收，避免主逻辑全程屏蔽异步异常导致线程没法被正常取消。
• onException运行在mask环境中，只要主逻辑a抛出异常（不管同步还是异步），处理器一定会先触发执行sequel，再向外传递异常。
• 主逻辑正常执行完成后，后续的sequel同样运行在mask保护下，保证清理动作一定会被启动，不会在启动前被异步异常打断。

这里要注意：sequel运行时默认处于屏蔽状态，如果清理逻辑是长耗时操作、需要响应取消信号，需要在sequel内部手动调用restore放开屏蔽——这个设计的核心优先级是保证清理逻辑一定能被触发，而非保证清理逻辑全程不可打断。

异步异常屏蔽的设计本质 #

mask机制从来不是用来让代码完全免疫异步异常的，它的核心作用是消除「异常处理器挂载前、清理动作启动前」的竞态窗口，让开发者可以安全组合异常处理逻辑，实现可靠的资源管理。如果没有mask机制，你根本不可能写出可靠的finally、bracket这类资源安全组合子——无论你把代码写得多么紧凑，两个IO动作之间永远存在可被异步异常插入的间隙，永远没法100%保证清理逻辑被执行。

内容的提问来源于stack exchange，提问作者Tarek Soliman