Java线程优先级仅为操作系统调度的弱提示，不能保证执行顺序，仅在就绪态且无强干扰时略微提升高优线程被选中概率；必须在start()前设置，取值1–10，非法值抛IllegalArgumentException，跨平台效果不可靠。
Java 线程优先级只能作为操作系统调度的弱提示，不能保证执行顺序，但合理设置可在资源竞争激烈时略微提升高优线程被选中的概率。关键在于设对时机、用对范围、不依赖它做业务逻辑控制。
设置方式和硬性规则
必须在 调用 start() 之前 设置，否则无效或抛异常：
- 取值严格限定为 1～10（含），对应
Thread.MIN_PRIORITY、Thread.NORM_PRIORITY、Thread.MAX_PRIORITY - 传入 0、11 等非法值会立即抛
IllegalArgumentException - 新线程默认继承创建它的父线程优先级（不一定是 5），建议显式设置避免隐式偏差
- 推荐在构造方法中设置，例如：
class MyThread extends Thread {<br> MyThread() { setPriority(Thread.MAX_PRIORITY); }<br> public void run() { /* ... */ }<br>}
它到底怎么“影响”调度
影响的是就绪态（Runnable）线程在 CPU 时间片分配时的相对概率，不是强制指令：
- 仅在多个线程同时处于就绪态、且无其他强干扰（如锁竞争、I/O 阻塞、GC 暂停）时，才可能观察到微弱差异
- Linux 默认忽略 Java 优先级（CFS 调度器不映射），HotSpot 通常静默丢弃设置；Windows 虽支持映射，但需管理员权限且行为不稳定
- 即使映射成功，也只作用于同一 CPU 核心上的就绪队列，无法跨核、无法压倒同步块或原子操作的底层竞争逻辑
- 实测常见表现：满载环境下，高优线程在 10 次就绪竞争中可能约 6～7 次先获得时间片，而非 100% 先执行
哪些场景别指望它起作用
以下情况中，优先级基本无感知：
立即学习“Java免费学习笔记（深入）”；
- 线程处于阻塞（如
Object.wait()）、等待（LockSupport.park()）、睡眠（Thread.sleep()）状态时，优先级不参与调度决策 - 存在
synchronized块或AtomicInteger.compareAndSet()等竞争时，锁获取和 CAS 成败由硬件原子指令与队列策略决定，与优先级无关 - 低优先级线程若长期得不到调度，可能引发饥饿，反而降低整体吞吐
- 依赖优先级实现“先执行后校验”“高优必先完成”等业务逻辑，极易出错且不可移植
比优先级更靠谱的替代方案
真有优先级敏感需求，应放弃线程级控制，转向任务级或资源级设计：
- 用
PriorityBlockingQueue包装任务，按自定义权重排序，交由ThreadPoolExecutor消费 - 为不同重要性任务划分独立线程池（如实时计算池、后台日志池、定时任务池），通过资源隔离避免干扰
- 关键路径中主动让权（
Thread.yield()）或精准等待（LockSupport.parkNanos()），但需结合具体场景评估效果 - 用
CompletableFuture编排依赖、用CountDownLatch协调节奏，从逻辑上控制执行时序
