14 篇博文 含有标签「并发编程」

并发设计的第一步不是 go func()，而是知道工作在等待什么、占用什么，以及允许多少工作同时存在。

本期建立全系列的成本模型：CPU 密集、网络 I/O、同步阻塞和排队分别如何影响 Go runtime，并把目标 RPS 转成 goroutine、连接和内存预算。

创建 goroutine 的代码，也必须能说明谁等待它、谁取消它、它什么时候退出。

本期把 goroutine 从语法糖升级为受管理的生命周期。我们实现两种核心结构：请求内 fan-out/fan-in，以及跨请求的有界 worker pool。

Handler 只是入口；生产并发的真正边界位于连接池、下游 deadline、响应体和停机协议。

本期把前两期的容量与生命周期原则落到 net/http 服务，完成一个有界高扇出聚合 API。

零拒绝不是稳定性目标。系统超过容量时，及时拒绝一部分请求，才能保护已接纳请求和故障恢复能力。

本期专门处理“流量大于处理能力”。我们把限速、限并发、队列、重试和熔断放进同一个反馈系统，而不是堆叠互不理解的中间件。

并发安全不是“没有 concurrent map panic”，而是所有共享状态的不变量在任意合法交错下都成立。

本期建立同步原语的选择方法，并用 race detector、压力测试和业务不变量验证正确性。

排障不是随机抓火焰图，而是从用户影响和资源饱和提出假设，再选择能证伪它的证据。

本期完成系列闭环：建立压测方法、诊断端口和线上 Runbook，并复现 goroutine 泄漏、锁竞争、连接池耗尽与内存增长。

目标不是背 API，而是建立一套能设计容量、约束资源、证明正确性并处理线上事故的并发工程方法。

这个系列围绕同一个“高扇出聚合服务”逐期演进：入口接收请求，并发访问数据库、缓存和 RPC，最后聚合结果。每一期都会保留可复现实验、错误版本、修复版本和验收指标。

这张由 ImageGen 生成的系列概念图把高并发抽象成一条受控数据流：左侧大量青色任务先进入有界队列，中间由少量执行核心调度，右侧连接多个下游节点；少量橙色信号表示被监控和限制的过载，而不是任其扩散成雪崩。

Rust 的类型系统可以阻止不安全共享，但不会替你决定该共享多少、排队多久和何时拒绝。

本期先区分线程并行和 async I/O，并理解所有权、Send、Sync 与 Arc 真正保证什么。

async fn 返回的是一台惰性状态机；只有 executor 持续 poll，它才会向前执行。

本期理解 Tokio task 的调度与取消语义，并实现不泄漏子任务的 fan-out/fan-in。

async 让等待更便宜，Semaphore 决定允许多少等待同时存在。

本期实现 /aggregate：每个请求并发访问多个下游，但入口和依赖都有独立硬上限。