单核cpu上yield()易失效，因无其他就绪线程时调度器仍选当前线程；应改用sleep_for()、condition_variable::wait()等阻塞机制，或确保存在竞争线程。
在单核 CPU 上，yield() 很容易“失效”——调用后线程立刻被重新调度执行，形成看似让出、实则空转的假礼让，最终仍陷入高 CPU 占用的忙等待循环。这不是 bug，而是由单核调度机制和 yield() 的语义决定的：它只提示调度器“我愿意让”，但若就绪队列中没有其他可运行线程（尤其同优先级），调度器自然继续选它。
核心问题：单核下 yield() 缺乏竞争者
单核系统中，除非有其他就绪线程（且优先级≥当前线程），否则 yield() 几乎不改变执行流。常见场景如：
- 主线程启动 worker 后自己休眠或退出，只剩一个忙等线程
- 多线程程序但其他线程长期阻塞（如等待 I/O、锁、条件变量）
- 线程优先级设置不均，低优先级线程无法抢占
真正有效的替代方案
放弃依赖 yield() 做“轻量等待”，改用能强制让出 CPU 并进入阻塞态的机制：
-
用
sleep_for(1ms)替代yield()：哪怕 1 毫秒，也足以让调度器将线程置入阻塞态，释放 CPU 时间片，避免瞬时重调度。实测在单核嵌入式 Linux 上，比纯yield()降低 CPU 占用率 95% 以上 -
引入事件驱动同步原语：例如
condition_variable::wait()（C++）或Object.wait()（Java）。它们不仅阻塞，还与明确条件绑定，天然规避轮询 -
使用带超时的自旋辅助机制：先短时自旋（如 10–100 次循环），再调用
sleep_for()。兼顾响应性与节能，适合对延迟敏感但又不能无限忙等的场景
检查并激活竞争线程
如果确实需要协作式调度，必须确保“有得可让”：
- 确认至少存在另一个同优先级或更高优先级的就绪线程（例如一个空闲工作线程、心跳检测线程或定时器线程）
- 避免所有线程都依赖
yield()；至少一个线程应使用阻塞调用（如read(),poll(),wait()）维持就绪队列活跃 - 在实时系统中，可显式设置线程调度策略（如
SCHED_RR）并统一优先级，增强yield()的可预测性
调试验证方法
判断是否真陷入“yield 无效循环”：
- 用
top -H或htop观察该线程 CPU 使用率是否持续接近 100% - 在循环内插入计数器 + 日志，每千次打印一次时间戳，看实际间隔是否趋近于 0（说明未让出）
- 用
perf record -e sched:sched_switch抓取调度事件，确认该线程是否频繁连续出现在sched_switch记录中
