Cats Effect 3 Mutex异常行为：替换Console[F]后互斥失效

问题本质 #

你遇到的Mutex失效并非Mutex本身的bug，而是对Async类型类中pure方法的语义理解错误：

• Async[F].pure(a)的参数a是严格求值的——也就是说，a会在构建F[Unit]这个值的瞬间立即执行，完全不依赖F的调度逻辑。
• 失效场景里的Async[F].pure(println(...))，实际上是在创建run方法返回的F[Unit]时就直接执行了println，这些打印操作根本没有进入Mutex锁保护的异步执行流程，自然不会被互斥控制。
• 而正常场景中的Console[F].println是将打印操作封装为F的一部分，只有当F被调度执行（且持有Mutex锁）时才会触发打印，所以能被正确保护。

解决方案 #

要将副作用操作纳入F的异步上下文，必须使用延迟求值的方法，而不是pure：

1. 优先使用Console[F].println（这是Cats Effect推荐的IO打印方式，天然符合F的上下文语义）。
2. 如果需要手动封装同步副作用，使用Async[F].delay(...)或Sync[F].delay(...)——这两个方法会将副作用延迟到F被执行时才触发，而非构建时。

修复后的失效场景代码 #

class Service[F[_]: Async : Console](mutex: Mutex[F]) {
  def run(name: String): F[Unit] =
    for
      _ ← Async[F].delay(println(s"[$name] entered [run] within [${Thread.currentThread().getName}]"))
      _ ← mutex.lock.surround {
        for {
          _ ← Async[F].delay(println(s"[$name] entered [locked] within [${Thread.currentThread().getName}]"))
          _ ← Async[F].sleep(2.seconds)
          _ ← Async[F].delay(println(s"[$name] almost left [locked] within [${Thread.currentThread().getName}]"))
        } yield ()
      }
      _ ← Async[F].delay(println(s"[$name] left [run] within [${Thread.currentThread().getName}]"))
    yield ()
}

或者更规范的写法（继续使用Console[F]）：

class Service[F[_]: Async : Console](mutex: Mutex[F]) {
  def run(name: String): F[Unit] =
    for
      _ ← Console[F].println(s"[$name] entered [run] within [${Thread.currentThread().getName}]")
      _ ← mutex.lock.surround {
        for {
          _ ← Console[F].println(s"[$name] entered [locked] within [${Thread.currentThread().getName}]")
          _ ← Async[F].sleep(2.seconds)
          _ ← Console[F].println(s"[$name] almost left [locked] within [${Thread.currentThread().getName}]")
        } yield ()
      }
      _ ← Console[F].println(s"[$name] left [run] within [${Thread.currentThread().getName}]")
    yield ()
}

关键知识点回顾 #

• pure仅用于封装无副作用的纯值，永远不要用它包裹有IO、打印、状态修改等副作用的操作。
• 所有副作用必须通过delay、Console、IO等方式封装到F的上下文里，确保它们的执行时机受F的调度器和并发控制（如Mutex）管理。

内容的提问来源于stack exchange，提问作者St.