std::thread启停成本高，需线程池复用线程以提升吞吐量；最小实现含任务队列、线程循环和停止机制，依赖mutex+condition_variable阻塞等待，enqueue需move+notify，工作线程须谓词wait并异常捕获。
为什么 std::thread 不够用，得自己写线程池
直接用 std::thread 启停成本高，频繁创建销毁会触发系统调用、内存分配和上下文切换，吞吐量上不去；而线程池复用固定数量的线程，让任务排队等执行，是高并发 I/O 或计算密集场景的刚需。标准库没提供线程池，必须手撸或依赖第三方（如 boost::asio::thread_pool），但自实现能控制调度逻辑、避免黑盒依赖。
核心组件：任务队列 + 线程循环 + 停止机制
一个最小可用线程池只需三块：std::queue（或 std::deque）存待执行任务、std::vector<:thread></:thread> 管理工作线程、std::atomic<bool></bool> 控制运行状态。关键不是“存任务”，而是“怎么取”——必须用 std::mutex + std::condition_variable 配合阻塞等待，否则空轮询吃满 CPU。
- 任务类型统一为
std::function<void></void>，支持 lambda、bind、成员函数绑定 - 队列推荐用
std::queue<:function>></:function>，不追求随机访问，push()/pop()语义清晰 - 停止时要唤醒所有等待线程（
cv.notify_all()），否则线程卡在wait()里无法退出 - 析构函数必须调用
join()，不能让线程 detached，否则程序终止时未完成任务丢失且可能 crash
如何安全地向队列 push 任务并唤醒线程
外部线程调用 enqueue() 时，先锁住互斥量，插入任务，再立刻 notify_one()（或 notify_all()）。注意：notify 必须在 unlock 之前还是之后？——都可以，但推荐在 unlock 之后，避免唤醒的线程抢锁失败又立即阻塞，增加调度开销。
void enqueue(std::function<void()> task) {
{
std::lock_guard<std::mutex> lock(queue_mutex);
tasks.emplace(std::move(task));
}
cv.notify_one(); // unlock 已完成，这里更轻量
}
常见错误：漏掉 std::move(task)，导致拷贝构造函数被调用，而有些 lambda 捕获了非可拷贝对象（比如 std::unique_ptr），编译直接报错 use of deleted function。
立即学习“C++免费学习笔记（深入）”；
工作线程死循环里怎么正确 wait + pop
每个线程执行的函数里，必须用 cv.wait(lock, [&]{ return stop || !tasks.empty(); }) 这种带谓词的等待，而不是先 wait() 再检查空队列——否则存在竞态：通知来了但还没加锁，线程已判断为空，跳过执行。
-
stop是std::atomic<bool></bool>，保证多线程读写可见 - pop 操作必须在锁区内完成，且要用
std::move转移出队列元素，避免无谓拷贝 - 如果任务抛异常，别让它崩掉整个线程——用
try/catch(...)吞掉，否则该线程退出后池子少一人，负载不均
真正难处理的是“优雅关闭”：任务队列非空时调用 stop()，已有线程要继续把活干完，新任务应拒绝接收。这需要额外状态位（如 accept_new_tasks）配合判断，不是仅靠 stop 标志就能搞定的。
