linux下设线程优先级需用pthread_setschedparam配合sched_fifo/rr策略并检查返回值，windows则依赖进程优先级类的相对偏移，yield()不改变优先级且无效于调度控制。
Linux 下用 pthread_setschedparam 设置线程优先级
在 Linux 上，C++ 线程（std::thread）底层依赖 pthread，直接调用 pthread_setschedparam 是最可控的方式。POSIX 调度策略分 SCHED_FIFO、SCHED_RR 和 SCHED_OTHER，只有前两者支持优先级调整，且需特权（root 或 CAP_SYS_NICE）。
常见错误是调用后没检查返回值，结果优先级根本没生效，程序还照常跑——看着像成功了，实际被内核静默降级为 SCHED_OTHER。
- 先用
pthread_getschedparam查当前策略和优先级范围，避免硬写无效值（比如在普通用户下传 50 给SCHED_FIFO） - 设置前必须先
pthread_attr_setschedpolicy并设PTHREAD_EXPLICIT_SCHED，否则属性被忽略 -
std::thread对象需用native_handle()拿到pthread_t，不能对已分离线程操作 - 示例关键片段：
struct sched_param param;<br>param.sched_priority = 10;<br>int ret = pthread_setschedparam(th.native_handle(), SCHED_FIFO, ¶m);<br>if (ret != 0) fprintf(stderr, "set failed: %s\n", strerror(ret));
Windows 上用 SetThreadPriority 的限制
Windows 不叫“优先级”而叫“相对优先级”，基准是进程的优先级类（如 NORMAL_PRIORITY_CLASS），线程再在其基础上偏移。这意味着：同一数值在不同进程里实际调度权重可能完全不同。
容易踩的坑是以为设成 THREAD_PRIORITY_HIGHEST 就一定抢资源，但若进程本身是 IDLE_PRIORITY_CLASS，那这个“最高”其实比普通进程的“正常”还低。
立即学习“C++免费学习笔记（深入）”；
- 必须先用
GetPriorityClass确认进程级优先级类，再决定线程偏移量 -
SetThreadPriority返回TRUE只代表调用成功，不代表内核采纳——比如在沙盒或受限会话中会被无视 - 实时优先级（
THREAD_PRIORITY_TIME_CRITICAL）在非服务进程中常被系统压制，尤其 Win10+ 后更激进 - 别在 GUI 线程里乱设高优先级，容易卡死消息循环，表现为界面无响应但 CPU 不高
std::this_thread::yield() 不是优先级控制，别混用
有人看到“yield”就以为能让出 CPU 给更高优先级线程，其实它只是建议调度器切换，不保证目标线程被选中，也不改变任何优先级参数。在负载低时它几乎没效果，在负载高时可能让本该跑的线程被跳过。
典型误用场景：用它替代真正的优先级设置，结果逻辑卡顿却查不出原因。
-
yield()适合短等待自旋（比如等某个标志位），不是调度策略工具 - 它不涉及调度策略切换，所以跨平台行为一致，但也没法解决优先级问题
- 真正需要抢占式调度时，必须用平台原生 API 配合对应策略，
yield()连边角料都算不上
实时优先级的副作用比想象中大
设高优先级不是“让线程跑得更快”，而是“让它更频繁地打断别人”。一旦出错，影响的是整个进程甚至系统响应——比如一个死循环的 SCHED_FIFO 线程能把其他所有用户线程饿死，连 Ctrl+C 都收不到。
调试时最容易忽略的是：优先级设置成功了，但线程实际运行时间仍短，因为被 I/O 阻塞、锁竞争或内存缺页拖住，这时候调优方向全错了。
- 优先级只影响 CPU 时间片分配，不影响 I/O 等待、锁争用、TLB miss 等耗时
- 用
perf record -e sched:sched_switch观察实际调度行为，比看代码里的pthread_setschedparam调用更有说服力 - 生产环境除非确定要硬实时（如音频处理、工业控制），否则优先用线程池 + 任务优先级队列，而不是 OS 级优先级
