系统设计 on 止语Lab

冷启动雪崩的三种策略：惰性加载、主动预热、渐进式预热怎么选

Wed, 10 Jun 2026 00:20:40 +0800

缓存服务一重启，数据库 CPU 瞬间 100%。你不是第一个遇到这个问题的人。

这个问题有个专有名词叫"冷启动穿透"——严格来说它和标准的缓存雪崩（大量 key 同时过期或节点宕机）不是一回事，但后果类似：缓存里没有数据，所有请求穿透到数据库。很多人第一反应是"缓存挂了"，其实真正的原因是缓存冷着的时候，你的策略没选对。

选择缓存策略本质上是一道选择题：你的业务能不能接受缓存冷启动时的那几秒"冷"？如果能，最省事的策略就够了；如果不能，你需要付出什么代价来预热。

本文是一篇决策导向的文章，不是操作教程。不教你怎么配 Redis，也不讲缓存穿透/击穿——只聚焦冷启动场景下三种策略的选择问题。

一、先看矩阵：你的系统在哪个象限？

选策略之前，先看两个变量。

第一个是缓存缺失容忍度：你的业务能不能接受缓存冷启动时的"缓存穿透"？

高容忍：CMS、后台管理、数据分析平台
低容忍：秒杀、实时推荐、高并发 API

第二个是数据预热成本：预热需要多少时间和资源？

低成本：热点数据 < 10,000 条，预热耗时 < 10ms
高成本：热点数据 > 100,000 条，预热耗时 > 100ms 或需要大量计算

两个变量组合起来，就是四个象限：

	低成本预热	高成本预热
高容忍度	惰性加载+保护	渐进式预热
低容忍度	主动预热	渐进式预热（或架构优化）

下面逐个拆解每个象限。你可以在读的过程中不断回看这个矩阵，找到自己业务的位置。

二、高容忍 × 低成本：惰性加载 + 保护

大多数团队第一次遇到冷启动穿透时的反应是：加预热。但有时候你不需要预热——你需要的只是一个保护方案。

惰性加载的策略很简单：不预加载任何数据，请求到了才查缓存，缓存没有就去数据库查，查到了再写回缓存。零启动成本，系统重启后立刻可用。代价是第一次请求慢，并发够大时数据库可能被打穿。

但惰性加载最容易被忽视的问题不是"慢"，是雪崩效应。假设你的服务有 50 个实例同时重启，每个实例的缓存都是空的。这时候哪怕只有一个请求打到每个实例上，数据库就要承受 50 倍的瞬时压力。如果用户的请求再密集一些——比如所有实例同时收到 100 个请求——数据库瞬间就面临 5000 个并发查询。

50 倍的放大效应——这就是雪崩。

保护怎么做？

“保护"就是在惰性加载的基础上加一个断路器或限流器：当数据库连接数超过某个阈值时，拒绝后续请求，或者返回降级响应。

常见的保护手段有三种：

连接池限流：设置数据库连接池上限，超过上限的请求排队或超时。简单有效，但排队可能导致请求堆积。
断路器：当数据库错误率达到阈值（比如常见默认值 50%，Hystrix 标准，请根据业务调整），断路器打开，直接返回降级响应，不再请求数据库。这能保护数据库不被完全打垮。
缓存空值：当数据库查询为空时，也把"空结果"缓存起来（设置较短 TTL），避免同一 Key 的反复穿透。

这其实是一个权衡：你是接受少量请求的慢响应，还是接受系统启动的额外延迟？

实测数据

我跑了一组模拟实验，配置如下：10,000 个缓存键，20% 是热点键（占 80% 访问量），50 个并发 worker，总共 10,000 次请求。运行环境：Go 1.26.4，本地单机 Redis，单表简单查询。

结果：

策略	缓存命中率	DB 查询数	DB 峰值连接	平均延迟
惰性加载+保护	61.8%	3,816	50	~3.6ms
主动预热	82.2%	1,778	0	~1.8ms
渐进式预热	82.1%	1,790	1	~1.9ms

惰性加载+保护的命中率只有 62%，DB 峰值连接数冲到 50（模拟的断路器上限），平均延迟接近 3.7ms——比预热方案慢了将近一倍。

但注意：这个数据是在高并发、热点集中的场景下测的。如果你的系统 QPS 很低，惰性加载的表现完全不同——命中率会更高，DB 连接数也不会成为瓶颈。

什么时候选这个象限？

QPS 低：系统日常 QPS < 100，数据库扛得住偶尔的全量穿透
容忍度高：首次访问的几秒延迟对业务无影响（如 CMS、后台管理）
数据量大：全量预热成本太高，且大部分数据可能永远不会被访问
快速迭代：服务频繁重启/发布，没有时间等预热完成

如果你在做一个内部管理系统，用户每天就几十个人用，缓存预热完全是浪费感情。惰性加载 + 一个简单的限流就够用了。

三、低容忍 × 低成本：主动预热

如果你的业务容忍度低——首次访问延迟不可接受，那就主动预热：系统启动时，先把热点数据加载到缓存里。

我的做法是：既然冷启动穿透是因为缓存冷，那就让缓存不冷。提前把预测会被频繁访问的数据加载进去，让系统在对外提供服务前就已经"暖"了。

关键问题：预热什么？

主动预热最核心的问题不是"怎么预热”，而是"预热什么"。加载了不该加载的数据，比不加载更糟糕——浪费内存、拖慢启动。

我一般把预热数据分为两类：

可预测的热点：比如电商系统的商品详情、配置中心的配置项、用户的权限数据——这些几乎 100% 会被访问
统计出来的热点：通过历史访问日志分析出来的高频 Key，比如过去 24 小时 PV Top 1000

第二类有一个陷阱：热点是会变的。昨天的高频 Key 今天可能就冷下来了。所以主动预热通常需要一个"预热 + 定期刷新"的组合方案。热点预测永远有误差。我常用的做法是：对预测的热点设置较短的 TTL，让缓存自己"验证"这个热点是否真的热——如果访问频率低，TTL 过期后自然淘汰。

怎么做定期刷新？两种思路：

定时全量刷新：每 N 分钟重新跑一次热点分析，重新加载热点数据。简单但浪费——热点数据可能没变。
增量监听：监听数据库的变更日志（如 MySQL 的 binlog，可以使用 Canal、Debezium 等成熟 CDC 工具），数据变了才更新缓存。成本高但精准。

大部分团队从定时全量刷新开始就够了——又不是所有数据每秒都在变。

还有一个容易被忽略的问题：预热的数据应该设置什么样的 TTL？

如果你预热的商品详情设置 24 小时 TTL，但商品价格在 2 小时后变了呢？用户看到的价格就是错的。我踩过这个坑之后的做法是：预热数据设置较短的 TTL（比如 5 分钟），同时配合定期刷新来续期。这其实是一个自动降级机制——刷新任务挂了后缓存自动过期，系统退回到惰性加载模式。虽然不是最优状态，但至少不会提供过期数据。

注意：所有预热数据的 TTL 不要设成相同的值。加上随机偏移（比如基础值 ± 随机范围），避免同时过期触发第二次雪崩。

启动时间的账

预热是要花时间的，而且这时间花在"系统启动阶段"——也就是你最希望系统快速上线的时候。

从我的基准测试来看：

预热数据量	耗时	影响评估
1,000 条	~0.5ms	几乎无感
10,000 条	~3ms	可接受
100,000 条	~28ms	启动变慢，但可接受
1,000,000 条	~320ms	已不可忽略

大多数业务场景的热点数据在 1,000-10,000 条这个量级，预热的成本不到 3ms。从这个角度看，主动预热几乎是"免费的"。

但有一个例外：如果你的热点数据是百万级的，320ms 的预热时间在微服务架构中可能触发健康检查的超时。这个场景我会放到后面的"高成本"象限讨论。

怎么实现？

主动预热最常见的实现方式是：在应用启动后、对外提供服务前，执行一个预热函数。

func Warmup(ctx context.Context, redis *redis.Client) error {
    hotKeys, err := loadHotKeys(ctx)
    if err != nil {
        return fmt.Errorf("加载热点列表失败: %w", err)
    }
    
    // 批量写入 Redis
    pipe := redis.Pipeline()
    for _, item := range hotKeys {
        pipe.Set(ctx, item.Key, item.Value, item.TTL)
    }
    _, err = pipe.Exec(ctx)
    if err != nil {
        // 预热允许部分失败，但至少记录日志
        log.Printf("预热部分写入失败: %v", err)
    }
    return nil
}

这段代码在 Spring Boot 中通常放在 @PostConstruct 或 CommandLineRunner 里（注意：Spring Boot 3.x + Java 17+ 需要使用 jakarta.annotation 包），在 Go 中放在 main() 函数中服务启动之前。

注意：如果使用 go Warmup() 异步预热，服务启动时缓存可能尚未就绪。Spring Boot 的 @PostConstruct 默认同步阻塞。两种语言的预热语义不同，需要根据业务决定。

还有一个容易被忽略的问题：预热失败怎么办？ 如果数据库在预热时挂了，预热函数返回错误，你的服务应该拒绝启动，还是先启动再说？

我一般这样区分：对于秒杀系统，缓存没有预热好就上线等于灾难——应该阻止启动。对于一般业务，更合理的做法是：预热失败打印警告，服务继续启动，让惰性加载兜底。

多实例场景的陷阱

50 个实例同时重启，每个都执行一次预热——等于 50 次同样的数据库查询同时打过去。经典解法是使用分布式锁或 leader 选举，只让一个实例执行预热，预热结果共享给其他实例。

如果你的业务已经上了服务发现或配置中心，可以借助这些基础设施来做 leader 预热：启动时先尝试获取分布式锁，拿到锁的实例负责预热，其他实例等待预热完成或直接使用缓存中的现有数据。

什么时候选这个象限？

热点可预测：你知道哪些数据会被频繁访问（比如商品详情、配置项）
容忍度低：首次访问延迟不可接受（比如秒杀系统、实时推荐）
数据量适中：热点数据量 < 100,000 条，预热成本可控
服务重启不频繁：每次重启都做一次预热，启动频率越低越划算

四、高容忍 × 高成本：渐进式预热

主动预热的前提是你"知道"热点是什么。但如果热点不确定呢？

比如你做的是一个社交 Feed 系统，每个用户看到的内容都不一样。你没法提前知道"哪个用户的 Feed 会被访问最多"，因为热点完全取决于用户行为。

这时候主动预热没用——你不可能预热所有用户的 Feed。惰性加载+保护又太被动——用户量大，首次访问的延迟会拉低整体体验。

渐进式预热就是第三种选择：先让系统起来，然后边服务边预热。

这听起来像是"两全其美"，但它有一个隐含的代价：预热期间，部分请求仍然会穿透到数据库。渐进式预热不是在"要不要穿透"之间选，而是在"穿透多少"和"等待多久"之间找平衡点。

怎么做？

渐进式预热的做法是：系统启动后立即开始分批加载热点数据，同时用限流/断路器保护数据库。和主动预热的关键区别在于：服务不需要等预热完成再启动。

func GradualWarmup(ctx context.Context, redis *redis.Client) {
    // 使用游标分页加载，避免一次性加载全部热点到内存
    var cursor int64
    batchSize := 100
    
    for {
        hotKeys, nextCursor, err := loadHotKeysPage(ctx, cursor, batchSize)
        if err != nil {
            log.Printf("分批加载热点失败: %v", err)
            break
        }
        
        // 每批写入 Redis
        pipe := redis.Pipeline()
        for _, item := range hotKeys {
            pipe.Set(ctx, item.Key, item.Value, item.TTL)
        }
        _, err = pipe.Exec(ctx)
        if err != nil {
            log.Printf("预热部分写入失败: %v", err)
        }
        
        // 每批之间间隔 200ms，给数据库喘息空间
        time.Sleep(200 * time.Millisecond)
        
        if nextCursor == 0 {
            break
        }
        cursor = nextCursor
    }
}

关键参数是 batchSize 和批间隔。batchSize 太大等于全量预热，太小又预热太慢。我的建议是从 100 开始，根据预热期间数据库的负载动态调整。

从我的模拟实验来看，渐进式预热的表现和主动预热非常接近：命中率 82.1%，DB 峰值连接只有 1。

它和主动预热的核心差异不是性能，是灵活性：

主动预热：启动时一次加载完，之后就不管了
渐进式预热：持续加载，可以动态调整预热策略

比如，你可以根据预热期间的缓存命中率来动态调整：如果命中率已经超过 90%，可以放慢预热速度甚至停止；如果命中率仍然很低，加快预热速度。

和主动预热怎么选？

如果你的热点是明确的、稳定的，选主动预热就够了，不需要渐进式的复杂性。只有在你不确定或者数据量大到一次加载不完的时候，渐进式预热才值得。

我常用的判断标准：如果预热耗时超过服务启动时间的 20%，就该考虑渐进式预热了。

什么时候选这个象限？

热点不确定：你不知道哪些数据会被频繁访问
数据量大：全量预热会显著拖慢启动（百万级以上）
需要持续更新：热点数据会随时间变化，需要持续加载
高可用要求：不能因为预热而延迟服务启动

五、低容忍 × 高成本：最棘手的象限

如果你的业务既对延迟敏感（低容忍），又需要预热大量数据（高成本），矩阵的右下角——这是最难的场景。

矩阵上说"渐进式预热（或架构优化）"。我来展开"架构优化"是什么意思。

这个象限的核心矛盾是：系统启动必须快，但缓存又不能不预热。渐进式预热可以缓解这个问题——服务先起来，边服务边预热——但预热期间仍然会有部分请求穿透到数据库，低容忍度的业务可能接受不了。

这时候有两条路：

第一条路：本地缓存 + 预热拆分 在应用层加一层本地缓存（如 Go 的 sync.Map、Java 的 Caffeine），热点数据优先从本地缓存读取。预热只预热 Redis 这一层，本地缓存靠惰性加载。启动速度几乎不受影响，本地缓存命中率在预热完成后自然下降。代价是多了一层缓存一致性要维护。

第二条路：重新评估缓存必要性 有时候"低容忍 + 高成本"意味着你的架构选型有问题——缓存不是最好的解决方案。比如可以考虑：

数据分片：把一个大 Redis 拆成多个，每个分片的数据量变小，预热成本自然降低
读写分离：读走从库、写走主库，减少缓存的压力
换个思路：是否可以用 CDN 或预计算来代替缓存？

六、决策树：三步走到答案

如果上面四个象限看完还是不确定，走这个流程：

你的业务能接受缓存冷启动吗？
- 能 → 惰性加载+保护就够了（回到高容忍×低成本）
- 不能 → 进入下一步
你知道热点数据是什么吗？
- 知道 → 主动预热（低容忍×低成本）
- 不知道 → 进入下一步
预热会拖慢启动吗？
- 不会 → 主动预热（即使用统计出来的热点也值得）
- 会 → 渐进式预热（高容忍×高成本或低容忍×高成本）

这个决策树覆盖了大多数场景。如果你走到第三层还是不确定，说明你的场景比较特殊——可能根本不需要缓存，或者需要重新考虑架构。

比如有些场景下缓存 Key 设计不合理，大部分请求都集中在少数 Key 上——这时候与其纠结预热策略，不如先看看缓存的设计是否合理。

矩阵之外：什么时候不该用缓存？

最后说一个反直觉的结论：有时候不做缓存，比做缓存好。

如果你的数据库本身响应就很快（比如单表百万级的 PostgreSQL，简单主键查询场景），缓存引入的复杂性可能得不偿失。缓存预热、缓存一致性、缓存穿透——这些问题的维护成本，可能超过缓存带来的性能收益。

我的判断标准：如果数据库 P99 延迟 < 5ms，且 QPS < 1000，先别急着加缓存（注意：这只是简单查询场景的参考值，复杂 JOIN 或高并发下 P99 远不止 5ms）。先看看慢查询能不能优化。缓存是用来解决"优化解决不了的问题"的，不是用来掩盖设计缺陷的。

还有一点：加了缓存不等于加了预热。很多团队上了 Redis 但没做预热，结果上线第一天缓存是空的，数据库被打穿。如果你决定用缓存，至少要确保惰性加载+保护这一层兜底是到位的。先让它不崩，再考虑怎么让它快。

我见过一个案例：一个日活百万的 App，缓存集群重启后数据库直接被冲垮，DBA 紧急扩容才恢复。事后排查发现，他们根本没有缓存缺失的保护机制——Redis 一重启，数据库就裸奔。加一个简单的限流，整个事故就能避免。

回到那个矩阵

没有银弹。选对策略比选对工具重要。

大多数团队遇到冷启动穿透的第一反应是"加预热"——这没错，但问一句"我的场景真的需要预热吗"往往更值钱。

回到开头的那个矩阵：你的业务在哪个象限？

高容忍 × 低成本 → 惰性加载+保护，省掉预热的运维成本
低容忍 × 低成本 → 主动预热，命中率最高
高容忍 × 高成本 → 渐进式预热，在灵活性和安全感之间找到平衡
低容忍 × 高成本 → 渐进式预热（或重新考虑架构）

你的业务对"冷"有多敏感？

下次遇到缓存重启后数据库 CPU 100% 的问题，先问自己三个问题：我的业务能忍多久？我知道热点在哪吗？预热会影响启动吗？问清楚了，方案自然就出来了。

原文发布于止语Lab

并发模型三流派：CSP / Actor / 线程

Sat, 30 May 2026 11:03:55 +0800

很多并发模型比较，问的是"谁更先进"。这篇换个问法：状态归谁，等待归谁，失败归谁。

很多文章讲并发模型，喜欢从一个大表开始：线程、协程、Actor、CSP、async/await，各自一列，优缺点排开。

这种写法看起来完整，但读完很容易只记住几个标签：Go 是 CSP，Erlang 是 Actor，Java 是线程。

问题就在这里。

真实工程里，你不会因为一个模型"更先进"就选它。你真正关心的是：这段并发代码出了问题以后，我该去哪里看？谁能改状态？谁在等？谁接住失败？

这篇不做先进性排名。但"不排名"不等于"三种模型完全等价"——某些场景客观偏好某种模型，电信级长连接和毫秒级故障转移下 Actor 有结构性优势。本文反对的是脱离场景的抽象排名，不是反对场景化判断。

我会用同一个任务编排器，把 Go、Erlang、Java 三种心智模型放在同一张白板上看。不是看语法谁漂亮，而是看三件事：

状态归谁：谁拥有结果，谁能修改，谁负责一致性。
等待归谁：阻塞、超时、取消、背压由谁表达。
失败归谁：一个子任务失败后，错误被关在哪里，谁决定恢复或扩散。

这三个问题，比"CSP / Actor / 线程谁好"更接近工程现场。

1. 先固定一个任务：聚合三个下游

先别急着下定义。

想象一个用户画像接口。它要同时请求三个下游：

profile：基础资料，通常很快。
billing：付费状态，偶尔返回业务错误。
risk：风控标签，偶尔超时。

聚合层要做的事也很普通：并发发起请求，等结果回来，组装成一个响应。如果某个下游超时，不能让整个请求无限挂着；如果某个下游明确失败，要决定其他任务还要不要继续跑。

这个小场景写了三份最小实现：

语言 / 风格	实现路径	运行场景
Go / CSP 风格	`goroutine + channel + context`	success、timeout、worker-error
Java / virtual thread	`virtual thread + Future/CompletionService`	success、timeout、worker-error
Erlang / Actor 风格	`process + message + link/EXIT`	success、timeout、worker-error

代码不测性能。这里没有 QPS，也没有延迟排名。

这么做是有意的。并发模型讨论很容易被性能数字带偏：哪个更快、哪个开销更低、哪个能撑更多连接。这些问题当然重要，但不是这篇要解决的事。此场景偏短生命周期聚合，Actor 的长生命周期优势未覆盖——边界先放这里。

一个模型性能再好，如果团队不知道失败以后谁来收场，它还是会在生产环境里变成黑盒。反过来，一个模型看起来不够"酷"，但责任边界清楚，排障时反而更省命。

技术选型最后比的，往往是事故发生时谁能最快定位、最快止血，谁能避免下一次复发。

只看一件事：同一个工程任务，在不同模型里，责任被放到了哪里。

并发模型最容易被讲成抽象概念。但工程师真正付出的成本，通常不在"能不能并发"，而在"并发以后谁负责收尾"。

下面进入三问。

2. 第一问：状态归谁

先看状态。

这个任务里，状态主要是"已经拿到了哪些下游结果"。它看起来只是一个结果集合，但并发一上来，问题就变了：多个任务能不能同时改它？如果能，谁保证一致性？如果不能，结果怎么汇合？

Go 的写法很典型。

Go 版本里，每个 worker goroutine 不直接修改聚合结果。它只把一个不可变的 Result 发到 channel。真正持有结果列表的是聚合 goroutine——社区惯用 errgroup 进一步封装这个模式。

实验输出里，这个观察写成一句话：

场景	状态所有权观察
Go success / timeout / worker-error	`aggregator goroutine owns the result slice; workers only send immutable Result values`

翻译成人话就是：worker 只交信封，不改账本。账本在聚合者手里。

这就是 Go 偏 CSP 心智模型的好处。它鼓励你把协作关系写到通信结构里。channel 不只是传值，它也在暗示：谁能说话，谁能接收，谁能关闭这条路。

但这里要补一条边界。

Go 不是"无共享状态语言"。Go 项目里 mutex、atomic、WaitGroup、context 到处都是。把 Go 写成"只能 channel"是误导。更准确的说法是：Go 的默认心智模型鼓励你先问，能不能通过通信把状态所有权收束起来；如果收不住，再用锁和原子操作。

Erlang 的状态边界更硬一点。

在 Actor 风格里，每个 process 天然拥有自己的局部状态。外部不能直接伸手改它，只能发消息影响它。Erlang 实验里，worker process 完成后给 parent 发消息，parent 负责聚合。

输出里是这样：

场景	状态所有权观察
Erlang success / timeout / worker-error	`each process owns its local state; parent aggregates only messages`

这个表达很 Actor：实体先存在，通信再发生。

CSP 更像"我关心通道和协作关系"；Actor 更像"我关心实体和边界"。两者都是消息传递，但重心不同。CSP 的问题常常是"这条通信路径怎么设计"；Actor 的问题常常是"这个状态属于哪个实体"。

Java virtual thread 的位置又不一样。

virtual thread 不会替你决定状态归谁。它解决的是阻塞线程的开销问题，共享状态如何保证一致性，仍然是应用层需要自己设计的。

Java 实验里，聚合状态仍然是调用方普通对象和集合。virtual thread 让每个子任务可以继续写成同步阻塞代码，但它没有把共享状态变成私有状态，也不会自动给你 Actor 边界。

输出里故意写得很直白：

场景	状态所有权观察
Java success / timeout / worker-error	`caller keeps aggregation state in ordinary objects; virtual threads do not change shared-state semantics`

这句话可以放进正文里反复提醒自己：virtual thread 改变了等待成本，但没有改变状态语义。

第一问的答案大概是：

Go 倾向于让状态通过通信汇聚。
Erlang 倾向于让状态先属于一个 process。
Java virtual thread 让你保留熟悉的对象和调用栈，但状态边界仍要自己设计。

先别急着分高下。我们只看第一类责任：状态到底放在谁手里。

3. 第二问：等待归谁

并发代码第二个麻烦是等待。

你发出三个下游请求，不可能一直等。risk 慢了怎么办？整体超时谁说了算？已经成功的结果要不要保留？还没结束的任务谁去取消？

先看边界感最强的方案。

Erlang 的等待像 mailbox 里的时间边界。Erlang 版本用 parent process 收 worker 消息，receive ... after 定义整体等待时间。risk 超时后，parent 杀掉还没完成的 worker。

erlang-timeout 的输出是：

字段	输出
completed	`[billing,profile]`
canceled	`[risk]`
error	`timeout`

Actor 风格的等待不是"共享一个 context"，而是"某个 process 在等消息"。这会改变排查入口。你会去看 mailbox、process 状态、消息有没有堆积，而不是先看某个共享取消对象。

Go 的等待关系通常更显眼一些。

在实验里，整体超时由 context.WithTimeout 定义。worker 里用 select 同时等两个东西：自己的模拟耗时，或者 ctx.Done()。聚合者看到第一个错误后调用 cancel()，兄弟 goroutine 通过同一个 context 收到取消。

go-timeout 的输出是：

字段	输出
completed	`[billing profile]`
canceled	`[risk]`
error	`risk canceled: context deadline exceeded`

你能从这组输出里看到 Go 的风格：等待和取消不是藏在运行时深处，而是直接写在应用编排代码里。

这也是 Go 并发代码读起来有时"啰嗦"的原因。你要传 context，要处理 channel，要决定谁 close，要防止 goroutine 泄漏。它不替你消失这些问题。它只是把问题摆在桌面上。

Java virtual thread 的等待最容易被误解。

很多人听到 virtual thread，会以为 Java 的并发模型就变成了另一种东西。其实没有。virtual thread 的关键价值是：你可以继续写看起来同步的阻塞代码，而不会像平台线程那样为每个阻塞请求付出昂贵资源成本。

Java 版本用 Executors.newVirtualThreadPerTaskExecutor() 提交任务，再用 CompletionService 等结果。代码仍然是 Future 编排：谁超时，谁取消，谁收错误，都由应用层决定。

java-timeout 的输出是：

字段	输出
completed	`[billing, profile]`
canceled	`[risk]`
error	`overall timeout after 70ms`

这说明 virtual thread 主要解决"等待能不能便宜一点"。至于等待语义怎么设计，还得回到应用编排。

把这三种模型放在一起，第二问会变得很清楚：

Erlang 把等待写成 parent process 对 mailbox 的接收边界。
Go 把等待和取消写成 context/select/channel 的协作协议。
Java virtual thread 把等待保留在同步调用栈里，让 JVM 承接更多阻塞成本，但取消策略仍在应用层。

不要只问"哪个模型更适合高并发"。先问：你的团队更想在代码哪里看到等待？process 边界里，通信结构里，还是同步调用栈里？

4. 第三问：失败归谁

状态和等待还只是开胃菜。并发模型真正拉开差距的地方，是失败。

因为并发系统里，失败不是一个点。一个子任务失败以后，至少有三个问题跟着来：

失败先被谁看到？
兄弟任务要不要取消？
这个失败会不会越过当前边界，影响更上层？

实验里加了两个失败场景：

timeout：risk 比整体超时更慢。
worker-error：billing 明确返回错误。

Go 的 worker-error 输出是：

字段	输出
completed	`[profile]`
failed	`[billing]`
canceled	`[risk]`
error	`billing returned error`

这里的失败边界很应用化。billing 出错后，聚合者调用 cancel()，risk 通过 context 退出。Go 没有一个"自动监督者"替你决定失败传播。你要把传播路径写出来。

很多业务系统正需要这种显式控制。

代价也在这里：如果你忘了传 context，忘了监听取消，忘了 drain channel，失败边界就会变成泄漏边界。Go 的并发事故里，goroutine 泄漏经常不是因为 goroutine 这个概念复杂，而是因为退出条件没有被完整表达。

Erlang 的失败更像"边界先存在"。

最小 Erlang 实验里，worker 用 spawn_link 启动——注意 parent 需要先 process_flag(trap_exit, true) 才能把 EXIT 信号转为可处理消息，否则会被级联终止。billing 失败时，parent 收到 EXIT 信号，然后 kill 兄弟 process。

输出是：

字段	输出
completed	`[profile]`
failed	`[billing]`
canceled	`[risk]`
error	`{task_error,billing}`

这当然还不是完整 OTP supervision。真正的 Erlang 工程会有 supervision tree、restart strategy、monitor 等更完整的设计。这里补一个关键区分：link 是双向的（一方死另一方跟着死），monitor 是单向的（只收通知，自己不死）。supervision tree 大量依赖 monitor 来实现"观察而不殉葬"。

但即使在这个最小实验里，你也能看到 Actor 心智模型的味道：失败是 process 边界上的信号，不只是一个返回值。一个实体死了，另一个实体可以观察到它的死亡，并决定下一步。

Java virtual thread 的失败边界则更接近传统线程模型，只是线程变轻了。

java-worker-error 的输出是：

字段	输出
completed	`[profile]`
failed	`[billing returned error]`
canceled	`[risk]`
error	`billing returned error`

这里的失败处理仍然靠应用编排 Future：捕获 ExecutionException，记录第一个错误，取消未完成任务。

Java 对"兄弟任务收束"这个问题已经给出了官方答案：StructuredTaskScope（JEP 480，已正式进入 JDK）。它的设计思路是把一组子任务绑进同一个作用域，作用域退出时所有子任务必须结束——要么全成功，要么第一个失败触发其余取消。最小示例：

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    Subtask<String> profile = scope.fork(() -> fetchProfile());
    Subtask<String> billing = scope.fork(() -> fetchBilling());
    Subtask<String> risk    = scope.fork(() -> fetchRisk());
    scope.join();           // 等待全部完成或第一个失败
    scope.throwIfFailed();  // 有失败则抛出
    return new Result(profile.get(), billing.get(), risk.get());
}
// scope 关闭时，未完成的子任务被自动取消

这比手动 Future 编排清晰不少——失败边界直接写在语法结构里。不过 StructuredTaskScope 的 API 仍在演进（自定义策略、嵌套作用域等场景还有边界），它尚未覆盖 supervision tree 那种"长期实体+重启策略"的场景。

到这里，第三问的差异就出来了：

Go：失败边界是应用协议，靠 context、channel、错误处理约定串起来。
Erlang：失败边界是 process 语义的一部分，link/monitor/supervision 让失败可观察、可隔离、可恢复。
Java：失败从手动 Future 编排走向 StructuredTaskScope 的作用域收束；线程变轻，失败策略正在被语法化。

当三种模型都有明确的责任位置时，争论"谁更先进"反而显得多余。真正的差异在于：失败信号沿着什么路径传播，传播到哪里停下来。

Actor 的核心设计选择，是把状态和失败一起包进实体边界里。这让它在长生命周期、需要隔离和恢复的场景下有天然优势。

5. 一个辅助观察：责任在代码表面的分布密度

为了避免只凭感觉，还做了一个粗略的辅助观察。

方法很简单：对三份实验源码做关键词扫描，粗略统计"状态/聚合"“等待/调度"“失败/取消"三类责任关键词在代码里出现的相对密度。这只是一个粗略代理指标，不是性能比较，也不是可维护性评分——它只反映一个现象：代码表面上，你的注意力会被拉向哪个方向。

观察结果：

Go 代码里，等待和取消关键词（context、cancel、select、Done）分布最密集——你很容易看到协作痕迹。
Erlang 代码里，失败边界关键词（EXIT、link、kill、trap_exit）占比最高——process 边界和信号非常显眼。
Java 代码里，三类关键词分布相对均匀，状态管理稍密——同步写法保留，取消仍在 Future 编排层。

这个观察不能推出"Go 代码更复杂"或"Erlang 失败处理最好”。它能说明的只是：三种模型会把你注意力拉向不同地方。

模型	写代码前先问
Go	取消路径写完整了吗？
Java virtual thread	同步写法背后的失败收束写清楚了吗？
Erlang / Actor	实体边界和观察关系设计清楚了吗？

模型不会替你收拾现场。它只是让某些责任更容易被看见，另一些责任必须靠你自己补上。

6. 反例：别把语言等同于模型

专业读者可能已经想反驳了：

Go 也能用锁啊。Java 也能写 Actor。Erlang 也不只是 mailbox。

这些反驳都对。

这篇文章从头到尾比较的是"默认心智模型”，不是"语言能力上限"。

语言像工具箱，默认心智模型像你最顺手拿起来的那把工具。Go 的工具箱里当然有锁和原子操作，但 goroutine、channel、context 会不断提醒你：协作关系能不能显式写出来？

Java 的工具箱越来越大。virtual thread 让 thread-per-request 这种老写法重新变得可承受，但它并不会自动替你做状态隔离。你仍然要设计对象边界、取消策略、错误传播。

Erlang 的工具箱也不只是"发消息"。如果只把 Erlang 当成 mailbox，你会错过它的核心设计：进程边界、失败信号、监督关系，以及"让它崩溃"背后的恢复语义。

更准确的说法是：

Go 不是 CSP 的纯实现，但它偏向用通信结构组织并发。
Erlang 不只是 Actor 消息队列，但它偏向用实体边界组织状态和失败。
Java 不等于传统重线程；virtual thread 让同步线程模型在高并发 I/O 下重新有吸引力。

一旦你接受这个边界，争论就会少很多。

给语言贴标签已经够多了。真正要问的是：同一个问题，用哪套责任分配方式更容易写对、读懂、排查。

7. 最后给一张速查表

如果你在设计一个并发模块，不要先问"我该用 CSP、Actor 还是线程"。

先问三句：

状态归谁？
等待归谁？
失败归谁？

然后再看场景。

场景信号	更该关注的问题	倾向的表达方式
多个 I/O 下游并发等待，取消关系复杂	等待归谁，取消怎么传播	Go channel/context，或 Java virtual thread + 明确 Future 编排
每个实体有长期状态和独立生命周期	状态归谁，失败被关在哪里	Actor/process 边界
团队强依赖同步调用栈可读性	能否保留顺序代码，同时降低等待成本	Java virtual thread
失败恢复比吞吐更重要	谁观察失败，谁负责重启/隔离	Erlang/Actor supervision 思路
状态集中且需要严格共享一致性	谁能改状态，锁或事务在哪里	线程 + 显式同步，或重新拆分状态所有权

这张表不是标准答案。它只是把"模型选择"翻译成"责任选择"，让讨论别一上来就变成语言站队。

下次看到并发模型争论时，先别急着站队。

有人说 channel 优雅，你就问：状态归谁？

有人说 Actor 才可靠，你就问：失败归谁？

能把这三件事回答清楚，模型名字反而没那么神秘。

CSP、Actor、线程的区别，在于把状态、等待和失败交给不同的角色负责。

工程里最怕的，不是三种模型给出了不同答案。

是这三个问题，从头到尾没人问过。

原文发布于止语Lab