Java线程优先级在JVM层面不保证传递给操作系统，Linux下普通线程始终运行于SCHED_OTHER类，CFS调度器忽略Java优先级；Windows和macOS支持同样不可靠，实际调度效果微弱甚至被静默忽略。
Java线程优先级在JVM层面是否被真正传递给操作系统
Java的Thread.setPriority()调用**不保证**将优先级映射到宿主操作系统的调度策略。JVM规范只要求将1–10的优先级映射为“相对顺序”，具体实现由JVM厂商决定。HotSpot JVM在Linux上默认使用pthread_setschedparam()，但仅当启用了-XX:+UseThreadPriorities（默认开启）且线程未处于PTHREAD_SCOPE_SYSTEM作用域时才尝试设置；而现代Linux内核（2.6.23+）对普通用户线程忽略SCHED_OTHER下的nice值调整——这意味着即使JVM调用了系统调用，内核也可能直接无视。
Linux下普通Java线程无法通过setPriority获得CPU时间倾斜
除非以root权限运行并显式配置实时调度策略（如SCHED_FIFO），否则Java线程在Linux上始终运行在SCHED_OTHER类中。此时：
-
Thread.MIN_PRIORITY（1）和Thread.MAX_PRIORITY（10）在内核调度器眼中没有区别 - 实际调度仍由CFS（Completely Fair Scheduler）按
vruntime公平分配，与Java优先级无关 - 即使JVM成功调用
setpriority(PRIO_PROCESS, 0, nice)，普通用户进程的nice范围（-20~19）对CFS权重影响极小，且会被autogroup等机制进一步平滑
实测：启动两个无限循环线程，分别设为1和10优先级，在无负载机器上观察/proc/PID/schedstat，运行时间差通常小于0.5%。
Windows与macOS行为略有不同但依然不可靠
Windows的线程调度器对优先级更敏感，Thread.setPriority()会映射为SetThreadPriority()调用（如THREAD_PRIORITY_HIGHEST），但仍有明显限制：
立即学习“Java免费学习笔记（深入）”；
- Java线程默认创建为“普通”进程优先级（
NORMAL_PRIORITY_CLASS），无法提升整个进程级别 - 即使单个线程设为
MAX_PRIORITY，其调度优势也仅在同进程内有效；跨进程竞争时仍受系统全局调度策略压制 - macOS（XNU内核）对用户态线程优先级支持更弱，JVM基本只做空转处理，
setPriority()调用被静默忽略
Thread t1 = new Thread(() -> {
while (true) { /* CPU-bound work */ }
});
t1.setPriority(Thread.MAX_PRIORITY);
t1.start();
Thread t2 = new Thread(() -> {
while (true) { / same work / }
});
t2.setPriority(Thread.MIN_PRIORITY);
t2.start();
这段代码在任意主流OS上都无法稳定让t1获得两倍于t2的CPU时间——它不是调度保障机制，只是提示信号。
真正可控的并发资源分配方式有哪些
依赖setPriority()做性能调优是危险的幻觉。更可靠的做法包括：
- 用
ExecutorService配合ThreadFactory控制线程数与命名，而非优先级 - 对I/O密集型任务使用
ForkJoinPool.commonPool()或专用ThreadPoolExecutor，避免饥饿 - 关键路径用
LockSupport.parkNanos()或Phaser.awaitAdvance()做精确协作，而非抢CPU - 需要硬实时响应？必须脱离JVM——用JNI调用实时Linux补丁（PREEMPT_RT）或迁移到Zephyr等RTOS
线程优先级最现实的用途只剩日志标记和调试辅助：Thread.currentThread().setName("IO-Worker-P5")比setPriority(5)有用得多。
