java线程优先级不保证调度顺序，setpriority()仅为jvm建议且映射受os限制；linux下基本无效，windows下也受限于进程基优先级；实际生效需-xx:+usethreadpriorities、os权限及start()前调用；推荐用executorservice等协作机制替代。
Java线程优先级不保证调度顺序
Java的setPriority()只是向JVM提出一个建议，不是指令。JVM会把它映射到操作系统的线程优先级上，但这个映射既不一一对应，也不跨平台一致。比如Linux的SCHED_OTHER策略下，所有Java线程默认落在同一调度优先级范围内，Thread.MAX_PRIORITY（10）和Thread.NORM_PRIORITY（5）在底层可能都映射成同一个nice值，根本不会触发内核级抢占。
常见错误现象：Thread.sleep(0)后高优先级线程仍不抢到CPU；多个线程用不同setPriority()启动，执行时间分布毫无差别。
- Windows下映射相对明显（1–10 → Windows线程优先级类），但依然受进程基优先级限制
- Linux（主流JVM）基本忽略Java优先级，除非用
-XX:+UseThreadPriorities且运行在root权限下启用实时调度策略（不推荐） - Android Dalvik/ART 早期版本直接禁用优先级映射，OpenJDK 17+ 在cgroup v2环境里也趋于弱化该特性
Thread.setPriority() 的实际生效条件
调用setPriority()是否起作用，取决于JVM启动参数、OS权限、线程状态三者共同作用。它只在JVM明确支持且操作系统允许提权时才可能向下传递。
使用场景：极少数嵌入式或实时Java环境（如Real-Time Java Specification兼容JVM），普通应用中它基本是“装饰性API”。
立即学习“Java免费学习笔记（深入）”；
- 必须在
start()前调用才可能被JVM捕获；线程启动后再调用，多数JVM直接忽略（OpenJDK源码中setPriority0()对RUNNABLE状态线程返回false） -
-XX:+UseThreadPriorities是前提，但默认关闭；开启后还需OS允许Java进程调整调度策略（通常需cap_sys_nice能力或root） - 即使生效，也仅影响同优先级队列内的相对顺序，无法突破操作系统的调度周期（如Linux CFS的
vruntime机制）
替代方案：用显式协作代替优先级幻想
真正可控的调度逻辑得靠代码自己组织，而不是依赖不可靠的优先级数字。JVM线程调度器不提供硬实时保障，连“高优线程先执行”这种基础承诺都不做。
性能影响：滥用setPriority()可能引发意外的OS资源争抢（如在容器中触发cgroup throttling），反而降低吞吐。
- 用
ExecutorService配合不同队列策略（如PriorityBlockingQueue）实现任务级优先调度，而非线程级 - 对延迟敏感任务，用
LockSupport.parkNanos()或Phaser.awaitAdvanceInterruptibly()做精细等待控制 - 避免在同步块内调用
setPriority()——它可能触发JVM内部锁竞争，导致Unsafe.park行为异常
JVM源码里那行被注释掉的注释
OpenJDK hotspot/src/share/vm/runtime/thread.cpp 中，JavaThread::set_priority()函数开头有段被注释掉的说明：“This is a no-op on most platforms. Don’t rely on it.”——不是忘了实现，是故意不实现。
容易被忽略的地方：很多监控工具（如JConsole、VisualVM）仍会显示线程的priority字段，但这只是Java对象里的一个整数副本，和OS内核里正在运行的那个线程毫无关系。看到它变了，不代表调度器收到了信号。
