C++实现多线程任务异步调度队列 _ 线程池与工作者线程协作模式【源码】-C++-PHP中文网

根本原因是std::queue未加锁导致竞态，且主线程退出时未join()线程致析构调用std::terminate()；须用std::mutex保护push/pop，std::condition_variable避免轮询，并确保每个std::thread析构前已join()。

c++实现多线程任务异步调度队列 _ 线程池与工作者线程协作模式【源码】

根本原因通常是 std::queue 未加锁，或生产者/消费者线程对共享队列的访问存在竞态。更隐蔽的问题是：主线程退出前没等待工作者线程结束，导致 std::thread 对象析构时调用 std::terminate()。

必须用 std::mutex 保护 std::queue 的 push() 和 pop()；仅声明 std::queue 为 std::atomic 无效（它不支持原子操作）
使用 std::condition_variable 替代轮询——避免空转消耗 CPU，且能精确唤醒等待线程
每个 std::thread 对象在析构前必须处于 joinable() 状态，推荐在析构函数中统一调用 join()，不要用 detach()
任务函数对象需支持移动语义：用 std::function && 接收，再通过 std::move() 存入队列，否则可能触发拷贝失败（如捕获了不可拷贝的 lambda）

直接把 std::future 塞进队列不行——它不可拷贝、不可默认构造，且一旦被 get() 过就失效。正确做法是让线程池只负责执行，结果由 std::packaged_task 自动绑定到其关联的 std::future 上。

定义任务类型为 std::packaged_task（无参无返回），或泛型封装如 std::packaged_task
创建任务时：先构造 std::promise，再用 std::bind 或 lambda 包装原始函数 + promise.set_value()，但更简洁的是直接用 std::packaged_task 构造器接收可调用对象
入队前调用 task.get_future() 获取对应 std::future 并返回给调用方；工作者线程执行 task() 后，future 自动就绪
注意：std::future::get() 是阻塞的，若想非阻塞检查，用 wait_for(std::chrono::seconds(0)) == std::future_status::ready

仅设置一个 bool stop_requested 并通知条件变量，会导致正在执行的任务被强行中断（C++ 标准线程不支持抢占式取消），且已入队但未取走的任务永久丢失。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

shutdown 应分两阶段：先设 flag 禁止新任务入队（enqueue() 返回 false 或抛异常），再等待队列清空 + 所有活跃任务完成
工作者线程循环中需同时检查两个条件：!stop_requested || !queue.empty()，否则可能在 flag 为 true 但队列非空时提前退出
推荐用 std::atomic 替代普通 bool 控制 flag，避免编译器优化导致读写重排
等待所有线程结束前，要先调用 cv.notify_all() 确保阻塞中的线程有机会检查 flag 并退出循环

std::jthread 内置自动 join() 和协作式中断机制，能直接替代手写的生命周期管理与停止令牌逻辑，但要注意它不是“万能补丁”。

构造 std::jthread 时传入带 std::stop_token 参数的函数，工作者线程可通过 token.stop_requested() 检查是否应退出
std::jthread 析构时自动调用 join()，无需手动写 for (auto& t : threads) t.join();
但队列本身仍需互斥保护，std::stop_token 不提供同步原语，不能替代 std::mutex 或 std::condition_variable
若需兼容 C++17，别硬套 std::jthread；可用 std::unique_ptr<:thread> + RAII 封装模拟类似行为