std::jthread是c++20新增的线程类，c++17不支持；std::shared_mutex是c++17唯一新增同步原语，专为读多写少场景优化，需包含头文件，不支持递归加锁和超时。
std::jthread 在 C++20 才正式标准化，C++14 和 C++17 都没有它 —— 别在 C++17 项目里写 std::jthread，编译器会报错。
std::shared_mutex 是 C++17 唯一新增的同步原语
C++17 引入了 std::shared_mutex 和配套的 std::shared_lock，专为“读多写少”场景优化。它不替代 std::mutex，而是补充：多个线程可同时持 shared_lock（读锁），但任意写操作必须用 unique_lock 排他获取。
- 头文件是
<shared_mutex></shared_mutex>，不是<mutex></mutex>，漏包含会编译失败 -
std::shared_mutex不支持递归加锁，也不支持超时（try_lock_for等），要用超时得选std::shared_timed_mutex（C++14 就有，但 C++17 才推荐） - 性能上，读并发提升明显，但写操作开销略高于
std::mutex，别盲目替换所有互斥量
C++14 对多线程库“没加新类，只修了行为”
C++14 没新增线程类或同步工具，但悄悄修正了 std::async 的默认启动策略：从“可能延迟执行（launch::deferred）”改为“优先异步执行（launch::async 或 launch::deferred 组合）”，实际效果是更大概率真正开新线程 —— 但你不能依赖这个“大概率”，显式传 std::launch::async 才可靠。
-
std::async的返回值std::future在 C++14 中仍不支持 move-only 类型的存储（如std::unique_ptr），要等 C++20 的std::future<t></t>完整支持 -
std::thread构造函数在 C++14 中仍不接受移动捕获的 lambda（比如[x = std::move(y)]{}），C++17 才放开限制
C++20 的协作式中断机制不可跳过
C++20 的 std::jthread、std::stop_token、std::stop_source 是一套协作停止方案，核心不是“强制杀线程”，而是让工作线程主动检查是否该退出。
-
std::jthread析构时自动join()，省去手动配对join()/detach()的心智负担，但代价是：如果线程卡死在无限循环里且没检查stop_token，join()会永久阻塞 -
std::stop_token::stop_requested()是轻量级原子读，无锁，但必须在线程函数内定期调用 —— 忘了加检查点，request_stop()就完全失效 -
std::stop_source可拷贝，std::stop_token可复制共享，但它们之间不是线程安全的“广播”，而是单向通知：一个stop_source触发，所有关联的stop_token同时变为已请求状态
真正容易被忽略的是：C++14/17/20 的多线程增强不是堆砌功能，而是逐步把“易出错模式”变成“难错模式”。比如 std::jthread 治的是忘记 join()，std::shared_mutex 治的是读锁粗粒度，stop_token 治的是硬 kill 导致资源泄漏 —— 但每一步都要求你理解底层协作契约，而不是光靠语法糖兜底。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
