Java采用抢占式调度，JVM将线程映射为OS原生线程，由操作系统按优先级、就绪状态等动态调度；多核下表现为“跨核并行+单核抢占”，分时调度仅在单核内部局部轮转，不保证全局均分时间片。
Java 多线程在多核处理器上运行时，分时调度和抢占式调度不是互斥的两种“切换方式”，而是不同层级的抽象机制：分时调度是操作系统层面为单核设计的经典模型；而 Java 实际依赖的是抢占式调度，且该策略在多核环境下自然延伸为“跨核并行 + 单核抢占”的混合执行形态。
抢占式调度是 JVM 的实际行为基础
Java 虚拟机不自行决定线程何时运行，而是将线程映射为操作系统的原生线程（1:1 模型），由底层 OS 调度器统一管理。现代主流 OS（Linux/Windows/macOS）全部采用抢占式调度——它依据线程优先级、就绪状态、时间片耗尽或阻塞事件，动态决定哪个线程获得 CPU 核心的使用权。
- 优先级高的线程更可能被选中运行，但不保证绝对先执行；JVM 默认优先级为 5，可设为 1–10，仅作提示，不具强制性
- 当一个线程在某个核心上运行时，若被更高优先级线程抢占，或主动进入阻塞（如 wait/sleep/io），OS 会立即切换上下文，让出该核心
- 多个高优先级线程可能同时分布在不同物理核心上并发执行，这正是多核带来的真正并行性
分时调度在多核下表现为“单核内轮转”而非全局平均分配
分时调度强调“所有线程轮流使用 CPU，均分时间片”，这种模型在单核时代有意义。但在多核环境中，它只在每个物理核心内部局部生效：OS 会对每个核心上的就绪线程队列做时间片轮转，但不同核心之间无同步轮转机制。
- 比如 4 核 CPU 上有 8 个就绪线程，OS 可能将其中 2 个调度到核心 0，另 2 个到核心 1……各核独立维护自己的调度队列和时间片计数
- 不存在“8 个线程一起被均分 1ms 时间片”的全局协调；更常见的是：核心 0 上的线程 A 运行 10ms 后被中断，核心 3 上的线程 B 已连续运行了 15ms
- Java 程序员无法控制线程绑定到哪个核心（除非用 JNI 或特定库如 Affinity，但这属于 OS 层优化，非 JVM 规范）
真正影响执行效果的是线程状态与调度边界
Java 中线程是否能获得 CPU，关键不在“调度算法名字”，而在其是否处于 RUNNABLE 状态，以及是否被 OS 认为可调度。以下情况会打破理想化的轮转或抢占预期：
立即学习“Java免费学习笔记（深入）”；
- 线程调用 sleep()、wait()、join() 或发生 I/O 阻塞时，自动退出可运行队列，不参与当前调度竞争
- 同步块（synchronized）或显式锁（ReentrantLock）导致线程因争抢 monitor 而进入 BLOCKED/WAITING 状态，此时即使优先级高也无法获取 CPU
- 频繁的上下文切换（如大量短任务+高线程数）会放大调度开销，反而降低吞吐量——这时线程池比裸线程更可控
开发者应关注可观察行为，而非调度术语本身
写代码时不必纠结“我的线程现在走的是分时还是抢占”，而要聚焦于如何让线程状态更可控、协作更明确：
- 避免依赖线程优先级做逻辑正确性保障（例如不能靠 setPriority(10) 来确保某任务一定先完成）
- 用 ExecutorService 管理线程生命周期，比手动 new Thread() 更利于资源复用与调度稳定性
- 监控工具如 jstack 查看线程状态（RUNNABLE/BLOCKED/WAITING），比分析调度算法更能定位卡顿根源
