取消、超时与优雅退出：最难的那部分

为什么不能强杀

Java 有过 Thread.stop()。它真的能强行终止一个线程。它在 Java 1.2（1998）就被废弃了，而且是 Java 历史上被废弃得最坚决的一个 API。

// 假设线程正在执行这段代码:
synchronized (account) {
    account.balance -= 100;        // ← 就在这一行的【正后面】被强杀了
    recipient.balance += 100;      // ← 这一行永远不会执行
}
// 结果:
//   1. 100 块钱【凭空消失了】
//   2. 锁被释放了(JVM 会释放),但它保护的数据【已经处于不一致状态】
//   3. 而其他线程会拿到这把锁,然后基于【坏掉的数据】继续工作
//
// 你不是杀死了一个线程。你是【把整个系统的一致性炸了】。

协作式取消的三个环节

取消要真正生效，需要三样东西同时到位。缺任何一个，取消就是个摆设。

「超时」和「取消」不是一回事

这是本章最重要的一节。

// 你以为你做了什么:
ctx, cancel := context.WithTimeout(ctx, 100*time.Millisecond)
defer cancel()
result, err := slowService.Call(ctx)   // 100ms 超时
// 「超时了,我就不等了,快速失败」 ✓

// 你实际上做了什么 —— 取决于 slowService 有没有真的检查 ctx:

// ❌ 弱超时
resp, _ := http.Get(url)                       // 用的是 context.Background()

// ✅ 强超时:ctx 传进 HTTP 请求
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := client.Do(req)     // ctx 取消 → 【socket 真的被关掉】
                                //          → 对端的 TCP 连接断了
                                //          → 对端的 handler 的 r.Context() 也被取消了
                                //          → 【取消一路传到了对端的数据库查询】

// ✅ 数据库也一样
rows, err := db.QueryContext(ctx, "SELECT ...")   // 不是 db.Query!
// PostgreSQL 驱动会真的发一个 CancelRequest 给服务器。

取消之后：清理代码的困境

取消发生了。现在你要清理：关连接、回滚事务、删临时文件。但你已经被取消了 —— 你还能执行代码吗？

suspend fun process() {
    val conn = openConnection()
    try {
        conn.query(...)          // ← 在这里被取消了
    } finally {
        conn.close()             // ✅ finally 会执行
        logCleanup()             // ❌ 如果 logCleanup 是 suspend 的 ——
    }                            //    它会【立刻抛 CancellationException】!
}                                //    因为协程已经处于「取消中」状态,
                                 //    任何新的挂起调用都会立刻失败。

// ✅ 正确:在 NonCancellable 上下文里做需要挂起的清理
suspend fun process() {
    val conn = openConnection()
    try {
        conn.query(...)
    } finally {
        withContext(NonCancellable) {    // ← 「这一段不许被取消」
            conn.closeAsync()             // suspend 的清理,现在能跑完了
            logCleanup()
        }
    }
}

func process(ctx context.Context) error {
    conn := openConnection()
    defer conn.Close()               // ✅ defer 一定会执行

    if err := doWork(ctx); err != nil {
        // ❌ 用已经取消的 ctx 去做清理?那个清理调用会立刻失败。
        // cleanup(ctx)

        // ✅ 用一个【新的、干净的】ctx 做清理
        cleanCtx, cancel := context.WithTimeout(
            context.WithoutCancel(ctx),      // ← Go 1.21+:保留 value,去掉取消
            5*time.Second,
        )
        defer cancel()
        cleanup(cleanCtx)
        return err
    }
    return nil
}

async def process():
    conn = await open_connection()
    try:
        await do_work()
    finally:
        # ❌ 如果已经被取消了,这个 await 会立刻抛 CancelledError
        # await conn.close()

        # ✅ shield 保护清理代码不被取消
        await asyncio.shield(conn.close())
        # 或者更稳:
        # await asyncio.wait_for(asyncio.shield(conn.close()), timeout=5)

三个最常见的「取消被吞掉」

// ❌ runCatching 抓的是 Throwable —— 它会吞掉 CancellationException
val result = runCatching { api.call() }
// 取消信号被吃了。协程「以为自己成功了」,继续往下跑。

// ❌ 同一个坑的另一个面目
try {
    api.call()
} catch (e: Exception) {      // CancellationException 是 Exception 的子类!
    log.error(e)
}

// ✅
try {
    api.call()
} catch (e: CancellationException) {
    throw e                    // ← 先放取消过去
} catch (e: Exception) {
    log.error(e)
}

# Python 3.8 起,CancelledError 继承自 BaseException(不是 Exception)——
# 所以 `except Exception` 【抓不到】它。这是个正确的设计。

# ✅ 这样写是安全的:
try:
    await api.call()
except Exception as e:         # 抓不到 CancelledError,很好
    log.error(e)

# ❌ 但这样就吞了:
try:
    await api.call()
except BaseException:          # ← 抓到了 CancelledError
    log.error("出错")           # ← 而且没有 re-raise

# ✅ 需要清理的话:
try:
    await api.call()
except asyncio.CancelledError:
    await cleanup()
    raise                      # ← 必须重新抛出!

// ❌ 把「被取消」当成普通错误吞掉
result, err := doWork(ctx)
if err != nil {
    log.Warn("失败了,用默认值")     // ← 但如果 err 是 context.Canceled 呢?
    return defaultValue, nil       //    你把「服务正在关闭」当成了「查询失败」
}

// ✅ 区分对待
result, err := doWork(ctx)
if errors.Is(err, context.Canceled) || errors.Is(err, context.DeadlineExceeded) {
    return nil, err                // 取消/超时 → 往上传,不要吞
}
if err != nil {
    log.Warn("真的失败了,用默认值")
    return defaultValue, nil
}

优雅退出：一份完整的清单

服务收到 SIGTERM（K8s 滚动更新、容器重启）后，正确的行为是：

func main() {
    srv := &http.Server{Addr: ":8080", Handler: handler}

    // 监听信号
    ctx, stop := signal.NotifyContext(context.Background(),
        os.Interrupt, syscall.SIGTERM)
    defer stop()

    go func() {
        if err := srv.ListenAndServe(); err != http.ErrServerClosed {
            log.Fatal(err)
        }
    }()

    <-ctx.Done()                    // ← 等 SIGTERM
    log.Info("收到关闭信号,开始优雅退出")

    // 1. 先让健康检查返回 503(让 LB 摘掉我们)
    health.SetNotReady()
    time.Sleep(5 * time.Second)     // ← 给 LB 反应的时间。【这一步经常被忘】

    // 2~4. 停止 accept + 等待在途请求(最多 25 秒)
    shutdownCtx, cancel := context.WithTimeout(context.Background(), 25*time.Second)
    defer cancel()
    if err := srv.Shutdown(shutdownCtx); err != nil {
        log.Error("优雅退出超时,强制关闭", err)
    }

    // 5. 关下游
    db.Close()
    mq.Close()

    // 6. flush
    logger.Sync()
    metrics.Flush()

    log.Info("退出完成")
}

val appScope = CoroutineScope(SupervisorJob() + Dispatchers.Default)

Runtime.getRuntime().addShutdownHook(Thread {
    runBlocking {                        // ← 这是 runBlocking 的正当用途之一
        health.setNotReady()
        delay(5.seconds)                 // 给 LB 时间

        withTimeoutOrNull(25.seconds) {
            appScope.coroutineContext.job.children.forEach { it.join() }
        } ?: log.warn("优雅退出超时")

        appScope.cancel()                // 强制取消剩下的
        db.close()
        logger.flush()
    }
})

下一章：把前面所有的坑集中起来解剖。十种线上并发 bug，每一种都给：症状、成因、复现、修法，以及怎么在 code review 里一眼认出它。