什么是线程池？
无废抓取浏览器为公共网络收集任务提供云浏览器会话，应用程序可以通过有限线程池工作流提交。
摘要
- 线程池重用工作线程。 任务进入队列，现有工作线程执行它们，而无需为每个任务创建新的线程。
- 队列是设计的一部分。 它的大小和接收规则决定了内存使用、延迟和过载行为。
- 池大小遵循工作负载形状。 I/O 等待和 CPU 密集执行对工作线程提出不同的要求。
- 未来将提交与完成分开。 调用者可以通过明确的句柄观察结果、失败、取消和时间预算。
- 更多线程可能会降低性能。 竞争、上下文切换、下游压力和共享锁可能会抹去任何增益。
线程池定义
线程池是一组可重用的工作线程，负责执行提交的任务。应用程序将工作放入队列中或交给执行器，而不是为每个工作单元创建和销毁线程。可用的工作线程接受任务，运行它，记录结果，并返回池。
该模式减少了线程生命周期开销，并集中限制、调度、关机和结果处理。执行器抽象和线程一样重要，因为调用者需要一种明确的方式来提交工作并观察完成，而不必直接拥有工作线程的创建。这里使用的主要术语遵循 Python 并发未来文档，它为该概念提供了一个具体的技术边界，而不是将其视为营销标签。
一个有用的定义还说明了该概念不做什么。线程池并不自动意味着并行加速、无限任务缓冲，或替代速率控制。运行时约束和工作负载行为决定了工作线程是否同时执行，以及下游系统是否可以接受它们的输出。保持该边界可见，可以防止架构图将保证分配给属于另一层的组件。
线程池如何处理工作
池将不规则的任务到达转化为受控的工作线程执行。提交、排队、分配、完成和关闭每个都需要一个明确的策略。
- 调用者将工作打包为可调用的任务对象并附上所需的数据。
- 执行器仅在接收策略和生命周期状态允许的情况下接受任务。
- 队列在工作线程可用之前保存接受的工作，除非设计直接将工作交给空闲的工作线程。
- 工作线程执行任务，并在相关的完成句柄中存储结果或异常。
- 执行器将工作线程返回到池，暴露结果，并最终执行有序的关闭。
固定池限制活动线程，缓存设计变化工作线程数量，工作窃取设计让空闲工作线程从相邻的队列中接受任务。名称在不同的运行时之间有所不同，但每个实现仍然对排队、工作线程创建、拒绝和生命周期做出选择。此行为在 Java ThreadPoolExecutor 文档中有更完整的记录。该来源很有用，因为它描述了实际执行或数据模型，而不是依赖于松散的类比。
线程池组件
| 组件 | 责任 | 设计问题 |
|---|---|---|
| 执行器 | 接受工作并管理生命周期 | 关闭开始后发生什么？ |
| 任务队列 | 缓冲接受的工作 | 容量是有限且可观察的吗？ |
| 工作线程 | 一次执行一个任务 | 一个任务可以无限制地阻塞吗？ |
| 未来 | 代表完成或失败 | 取消是如何传播的？ |
| 拒绝政策 | 处理超出能力范围的工作 | 呼叫者应该阻塞、丢弃还是重定向？ |
将队列视为实现细节是过载的一个常见来源。一个无限制的队列可以在延迟和内存上升而没有明显上限的情况下保持活动线程数稳定。一个有限的队列使压力明确，并迫使系统选择响应。
线程池的适用场景
阻塞网络客户端
当客户端库暴露同步接口并且任务量保持在限制内时，工作者可以重叠socket等待。
文件和存储操作
一个池可以将阻塞文件工作与事件循环或请求线程隔离，同时保持清晰的完成句柄。
短背景任务
可重用的工作者可以处理频繁的小工作，而不必为每个任务分配一个长期存在的线程。
适配器边界
一个线程池可以在狭窄的异步或服务级契约后包含一个阻塞的第三方库。
这些用例共享一个选择规则：选择线程池是因为其执行和所有权模型与工作负载相匹配，而不是因为名称听起来更先进。长时间运行的服务、在同一小池中等待其他任务的任务，以及高度CPU绑定的Python代码可能需要不同的结构。池应与阻塞行为匹配而不是表面语法。
大小和队列政策
池大小在有用的重叠与争用和资源成本之间取得平衡。没有普遍的工作者数量，因为任务在CPU时间、等待时间、内存、文件描述符和下游影响上有所不同。
- 测量服务和等待时间。 一个等待大部分时间的任务可能能容忍比一个饱和CPU的任务更多的工作者。
- 限制队列。 有限容量在内存成为唯一限制之前将过载转化为政策决策。
- 避免嵌套等待。 一个等待同一耗尽池中另一个任务的工作者可能会造成死锁。
- 命名工作线程。 有用的名称将堆栈跟踪和指标与拥有的池和工作负载关联起来。
- 定义关闭。 选择排队的工作是完成、被取消，还是交给另一个持久系统。
用代表性流量进行调优，然后观察队列年龄，而不仅仅是工作者数量。队列年龄的增长意味着所接受的工作等待的时间更长，即使吞吐量看起来稳定。这个信号通常在用户面临超时或内存警报之前就出现。一个相关的主要参考是 Windows线程池架构指导，它澄清了该选择背后的存储、执行或互操作性假设。
线程池故障模式
当线程池的限制仅存在于活动工作者上时，它们会安静地失败。等待的任务、下游连接和任务拥有的内存可能继续在可见数量之外增长。
- 无限制提交。 快速生产者可以创建一个长队列，其最旧的工作在开始之前就已过时。
- 池内部依赖。 等待同一耗尽池的未来的工作者可能会阻止所需任务的运行。
- 隐藏阻塞。 一个被描述为小的任务可能在其大部分生命周期内等待DNS、存储、锁或远程配额。
- 共享客户端误用。 一个库对象即使在池本身是正确的情况下，也可能不安全以供并发访问。
- 突然关闭。 在没有完成政策的情况下停止工作者可能会留下部分写入、租约或外部会话处于活动状态。
故障应追溯到最小的负责层。当延迟上升时，检查队列年龄和被阻塞的堆栈；当CPU上升时，检查任务成本和锁争用；当依赖减慢时，在扩大池之前减少入场。这种做法产生有用的纠正措施，而不是模糊的指令来增加更多容量。
Web收集中的线程池
Web收集池应该提交小的独立工作，其输出携带源URL和工作标识符。池管理本地重叠；它不允许过载主机或忽视API的服务合同。
对于公共网络输入，获取层应记录请求的URL、最终URL、收集时间、响应模式和内容检查，然后再开始下游处理。返回结构化的结果以便成功、验证失败、取消或时间预算耗尽，而不是简单的字符串。这个交接给分析师提供了可重复的源记录，并将收集行为与解释分开。
无残余处理开启句子中描述的托管Web收集步骤。应用程序仍然拥有源批准、字段定义、工作负载边界、保留、访问控制和验证。执行器拥有本地工作者，而应用程序拥有每主机的公平性、收集范围、远程限制，以及排队的工作是否仍然有价值。那些层之间的明确契约使后续更改更易于测试。
当用例需要审计时，管道应同时保留原始证据和策划输出。原材料支持在解析器或架构更改后进行重新处理；策划表支持稳定分析。仅在检查最终页面是预期页面而必填字段存在后存储收集的内容。这两种表示回答不同的操作问题，不应被误认为是重复的。
线程池审查检查表
在设计审查期间使用以下问题。书面答案比假设默认值更有价值，因为它揭示了团队在线程池方面的不一致。
- 最大队列容量和最大队列年龄是多少？
- 一个任务可以在同一池中等待另一个任务吗？
- 哪些操作会阻塞，什么会释放这些等待？
- 结果、异常和取消是如何表示的？
- 共享客户端和解析器是否被记录为线程安全？
- 哪些远程服务限制独立于工作线程数量？
- 哪些度量显示饱和度在用户可见故障之前？
- 关闭是如何处理排队和活动工作的？
当线程池的队列、拒绝行为、任务所有权、监控和关闭路径与工作线程数量一样谨慎时，它就是生产就绪的。在工作负载形状、数据量、服务限制或消费者期望改变后，重新审视答案。对于探索性批处理合乎逻辑的架构可能不适合持续的生产路径。
结论
线程池是一个可重用的工作管理模式，而不是一个神奇的速度控制器。当许多独立任务可以共享有限数量的线程，并且应用程序需要一个地方来管理提交、结果和关闭时，它是有帮助的。好的设计根据观察到的阻塞行为来调整工作线程的数量，限制排队工作，防止池内部死锁，并协调本地并发性与远程容量。
准备构建一个受限的浏览器工作池吗？
将托管的浏览器会话与明确的队列容量、工作所有权和结果验证相结合。
今天注册并获取 $5的免费信用 — 无需信用卡.
领取你的$5信用→常见问题解答
线程池解决了什么问题？
线程池重用一组管理的工作线程来处理多个提交的任务。它减少了重复的线程创建，集中生命周期控制，并让应用程序控制活跃工作。队列和拒绝策略是必不可少的，因为池还必须定义当任务到达的速度超过工作线程完成的速度时会发生什么。
一个池应该有多少个线程？
合适的大小取决于测得的CPU时间、等待时间、内存、文件描述符、共享锁和下游容量。CPU密集型工作通常需要与可用执行资源之间更紧密的关系。I/O密集型工作可能受益于更多重叠，但仅在队列和远程系统保持健康的情况下。
线程池可以死锁吗？
可以。常见情况是当每个工作线程都在等待提交到同一池的另一个任务，但由于没有可用的工作线程而无法启动。共享锁和不一致的获取顺序可能会产生其他死锁。依赖结构必须与池大小分开审查。
线程池和连接池是一样的吗？
不是。线程池管理执行工作线程，而连接池管理可重用的数据库、服务或网络端点连接。一个任务在运行时可能需要一个连接，因此这两个池会相互作用。它们的容量应该协调，以避免工作线程无限期等待连接。
浏览器收集应该使用线程池吗？
当作业是独立且有限时，线程池可以适合同步浏览器或HTTP客户端。异步客户端可以使用较少的线程和事件循环。在这两种设计中，本地工作线程数量必须与每主机策略、会话限制、验证和下游处理能力分开。