线程池构造时指定初始工作线程数是最直接可控的方式，决定长期存活的工作线程数而非任务队列长度或最大并发上限；传0通常非法，传1合法，超hardware_concurrency()可能增加调度开销。
线程池构造时指定初始工作线程数
绝大多数手动实现的 C++ 线程池（比如基于 std::thread + std::queue + std::condition_variable）都允许在构造时传入线程数量。这不是“运行时动态调整”，而是最直接、最可控的方式。
关键点在于：这个数字决定的是池启动时创建的**长期存活的工作线程数**，不是任务队列长度，也不是最大并发上限（除非你额外加限流）。
- 传
0通常非法 —— 多数实现会抛异常或断言失败 - 传
1是合法的，适合调试或单线程模拟场景 - 传大于
std::thread::hardware_concurrency()的值，可能造成调度开销上升，尤其在 CPU 密集型任务中
示例（简化版构造）：
ThreadPool pool(4); // 启动 4 个常驻工作线程
运行时增减线程需自行管理生命周期
C++ 标准库不提供“暂停/唤醒/销毁单个 std::thread”的接口，所以所谓“动态调整线程数”，本质是：停掉部分线程 + 启动新线程。这要求你在线程池内部维护可终止信号（如 std::atomic<bool></bool>）、安全退出逻辑和线程 join 调用。
常见错误是：只调用 thread.detach() 或忽略 joinable() 检查，导致程序退出时触发 std::terminate。
- 减少线程数时，必须确保目标线程已处理完当前任务并主动退出循环
- 增加线程数时，要避免重复启动同一对象（比如误把
std::thread成员变量 move 两次） - 所有线程退出前，必须消费完任务队列中剩余任务，否则任务会丢失
使用 std::jthread（C++20）简化线程管理
std::jthread 自动在析构时调用 join()，且内置 request_stop() 和 stop_token，比手写 std::atomic<bool></bool> 更安全可靠。
但注意：std::jthread 不代表“自动缩容”——它只是帮你省去显式 join() 和基础停止信号传递，线程池仍需自己判断何时该停掉某个 jthread 并从管理容器中移除。
- 每个
std::jthread对应一个独立工作循环，其内部需检查stop_token是否被请求 - 不能对同一个
std::jthread多次调用join()或request_stop()，否则未定义行为 - 若用
std::vector<:jthread></:jthread>存储，resize 减小时会自动析构末尾元素并 join，这是安全的
别混淆“线程数”和“任务并发度”
设置 8 个工作线程，并不等于任意时刻都有 8 个任务在跑。如果任务里有 I/O 等待、锁竞争或主动 sleep，实际并发执行数可能远低于线程数。
真正影响吞吐的往往是任务类型：
- CPU 密集型任务：线程数 ≈
std::thread::hardware_concurrency()通常是较优起点 - I/O 密集型任务：可设为更高（如 16~64），但需观察系统上下文切换开销
- 混合型任务：没有银弹，得靠压测 +
perf或vtune观察 CPU 利用率与线程等待时间
最容易被忽略的是：线程池本身无“拒绝策略”概念。当任务提交速度远超处理能力，队列会无限增长 —— 必须你自己加 queue.size() > threshold 判断，或用有界队列（如 boost::lockfree::queue 配合失败返回）。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
