1. 时间片是怎么来的：多个线程抢一个CPU时发生了什么
先讲一个我真实遇到过的场景。有段时间我在给一个并发任务做压测，机器是8核，业务逻辑也简单，就是一个纯计算任务，按道理应该把8个核吃满。结果压测发现CPU利用率只有130%左右，程序跑得反而比单线程还慢。当时第一反应是代码里是不是有锁竞争、有IO等待，排查了半天没发现问题。最后usingtop看到进程下有30多个线程在抢那8个核，问题才慢慢浮现出来——线程之间频繁地切换、抢占、让出，时间都浪费在了调度本身上。
这就是理解Java线程调度最关键的一点：操作系统里的CPU核数是有限的，但并发线程数可以远超核数。一台8核机器上开50个线程，同一时刻真正在执行指令的只能有8个，剩下的42个要么在等待CPU，要么在等待锁和IO。那么问题来了：这8个核，到底分配给哪8个线程？每个线程能跑多久？谁来确保没有线程被饿死？
答案就是时间片（Time Slice）。时间片是操作系统分配给每个线程的一段连续执行时间，线程在这个时间里独占CPU，时间用完了，调度器就会把它换下去，让另一个线程上来。这个“换人”的动作，就是上下文切换（Context Switch）。
我用一个生活化的例子解释。想象10个人排队用一台打印机，每个人打印得差不多了，后面的人就得等着。时间片就是“每个人最多打印5分钟”，5分钟一到，不管有没有打完，都让下一个人来。如果时间片太长，比如允许一个人打印一天，那排在后面的人就会等崩溃；如果太短，比如允许每人打印1秒，那大家大部分时间都在起身让座、重新摆弄文档上，真正打印的时间反而少了。
在操作系统层面，这个“让座”可不是站起来就走那么简单。上下文切换要保存当前线程的寄存器状态、程序计数器、内存栈指针，还要把下一个线程的这些数据恢复回来。这个过程本身要消耗CPU时间，而且切换之后，新线程刚加载进来的数据在CPU缓存里可能是“冷”的，访问速度会变慢。一次上下文切换看起来只有几微秒，但服务器上每秒可能发生几千次甚至几万次切换，积少成多就是一个不小的开销。
理解了这个，Java开发者应该意识到两件事：第一，线程不是开得越多越好，线程多了调度开销会侵蚀掉并行带来的收益；第二，Java本身不直接控制时间片的大小，它完全交给操作系统。所以要想真正搞懂Java线程调度，第一步是搞懂底层的时间片机制，而不是先在Thread类上找答案。
顺带说一句，如果你在面试里被问到“Java线程调度原理”，一上来就背synchronized和锁的八股文并不是重点。面试官真正想听的，往往是你对时间片、上下文切换、操作系统调度器这些底层概念的理解，以及你知不知道Java线程最终是映射到操作系统线程上的。
2. 时间片的长短不是拍脑袋：CFS和反馈队列的取舍逻辑
既然时间片这么重要，那它到底是怎么定的？很多人以为时间片是一个固定值，比如Linux每10毫秒切一次。其实早期的Linux确实有这个倾向，内核大约每10毫秒产生一次时钟中断，处理完中断就可能触发调度。但随着系统越来越复杂，固定的时间片已经不够用了，原因很容易理解：一个纯计算的线程和一个正在等用户输入的线程，它们的调度需求完全是相反的。
计算型线程希望一次拿到足够长的时间片，赶紧把活儿干完，中途不要被打断；交互型线程恰恰相反，它通常是“等一会儿事件→处理一下→又去等”，它希望自己一进入可运行状态就立刻被调度到，而不是排队等上几十毫秒。如果固定时间片太长，交互型应用会感觉到明显的卡顿；固定太短，计算型任务会频繁被切换，白白损失性能。
现代Linux采用的CFS（Completely Fair Scheduler，完全公平调度器）换了一个思路：不搞固定时间片，而是追求“虚拟运行时间”的公平。每个可运行的线程都有一个vruntime，记录它累计运行的虚拟时间。调度器每次都选vruntime最小的那个线程来运行，也就是说，谁运行得少，谁优先上CPU。这样天然公平，谁也别想饿着。
那vruntime和实际运行时间的区别在哪？这就涉及到优先级了。CFS给每个线程分配一个权重，权重高的线程vruntime增长得慢，它的“虚拟时间走得慢”，于是实际获得的CPU时间反而更多。这个权重和nice值挂钩，nice值每差一档，权重大约相差25%左右。nice值越小，权重越高，在CFS眼里越“受照顾”。
举个例子：两个线程A和B，A的nice值比B低5档，权重就差不多是B的三倍多。它们在同样的真实运行时间里，A的vruntime增长速度远慢于B。调度器看到B的vruntime比A大，就会更倾向于选A。结果是A获得大约75%以上的CPU时间。所以你看，在Linux上“优先级”不是直接决定谁先跑的硬规则，而是通过影响vruntime增长速度来分配的软规则。
CFS还引入了目标延迟（sched_latency）和最小粒度（min_granularity）两个参数。目标延迟是调度器的“周期目标”，比如默认6毫秒；最小粒度是线程每次最少能获得的时间，比如0.75毫秒。当可运行线程数少的时候，时间片可以宽裕一些；当线程数多了，就按目标延迟除以线程数来计算单个线程的时间片，但不得小于最小粒度。这样设计保证了：线程少时切换少、吞吐高，线程多时响应快、延迟可控。
除了CFS，经典的调度算法里还有一个概念叫多级反馈队列（MLFQ），现在很多系统也会借鉴它的思想。它的核心逻辑是：把就绪队列分成多个优先级层次，新线程先进入最高优先级队列，给一个较短的时间片；如果这个线程用完了整个时间片还没完成，说明它是计算型的，就把它降到下一级队列，下一级的时间片更长一些；如果线程在执行中间就主动让出CPU（比如在等待IO），说明它是交互型的，就把它留在当前优先级的队列头部，下次优先调度。这样交互型任务响应快，计算型任务虽然优先级降下来了，但时间片更长，也不会饿死。
讲了这么多操作系统层面的调度算法，你可能会问：那Java里能不能调时间片？答案是：不能，也不建议。JVM本身是跨平台的，Windows、Linux、macOS的调度策略各不相同，JVM不可能让你用一套代码去精确控制每个平台的时间片。Java能做的极限，就是通过线程优先级和yield、sleep之类的方法向调度器传递“建议”，至于操作系统听不听，那要看它自己的算法脸色。
这里有一个关键点需要记住：在现代操作系统上，调度器往往比程序员更聪明，它会根据线程的实际行为不断调整调度决策。你手动干预得越多，反而可能越帮倒忙。
3. Java线程调度模型：从Thread.start()到内核线程的真实映射
现在回到Java本身。Java的线程机制和操作系统线程到底是什么关系？答案很明确：在目前的绝大多数JVM实现上，Java线程和操作系统内核线程是一一对应的，这种模型叫1:1模型。
当你new了一个Thread对象，并在代码里调用start()的时候，JVM会通过native方法创建一个真正意义上的操作系统线程。在Linux上，这个创建过程会走到pthread_create，底层是clone系统调用。从这一刻起，你的线程就不再是“Java层面的对象”了，它已经变成一个被内核调度器管理的实体，自己的栈、寄存器状态、调度优先级都真实存在于操作系统里。
既然是一一映射，Java线程的各种状态就能直接映射到操作系统的状态。很多人学Java线程状态时单独背，觉得很简单，但真正排查问题的时候反而容易糊涂，原因就是没建立这个映射关系。我用一个表来说明。
| Java线程状态 | 对应操作系统/内核状态 | 说明 |
|---|---|---|
| RUNNABLE | Running或Ready（就绪） | 线程正在执行，或者等待被调度器选中执行 |
| BLOCKED | Sleeping（在锁上等待） | 线程想进入synchronized块，但锁被其他线程持有，进入阻塞队列 |
| WAITING | Sleeping（条件等待） | 调用了wait/join/park，无限期等待被唤醒 |
| TIMED_WAITING | Sleeping（限时等待） | sleep、带超时的wait/park，时间到了自动醒来 |
| NEW / TERMINATED | 不存在对应OS线程，或线程已销毁 | 对象已创建但未start；或run方法已返回 |
这个表里最容易被误解的就是RUNNABLE。Java的RUNNABLE其实包含了两种情况：一种是正在CPU上运行，另一种是已经就绪、但正在等待调度器给它分配CPU时间片。也就是说，jstack里看到大量RUNNABLE线程，不代表它们都在干活，也可能有一堆在排队等CPU。这一点在后面的排查章节我再展开。
聊到调度，就必须说yield()和sleep(0)。很多初学者把它们当成“让出CPU给别的线程”的救命稻草，实际效果却常常令人失望。Thread.yield()的语义是：当前线程愿意放弃CPU，让自己回到就绪队列的尾部，让同优先级或更高优先级的线程有机会运行。但这个语义在现在的JVM上非常弱。原因有三：第一，现代操作系统根本不怎么按“优先级队列”来调度，CFS只认vruntime，你让出来的CPU分给谁并不受你控制；第二，多核机器上，你让出的CPU核可能空着，其他线程在别的核上跑得好好的；第三，HotSpot在某些平台上把yield直接映射成一个空操作或者一个简单的hint，根本没有实际让出的效果。
sleep(0)其实是比yield更“实在”一点的做法。它可以触发一次线程重调度，让当前线程至少从运行态让出来，哪怕只有一瞬间。我在写高并发监控脚本时偶尔会用sleep(0)来平衡各个采集线程的CPU占用，但它的精度和效果在不同系统上差异也很大，不能当作精确调度工具来用。
还有一个容易忽略的点：每个Java线程的默认栈大小通常是1MB，这1MB是虚拟内存，不一定会都被物理内存占用，但线程数量多了以后，内存开销依然不容忽视。我曾经在生产环境见过一个应用创建了5000多个线程，光是线程栈就占了几GB的虚拟内存，再加上切换开销，整个进程卡到连jstack都快敲不出命令了。后来把线程池压到几百，性能反而恢复正常。
这里延伸一个面试高频问题：既然Java线程是1:1映射内核线程，那创建线程为什么那么贵？除了内核需要分配TCB（线程控制块）之外，还要分配独立的内核栈和用户栈，再加上创建过程中的系统调用开销，比起对象创建来说确实重很多倍。这也是为什么实际生产代码里几乎不用new Thread，而是用线程池来复用线程的原因。
4. 线程优先级和优先级反转：Java里最容易踩的隐性坑
Java的Thread类提供了优先级设置，范围是1到10，默认是5，看起来挺好用，设置个MAX_PRIORITY就能让关键线程多分点CPU。但真实情况远没那么美好，而且这里面有坑。
先搞清楚映射关系。Java的10个优先级在操作系统层面并不会一一对应到调度优先级。Windows有自己的优先级类机制，Linux是用nice值（范围-20到19），两者的映射都不可能做到精确的1:1。更重要的是，在不少Linux版本上，HotSpot JVM根本没有把Java线程的优先级映射成不同的nice值，也就是说，你设置的1到10在Linux上可能统统都变成了同一个nice值。线程优先级表现为“设置了但好像没用”。
为什么会这样？一方面是跨平台实现成本高，另一方面是CFS调度器本身就不信任静态优先级，它更愿意根据线程的实际运行行为做动态调整。一个线程就算你给它设置了MAX_PRIORITY，如果它是个疯狂的计算任务，运行时间长了，vruntime照样会涨上去，它在系统里的“实际地位”并不会比普通线程高多少。反过来，一个IO密集的小线程虽然nice值是默认的，但因为经常主动让出CPU，CFS会把它排在更前面。
那Java优先级这件事是不是完全没用？也不是。在Windows平台上，JVM确实会把Java优先级映射到不同线程优先级类，效果会明显一些。但Linux服务器上，我的建议是：别把它当成功能来用，当成“提示”就好，更不要在业务逻辑里依赖它来保证执行顺序。
比优先级更值得警惕的是优先级反转问题。这个问题在计算机系统里非常经典：一个高优先级的线程（T3）需要访问一个锁，锁被低优先级线程（T1）持有；与此同时，T1被一个中优先级线程（T2）抢占，T2又不需要那个锁，只知道埋头吃CPU。结果就是：T3优先级最高，但拿不到锁；T1优先级低但持有锁却被T2抢占；T2优先级居中但疯狂占用CPU。最终的运行顺序变成了T2 → T1 → T3，高优先级线程反而被低优先级线程拖住了。
优先级反转在操作系统内核里是可以通过“优先级继承”来解决的，也就是当高优先级线程在等待低优先级线程持有的锁时，临时把低优先级线程的优先级提上来，让它可以尽快释放锁。但在Java应用层，JVM并没有提供这种自动机制，所以如果你在业务中混用不同优先级的线程去抢同一把锁，就很可能遇到这种奇怪的卡顿：明明关键线程优先级最高，却感觉被什么东西拖住了，等它跑起来黄花菜都凉了。
给实际工作的建议：第一条，多线程协作完成任务时，用CountDownLatch、Semaphore、CyclicBarrier这类显式同步工具来控制执行顺序，不要用优先级来隐式表达“这个线程应该先跑”。第二条，锁的持有时间越短越好，尤其是不要让低优先级的线程持锁做耗时操作，这会放大优先级反转的伤害。第三条，如果真的需要让某些线程“更被照顾”，与其调优先级，不如从线程数量上做文章——给关键任务单独开一个专用线程池，保证它无论如何都有独立的CPU机会，这比在优先级上较劲靠谱得多。
面试里问到线程优先级的时候，我还比较推荐这套回答思路：先说明Java优先级是一个提示性参数；再说JVM和操作系统之间的映射是有损耗的；最后补一句“依赖优先级来保证执行顺序是一种反模式，应该用显式同步工具”。这样答，深度和实用性都有了。
5. 锁、阻塞与自旋：调度器面前的三个暗礁
如果说时间片和优先级是调度的底层规则，那锁和阻塞就是Java线程在业务代码里真正让调度“翻车”的地方。我调过无数个并发性能问题，发现90%的诡异卡顿，根源都是线程在锁和阻塞上消耗了远超预期的调度资源。
先看最简单的synchronized。当一个线程进入synchronized方法或代码块时，如果锁已经被别的线程持有，这个线程就会进入BLOCKED状态，在操作系统的“锁等待队列”里挂起。这个挂起和唤醒过程不是Java层面能做到的，它要借助操作系统的线程阻塞和唤醒原语，也就是要从用户态切到内核态。一次也就罢了，但如果锁竞争非常激烈，大量线程频繁地在“运行—阻塞—唤醒—运行”之间切换，上下文切换的次数会飙升，CPU大量时间花在调度而不是业务逻辑上。
Java对这个问题的应对是锁优化。JDK从早期开始就给synchronized设计了偏向锁、轻量级锁、重量级锁的升级路径。无竞争时用偏向锁，只有一个线程反复进入时几乎零开销；出现轻微竞争就CAS抢轻量级锁；竞争激烈了才会膨胀成重量级锁，让线程真的去阻塞。这套机制很有效，但它有一个隐含的前提：真正走到阻塞这一步时，代价已经非常高了。所以你在写代码时如果发现某个锁竞争特别激烈，第一步不是继续加锁，而是想办法减少锁的粒度，比如分段锁、读写锁、或者用ConcurrentHashMap兜底。
除了锁，自旋是另一个容易被误解的点。有些场景下，线程拿不到锁并不会立刻阻塞，而是选择“原地转圈再试几次”，这就是自旋锁。自旋的优点是避免了上下文切换，缺点是会白白占用CPU。到底该自旋还是该阻塞？经验法则是看临界区有多长。如果临界区非常短，比如就几个CAS操作，那自旋哪怕浪费一点CPU，也远比切换一次划算；如果临界区较长，比如要做复杂的计算或者IO，那就该果断阻塞让出CPU。JVM里其实有自适应自旋，它会根据上次自旋的结果动态调整自旋时间和次数，这个机制平时不必手动干预，但了解它有助于解释“为什么我的代码看起来在自旋，CPU却烧得很高”。
再看一个我在业务代码里经常见到的坏习惯：用Thread.sleep()来等待异步结果。有个项目里，一个线程调用了远程接口，然后直接sleep(1)，也就是睡1秒再查结果，美其名曰“给接口一点时间”。看上去没什么，但这个线程在sleep期间还持有锁，其他线程全部卡在锁外面等，白白浪费了过去。正确的做法是用线程间通信机制，比如wait/notify、CountDownLatch、或者直接用CompletableFuture和Future的回调，让线程真正“挂起等待被唤醒”，而不是“假装睡觉但占着锁”。排除了sleep轮询之后，锁的等待时间大幅下降，调度器的切换压力也自然缓解了。
再深挖一层，无锁技术在调度友好度上比任何锁都强。CAS（比较并交换）是CPU指令级支持的原子操作，多线程共享一个变量时，用AtomicInteger或者LongAdder就能避免锁竞争和线程阻塞。ThreadLocal则是另一种思路——每个线程一份独立数据，压根不需要共享。不可变对象更是彻底绕开了并发问题，不需要加锁，不会阻塞，调度器自然乐得轻松。这些都是高并发场景下比锁更优雅的方案。
线程池的线程数设置，也和调度开销强相关。之前说过，线程多了切换成本就上来了。生产上一个常用的经验公式是：CPU密集型线程数 = CPU核数 + 1；IO密集型线程数 = CPU核数 ×（1 + 平均等待时间 / 平均计算时间）。注意这只是起步参考值，真实环境必须压测验证。我遇到过不少团队，机器只有8核，线程池配了200个，以为能大幅提升吞吐，结果响应时间反而变高了，因为大部分时间都在切换线程。把线程池调小之后，吞吐量不降反升，CPU使用率反而更稳定。这个反直觉的结果，本质上就是线程调度开销在起作用。
6. 用工具看清调度真相：CPU高但吞吐低的问题排查链路
最后分享一套我在生产环境反复用过的排查思路。当你发现一个Java进程CPU使用率很高，但业务吞吐量却很低，先别急着改业务代码，大概率问题出在调度和资源竞争上。按下面的链路查，基本能定位。
第一步，用top命令看整体负载和上下文切换。top显示的是一整台机器的情况，配合vmstat可以看cs这一列，表示每秒上下文切换次数。如果cs值长期上万甚至十万以上，说明系统里线程切换极其频繁，这时候就算CPU使用率不高，吞吐也会被调度拖垮。多核机器上，尽量的上下文切换次数不应持续处于高位。
第二步，定位到具体的进程和线程。用 top -H -p 可以按线程维度查看CPU占用，找到CPU占用最高的几个线程。记录下它们的线程ID，然后用 printf "%x\n" 转成十六进制，再到jstack导出的线程栈里去对，以 nid=0x... 的方式找到对应的线程。
第三步，重点看jstack输出里的线程状态分布。如果你的线程大量处于BLOCKED状态，说明锁竞争激烈；大量处于WAITING或TIMED_WAITING，说明线程要么在等条件变量、要么在sleep，基本没在干活，但还占着线程资源；大量处于RUNNABLE但并不在计算（比如在自旋），说明锁的临界区设计有问题，线程在原地空转。
我实际处理过的一个案例是：服务有200个线程跑定时任务，每到整点就出现CPU飙高、接口响应变慢。用上面这套方法查下来，jstack里面几百行全都是同一个synchronized方法的等待栈，vmstat的cs值直接翻了五倍。进一步定位发现，所有线程都在抢同一个全局锁来刷新缓存，40多个线程等于在一个锁门前排队。后来我把缓存刷新改成了单线程预热加无锁读取，锁取消之后，CPU占用立刻降了一半，响应时间也稳定了。
更多时候，业务方跟我抱怨“CPU已经爆了”，实际上是没有区分“CPU高”和“忙”。用perf top看一下CPU时间的分布，如果大量时间花在锁相关的指令、或者spinning/spinlock上，那就说明CPU不是被业务逻辑消耗的，而是被并发控制消耗的。进阶的工具可以上async-profiler，出火焰图之后能很直观地看到哪个栈占CPU最多，是锁竞争、是GC、还是真在计算。
第四步，不要忽视JVM自带的工具。Arthas的thread -n 1可以直接列出CPU占用最高的线程，省去了手动转换的步骤。Java Flight Recorder（JFR）则能记录线程阻塞、锁竞争、上下文切换等更细的分析事件，适合做压测之后的离线分析。这些工具各有侧重，但对于“Java线程调度与时间片”主题来说，核心就是回答三个问题：哪些线程在消耗CPU？哪些线程在排队等待？切换是否过于频繁？
排完这些问题之后，你往往会在代码层面找到这样几个方向的优化空间：要么锁竞争过于激烈，要么线程数量超过了硬件承载能力，要么是sleep轮询类代码把线程变成了“僵尸”却还占着资源。
以我个人的经验，多线程调优做得越多，越会感慨：真正让吞吐提升的，往往不是把CPU利用率从80%干到99%，而是把无谓的切换和等待从系统里清出去。调度器是朋友，不是敌人，它已经很努力地在每个时间片里做到公平了。我们要做的，是别用糟糕的并发设计去考验它的耐心。如果你下次再遇到“线程开了很多但速度反而慢”的怪事，先别骂Java，拿vmstat看一眼cs值，拿jstack看一眼线程状态，答案往往就藏在这里。
