直接调用 pthread_getschedparam(pthread_self(), &policy, ¶m) 可获取当前线程调度策略，policy 接收 sched_fifo/sched_rr/sched_other，param.sched_priority 返回对应优先级（sched_other 下恒为 0）；需确保参数非空、线程存在且具备权限，否则返回 einval 等错误码。
怎么用 pthread_getschedparam 拿到当前线程的调度策略
直接调用即可，但必须传入合法的线程 ID 和非空指针。最常踩的坑是传了 NULL 给 policy 或 param 参数，导致段错误。
-
pthread_getschedparam(pthread_self(), &policy, ¶m)是获取**当前线程**策略的标准写法 -
policy是int*，接收值如SCHED_FIFO、SCHED_RR、SCHED_OTHER -
param是struct sched_param*，其中param.sched_priority才是实际优先级数值 - 返回值为 0 表示成功；非 0 是错误码（比如
ESRCH表示线程不存在）
为什么 pthread_getschedparam 返回 EINVAL？
常见于两个原因：线程未启用实时调度，或系统禁用了相关权限。Linux 默认只允许 root 或具备 CAP_SYS_NICE 能力的进程设置/查询实时策略。
- 普通用户线程通常运行在
SCHED_OTHER下，此时param.sched_priority恒为 0 —— 这不是错误，是设计如此 - 若你手动用
pthread_setschedparam设过SCHED_FIFO却仍返回EINVAL，先检查ulimit -r是否为 0（表示实时优先级上限被锁死） - 非 root 进程调用时，即使策略是
SCHED_OTHER，某些内核配置下仍可能因权限检查路径触发EINVAL
SCHED_OTHER 的优先级值为什么总是 0？
因为 SCHED_OTHER（即 CFS 调度器）不使用静态优先级字段，而是动态计算 vruntime。POSIX 规定该策略下 sched_param.sched_priority 必须为 0，强行读写无意义。
- 不要试图通过修改
param.sched_priority来“提升”普通线程的 CPU 占比 —— 该值会被忽略 - 真正影响
SCHED_OTHER行为的是nice值（可用getpriority/setpriority操作），和调度策略本身无关 - 若需细粒度控制，应改用
cgroups v2的cpu.weight，而非折腾调度策略
跨平台兼容性要注意什么？
pthread_getschedparam 在 glibc、musl、macOS（部分支持）、FreeBSD 上都存在，但行为有差异。
- macOS 不支持
SCHED_FIFO/SCHED_RR，调用成功也只返回SCHED_OTHER和 0 优先级 - Windows 的 pthread 实现（如 pthreads-win32）基本不支持该函数，返回
ENOSYS - 嵌入式场景（如 uClibc）可能完全未实现，编译期需用
#ifdef _GNU_SOURCE或__USE_GNU宏判断 - 务必检查返回值，不要假设调用一定成功
真实环境中，策略和优先级往往只是调度器的一个输入维度，真正起作用的还有 cgroup 限制、CPU affinity、负载均衡状态 —— 别只盯着 policy 变量看。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
