Windows线程优先级需先设进程优先级类再设线程偏移，Linux实时策略需权限且SCHED_OTHER下priority必须为0；std::thread用native_handle()获取句柄但类型平台相关；跨平台勿映射原始值，应分层抽象为低/中/高三级。
Windows 上用 SetThreadPriority 调整线程优先级不生效？
多数情况不是代码写错了，而是没意识到 Windows 的线程优先级是「相对进程基准」的。进程本身有优先级类（如 IDLE_PRIORITY_CLASS、HIGH_PRIORITY_CLASS），线程优先级只是在这个类内偏移。比如进程是 NORMAL_PRIORITY_CLASS，你对线程调 SetThreadPriority 设为 THREAD_PRIORITY_HIGHEST，实际等效于 NORMAL + 2，远低于一个设为 HIGH_PRIORITY_CLASS 的普通线程。
- 必须先用
SetPriorityClass设置进程级优先级，再调SetThreadPriority才能真正拉高调度权重 -
THREAD_PRIORITY_TIME_CRITICAL很危险：可能饿死系统线程，仅限极短时关键路径，且需管理员权限 - 普通应用尽量避免硬设，尤其不要在非主线程里反复调用——调度器开销明显，还可能触发 Windows 的“优先级衰减”机制
Linux 下用 pthread_setschedparam 失败返回 EPERM
这是权限问题，不是 API 用错。Linux 默认禁止普通用户提升线程的实时调度策略（SCHED_FIFO / SCHED_RR），哪怕只设个 priority=1 也会被拒。
- 临时解决：用
sudo setcap cap_sys_nice+ep ./your_program授予能力（比直接 sudo 安全） - 永久方案：在
/etc/security/limits.conf加一行* soft rtprio 99，然后重新登录终端 - 注意
SCHED_OTHER（默认）下pthread_setschedparam的 priority 必须为 0，设其他值会直接失败 - 实时策略线程一旦跑飞（比如死循环没 yield），整个系统可能卡死——务必配超时或信号中断逻辑
C++11 std::thread 怎么拿到原生句柄去调系统 API？
std::thread 不提供跨平台句柄抽象，但标准允许通过 native_handle() 拿到底层 OS 句柄。问题在于类型不透明：Windows 返回 HANDLE，Linux 返回 pthread_t，不能直接传给系统函数。
- Windows：把
t.native_handle()强转成HANDLE就能喂给SetThreadPriority - Linux：必须用
pthread_setschedparam，且传入的是pthread_t，刚好就是t.native_handle()的类型 - 别试图在
std::thread析构后还用这个句柄——它已失效，Windows 下可能变成INVALID_HANDLE_VALUE，Linux 下pthread句柄彻底无效 - 如果用了
std::jthread（C++20），记得在join()或detach()前操作，否则句柄可能提前释放
跨平台封装线程优先级时，哪些值根本没法对齐？
别指望 std::thread 层面做“统一优先级枚举”。Windows 的 THREAD_PRIORITY_ABOVE_NORMAL 和 Linux 的 SCHED_RR 优先级 50 在语义、调度行为、权限要求上完全不是一回事。
立即学习“C++免费学习笔记（深入）”；
- Windows 的 “normal class + above normal” ≈ Linux 的 “SCHED_OTHER + nice -2”，但后者不需要特权，前者需要进程有相应权限
- Linux 的
SCHED_FIFO是抢占式实时调度，Windows 的TIME_CRITICAL是尽力而为，并非严格实时 - 最稳妥的跨平台做法：只在启动时按平台约定设一次，且只用“低/中/高”三级抽象，底层分支处理，不暴露原始数值
- 日志里记清楚实际生效的策略和值——调试时你会发现，很多“设了没反应”其实是策略被降级到了
SCHED_OTHER或NORMAL_PRIORITY_CLASS
线程优先级不是性能银弹，尤其在多核饱和场景下，错误设置反而加剧锁竞争和缓存抖动。真要压低延迟，先看自旋等待、内存布局、系统调用次数，再碰调度策略。
