Java线程执行顺序由操作系统调度器决定，JVM不干预；setPriority()基本无效；需用CountDownLatch等同步机制而非调度策略控制顺序。
Java线程调度由操作系统决定，JVM不保证执行顺序
Java线程的执行顺序不可控，根本原因在于 Thread 被启动后，实际由底层操作系统（如 Linux 的 CFS 调度器或 Windows 的优先级驱动调度）分配 CPU 时间片，JVM 只负责将 Runnable 映射为 OS 线程（1:1 模型），并不干预具体调度逻辑。这意味着即使你按 t1.start(); t2.start(); t3.start(); 顺序调用，t2 完全可能比 t1 先拿到 CPU 并执行——这不是 bug，是设计使然。
常见错误现象包括：
- 反复运行同一段多线程代码，控制台输出顺序每次都不一样
- 误以为
join()能“让线程排队执行”，其实它只阻塞当前线程，不影响其他线程的调度竞争 - 在没有同步手段时，依赖
System.currentTimeMillis()或Thread.getId()推断执行先后，结果不可靠
为什么 setPriority() 几乎没用
Thread.setPriority() 在绝大多数现代 JVM（HotSpot）和操作系统上已失效。Linux 忽略线程优先级（除非用 chrt 配合实时调度策略），Windows 对 Java 线程的优先级映射也极粗糙，且 JVM 自身会在线程状态切换时重置优先级。实测中，把一个线程设为 MAX_PRIORITY 并不能让它“一定先跑”或“多占 CPU”。
真正影响调度权重的因素通常是：
立即学习“Java免费学习笔记（深入）”；
- 线程是否处于
RUNNABLE状态（而非WAITING或BLOCKED） - 是否刚从 I/O 或锁等待中唤醒（OS 调度器倾向给予短暂 boost）
- CPU 核心数与活跃线程数的比例（争抢越激烈，顺序越随机）
想控制执行顺序？别靠调度，靠显式同步
如果你需要严格顺序（比如 A→B→C），唯一可靠方式是用同步机制“阻断”后续线程，直到前序完成。典型做法有：
- 用
CountDownLatch：A 执行完countDown()，B 在await()后开始 - 用
Phaser或CyclicBarrier实现阶段式协同 - 用
BlockingQueue做生产者-消费者串行化（A 放入，B 取出再放，C 再取） - 避免用
wait()/notify()手写，易漏 notify 或虚假唤醒
示例：强制两线程顺序执行
CountDownLatch latch = new CountDownLatch(1);
Thread t1 = new Thread(() -> {
System.out.println("A done");
latch.countDown();
});
Thread t2 = new Thread(() -> {
try { latch.await(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); }
System.out.println("B done");
});
t1.start(); t2.start();
ExecutorService 也不能保证提交顺序就是执行顺序
ExecutorService.submit() 或 execute() 的调用顺序，只决定任务进入队列的顺序，不决定谁先被线程池中的工作线程取出执行。尤其在 newCachedThreadPool() 或核心线程数 > 1 的 FixedThreadPool 中，多个空闲线程会同时从队列头争抢任务，结果仍是随机的。
若需保序，必须：
- 用单线程池：
Executors.newSingleThreadExecutor()—— 此时任务严格 FIFO 执行，但失去了并发意义 - 在任务内部加锁或使用
CompletableFuture.thenRun()链式编排 - 避免混用不同线程池的任务依赖，容易因线程复用导致死锁或时序错乱
最常被忽略的一点：你以为的“顺序问题”，很多时候其实是可见性问题（比如没用 volatile 或同步块，导致线程读到过期变量值），而不是调度本身。先确认是不是真被调度搞乱了，还是只是内存模型在捣鬼。
