线程优先级是弱提示而非执行保证，须在start()前设为1–10并用官方常量；linux下基本无效，不可替代同步机制。
设置线程优先级不能靠“越高越好”，关键在明确目的、控制范围、避开平台陷阱。它不是执行顺序的保证，而是一个弱提示——用对了能微调响应性，用错了反而引发饥饿或误导。
优先级取值必须严格在 1–10 范围内
Java 规范强制要求：低于 1（如 0）或高于 10（如 11）会直接抛 IllegalArgumentException。务必使用官方常量：
- Thread.MIN_PRIORITY → 值为 1，适合日志归档、指标上报等后台低敏感任务
- Thread.NORM_PRIORITY → 值为 5，绝大多数业务线程应保持此默认值
- Thread.MAX_PRIORITY → 值为 10，仅限极少数需抢占式响应的场景（如实时音视频帧处理）
必须在 start() 之前设置，且推荐在构造阶段完成
一旦线程启动，setPriority() 调用可能被 JVM 忽略——调度器已介入，修改不再生效。安全做法是：
- 在自定义 Thread 子类的构造方法中立即调用 this.setPriority(...)
- 或在 new 出实例后、调用 start() 前显式设置（不推荐链式调用，易遗漏）
- 避免在 run() 方法里调用 setPriority()，此时线程早已运行
别指望跨平台效果一致，Linux 上基本无效
Windows 会把 Java 的 1–10 映射到 4 个 Win32 级别（Idle/Normal/Above/High），而 Linux 默认所有 Java 优先级都落在 SCHED_OTHER 类中，实际调度权重几乎无差别。实测显示，在多核 Linux 上设 1/5/10 优先级的计算密集型线程，CPU 占用率差异通常小于 3%。因此：
- 在服务端（尤其 Linux 容器环境），不要用优先级做任务分级依据
- 若真需资源倾斜，应配合操作系统级手段（如 cgroups、nice 值）或应用层队列策略
- GUI 应用在 Windows 上可谨慎尝试 MAX_PRIORITY 提升界面线程响应，但不可泛化
永远不用优先级替代同步机制
它不提供内存可见性、不保证执行先后、不防止竞态条件。高优先级线程仍可能被阻塞、被抢占、甚至因 I/O 等待而长时间挂起。真正需要确定协作逻辑时，应选择：
- synchronized 或 ReentrantLock 控制临界区
- CountDownLatch / CyclicBarrier 协调启动时机
- CompletableFuture 编排异步依赖
- BlockingQueue 实现生产者-消费者解耦
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
