Java线程优先级合法范围是1–10，越界值被静默截断为1或10；其实际调度效果跨平台差异极大，Linux/ macOS 基本无效，Windows 仅粗粒度映射到4个等级，不应依赖它控制执行顺序。
Java线程优先级的合法取值范围是1–10，但setPriority不会抛出异常来阻止越界赋值
调用setPriority时传入0或11，Java不会报错，而是静默截断：低于1的设为1，高于10的设为10。这是JVM规范要求的行为，不是bug。
- 合法值只有
Thread.MIN_PRIORITY（=1）、Thread.NORM_PRIORITY（=5）、Thread.MAX_PRIORITY（=10）三个常量，其余整数虽可设，但语义不明确 - 别依赖
thread.setPriority(7)在所有系统上都比6“更优先”——它只表示“向JVM提出请求”，实际调度权在OS - Linux下所有Java优先级最终映射到同一nice值（通常0），Windows则映射到4个实际调度等级（Idle、Normal、High、Realtime），差异极大
Windows和Linux对Java优先级的实际映射完全不同
Java线程优先级不是跨平台一致的调度信号，而是JVM根据宿主OS能力做的尽力映射。你写的setPriority(10)在Windows可能触发THREAD_PRIORITY_HIGHEST，在Linux却大概率等同于setPriority(5)。
- Windows：1–10被压缩映射到4个Win32优先级类：
THREAD_PRIORITY_IDLE（对应Java 1）、THREAD_PRIORITY_NORMAL（Java 2–6）、THREAD_PRIORITY_ABOVE_NORMAL（Java 7–8）、THREAD_PRIORITY_HIGHEST（Java 9–10） - Linux：HotSpot默认使用
pthread_setschedparam，但普通用户进程无法提升实时调度策略（SCHED_FIFO/SCHED_RR），所以所有Java优先级都落在SCHED_OTHER类中，仅影响CFS的nice值——而JVM通常不修改nice，导致全部线程实际调度权重相同 - macOS表现类似Linux，且从Java 17起，GraalVM甚至默认禁用优先级映射以避免误导
为什么setPriority几乎不影响CPU时间分配
现代OS调度器设计目标是公平与响应性，而非严格遵循应用层声明的“优先级”。尤其在非实时系统中，Java线程优先级对真实执行顺序的影响微乎其微。
- 线程真正抢到CPU，取决于：是否处于RUNNABLE状态、是否被I/O或锁阻塞、当前负载、CFS虚拟运行时间（vruntime）等，
setPriority不参与这些计算 - 实测显示，在4核Linux机器上启动10个计算密集型线程并分别设为1/5/10，它们的CPU占用率差异通常小于3%，远低于测量误差
- 唯一较可靠的影响场景：Windows GUI应用中，把GUI线程设为
MAX_PRIORITY可能略微缓解界面卡顿——但这本质是利用了Windows消息泵与线程优先级的耦合，并非通用规律
替代setPriority的更可控做法
如果你真需要控制执行顺序或资源倾斜，应该绕过优先级，直接干预线程行为本身。
立即学习“Java免费学习笔记（深入）”；
- 用
ExecutorService配合不同队列策略：比如给高优先任务配PriorityBlockingQueue，自己实现Comparable逻辑，比依赖OS调度更确定 - 对关键路径做显式让权：
Thread.yield()或短时Thread.sleep(1)，比设高优先级更容易观察到效果 - 避免跨线程争抢共享资源：用
StampedLock代替synchronized，或拆分临界区，这带来的吞吐提升远超调优先级 - 真有实时性要求？考虑JNI调用
sched_setscheduler（Linux）或SetThreadPriority（Windows），但需root/Admin权限，且脱离JVM管控
优先级映射不是黑盒，而是JVM在OS约束下的妥协结果；想靠setPriority解决性能问题，往往意味着还没看清瓶颈在哪。
