c++oding="utf-8" ?>
不能直接当线程数用，因其仅返回逻辑处理器数（如8），未考虑任务类型、锁竞争与调度开销；计算密集型可作起点，i/o或高竞争场景需压测调优。
上下文切换开销无法完全消除，但可通过减少线程数量、避免忙等、缩短临界区和改用轻量同步机制显著降低其负面影响。
std::thread::hardware_concurrency() 该不该直接当线程数用
不能直接照搬。返回值只是逻辑处理器数量（比如 8 表示 8 个超线程），但真实吞吐取决于任务类型和锁争用程度。盲目创建 8 个线程跑高竞争临界区，反而加剧调度压力。
- 计算密集型任务：线程数 ≈
std::thread::hardware_concurrency()是合理起点 - I/O 密集或锁竞争高的场景：从 2–4 个线程开始压测，观察
perf stat -e context-switches指标变化 - 线程池中工作线程数建议设为
min(4, hardware_concurrency())起步，再根据top中的%sy（内核态 CPU 占比）调整
std::this_thread::yield() 在锁竞争时到底有没有用
在极低延迟、短临界区且写者极少的场景下可能微幅缓解，但多数情况下是“伪优化”——它不释放 CPU 时间片，只是让出当前调度权，仍可能被立刻重新调度，徒增调度器负担。
- 常见误用：
while(!try_lock()) { std::this_thread::yield(); }→ 实际效果常不如std::this_thread::sleep_for(1ns)或直接用std::unique_lock(mutex, std::try_to_lock) - 真正适合
yield()的场景：协程让出、自旋等待某个标志位（非锁）、或调试时模拟调度行为 - 性能对比：在高争用下，
yield()循环的上下文切换次数反比阻塞等待更高
读多写少时为什么 shared_mutex 比 mutex 更省上下文切换
因为 std::shared_mutex 允许多个读线程并发进入临界区，不触发互斥等待；而 std::mutex 下每个读操作都需完整加锁/解锁流程，哪怕无写者，也频繁进出内核调度路径。
- 读操作用
std::shared_lock<:shared_mutex></:shared_mutex>：零阻塞，几乎不触发上下文切换 - 写操作用
std::unique_lock<:shared_mutex></:shared_mutex>：仅写者间互斥，不影响读线程调度节奏 - 注意：GCC libstdc++ 在较老版本（如 GCC 9 前）对
shared_mutex的实现有额外系统调用开销，建议用 GCC 10+ 或 Clang 12+
packaged_task + 线程池为何能压低上下文切换频次
核心在于复用线程和消除高频创建/销毁。每次 std::thread 构造和 join() 都隐含至少两次上下文切换（启动与退出），而线程池中一个线程持续消费任务队列，只在空闲时短暂阻塞于 condition_variable::wait()。
- 关键点：
std::packaged_task对象本身轻量（移动语义），不带线程生命周期，交给池中固定线程执行，避免了 per-task 的线程管理开销 - 队列同步推荐用
std::mutex+std::condition_variable，而非自旋锁——空闲时主动让出 CPU，比死等更省上下文切换 - 实测数据：1000 个短期任务，直接起 1000 个线程 vs 线程池（4 线程），前者上下文切换次数高出 3–5 倍（见
/proc/<pid>/status</pid>中的voluntary_ctxt_switches）
最容易被忽略的是：上下文切换开销往往藏在「看似无锁」的地方——比如频繁调用 std::chrono::steady_clock::now()（涉及系统调用）、或在临界区内做 std::cout（内部有锁）。优化前先用 perf record -e sched:sched_switch 定位真实热点线程切换点，而不是凭直觉改 yield 或锁类型。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
