std::thread 直接创建线程不适合高并发任务调度，因其频繁构造/析构引发大量系统调用和上下文切换开销，且缺乏并发度控制、内存管理、队列机制及统一生命周期管理能力。
为什么 std::thread 直接创建线程不适合高并发任务调度
频繁调用 std::thread 构造/析构会触发大量系统调用（如 clone），带来显著上下文切换开销；线程生命周期不受控还会导致资源耗尽（比如创建 10000 个 std::thread 几乎必然失败）。线程池的核心价值不是“复用线程”，而是“控制并发度 + 解耦提交与执行”。
- 默认栈大小通常为 1–8MB，100 个活跃线程就可能吃掉数百 MB 内存
- 没有内置队列机制，任务提交和执行强耦合，无法应对突发流量
-
std::thread不可拷贝、不可默认构造，难以统一管理（比如暂停、统计、优雅关闭）
如何用 std::queue + std::mutex + std::condition_variable 实现基础线程池
这是最常见也最容易出错的实现方式。关键不在“有没有锁”，而在“锁的粒度”和“唤醒逻辑是否精确”。
- 任务队列必须用
std::queue（非std::deque）配合std::mutex保护，避免在多线程 pop 时出现竞争条件 -
std::condition_variable::wait必须配合 while 循环检查条件（防止虚假唤醒），不能只用 if - 停止信号要用
std::atomic，且需在锁内修改后立即notify_all，否则工作线程可能永远阻塞 - 析构函数中应先设停止标志，再
join所有线程，不能倒过来
示例关键片段：
void ThreadPool::submit(std::function task) {
{
std::lock_guard lock(m_mutex);
m_tasks.push(std::move(task));
}
m_cv.notify_one(); // 注意：notify 可在锁外，但必须确保 push 已完成
}
std::jthread 和 std::stop_token 如何简化线程池关闭逻辑
C++20 引入的 std::jthread 自动 join，std::stop_token 提供协作式中断，能大幅降低手动管理状态的出错概率。
