Tokio与Rayon陷阱：为何async/await搞砸并发
The Tokio/Rayon Trap and Why Async/Await Fails Concurrency
async/await让写并发代码变得简单，却把调度复杂性甩给了开发者。在Tokio和Rayon混用的生产环境中，I/O阻塞与CPU密集型任务交织，导致线程卡死、延迟飙升。更糟的是，无界任务队列让系统在流量洪峰中直接OOM崩溃。作者受够了这种“伪简单”，推出了Project Tina——一个基于线程独占、严格限流和确定性调度的并发框架。它拒绝工作窃取，用显式状态机和消息传递换取可预测性。正如作者所言：可预测性胜过简洁性。
async/await让并发代码写得简单，却让系统运行变得复杂。
HN 评论区
61- 有评论者指出 spawn_blocking 的底层线程池过大，若用于纯 CPU 密集型任务会导致线程饥饿，正确做法是将其与 Rayon 线程池配合使用以隔离 IO 与计算负载。
- 一位从业者分享亲历经验，称在 Swift 中因异步任务导致内存泄漏和卡顿，最终不得不回退到经典 GCD 以解决引用计数问题。
- 针对混合 IO 与计算负载的难题，有观点认为不应盲目追求线程数，而应利用 liburing 或 I/O completion ports 实现多路复用，让少量线程高效处理异步 IO。
- 有评论者反驳原文对线程模型的偏见，指出 Erlang 和 Go 的 M:N 调度器在大规模连接场景下表现优异，线程数并非越多越好，关键在于调度策略。
- 多位开发者强调工具选择应基于具体场景而非教条，例如在日志代理中使用 Tokio 以兼容 ZeroMQ，而在计算密集型任务中使用 Rayon 以利用工作窃取机制。