/* Page prose (zh-Hans) */
"CappingConcurrency" = "# 限制同时运行的数量\n\n基本模式会把*每一个*任务都在一开始就添加进去。对 8 帧来说这没问题。但对 500 帧来说，你就等于是让系统一次性启动 500 个子任务，每一个也许都在内存里攥着一个解码后的帧，或者在猛敲同一块磁盘或同一台服务器。这可能会撑爆内存、把磁盘折腾坏，或者让你被限流。你通常会想要一个**并发上限**：最多让 `N` 帧在途，并且只有当一帧完成时才启动下一帧。\n\n在经典模型里，你有一个原生的旋钮来做这件事：来自 [Operations](Operations.playgroundchapter/Overview) 这一章的 `OperationQueue` 的 `maxConcurrentOperationCount`，或者来自 [组与信号量](Groups%20and%20Semaphores.playgroundchapter/Overview) 这一章的 `DispatchSemaphore`。**task group 没有这样一个内置设置**：并不存在 `group.maxConcurrency = 4`。相反，你要通过控制*你何时调用 `addTask`*来表达这个上限，标准写法是这样的：先用 `N` 个任务给 group **预热**，然后在收集循环里，每当一个结果出来时就添加一个新任务。这样就能让在途的数量始终在 `N` 附近徘徊。";
"CappingConcurrency-2" = "**观察运行：** 全部 20 帧仍然都会被处理，结果和“全部扇出”的版本一样。但在任何一个瞬间，运行中的都不会超过 4 个。20 帧、每批 4 个、每个半秒，整件事大约要花 **2.5 秒**，比一次性发射全部 20 个要慢，但换来的是一个有界、可预测的占用量。这个取舍，用一点点挂钟时间换来对内存和负载的硬性上限，正是你会选择它的原因。根据你要保护的资源来调节 `maxInFlight`。\n\n* callout(试一试): 把 `maxInFlight` 设为 `1`；你就又把这个 group 变回了顺序的、一次一个的版本。\n\n[上一页](@previous)  |  第 8 / 9 页  |  [下一页: 小结](@next)";
