做Linux性能排查和内核开发这几年，我经常被问到同一个问题：进程到底是怎么被安排到CPU上运行的？这个问题看似简单，但真要说透，绕不开Linux调度器。它是内核最核心的组件之一，负责在多个可运行任务之间分配CPU时间，直接决定了你的程序是流畅如飞还是卡成幻灯片。这篇内容只说基础，适合刚接触内核调度、或者做性能优化时想搞懂底层机制的同学。我会把调度器的工作逻辑、关键策略、常见坑都拆开讲，尽量不堆术语，但该有的内核细节也不会少。
1. 先搞清楚调度器到底在调度什么
1.1 进程、线程与调度实体
很多人把进程和线程当成同一个东西，但在调度器眼里，它俩根本不是一回事。Linux内核里的调度单位是task_struct，也就是任务结构体。一个进程可能包含多个线程，每个线程都有自己的task_struct，所以线程才是真正被调度器安排到CPU上运行的对象。换句话说，进程是资源的容器，线程是执行的载体。
调度器真正面对的是“可运行任务”，内核里统一称为sched_entity，直译是调度实体。在传统调度器里，调度实体直接对应一个线程；在带组调度的内核版本里，调度实体还可以是进程组、容器之类的集合。理解这一点很重要，因为后面讲CFS时，你会看到调度器不是简单地按“进程”排队，而是按调度实体在分配CPU时间。如果你只盯着进程PID分析，很容易被表象误导。
举个我实际遇到的例子。某个服务开了32个线程，另一个服务只有一个线程，但两个服务设置的nice值相同。此时调度器不会让两个服务各占一半CPU，而是让32个线程所在的进程获得绝大多数CPU时间。因为每个线程都是一个独立的调度实体，调度器按“实体数量”而非“进程数量”来分时间。很多同学第一次排查CPU占用时看不懂，就是没绕明白这个弯。
1.2 进程状态与调度时机
调度器只对“可运行状态”的进程感兴趣。Linux进程状态很多，但核心就几个：R（Running或Runnable）、S（Sleeping）、D（不可中断睡眠）、T（停止）、Z（僵尸）。其中D状态比较特殊，通常发生在进程等待磁盘I/O时，任意信号都打断不了它。排查系统负载时，如果看到大量D状态进程，往往意味着I/O瓶颈，而不是CPU调度问题。
调度时机也很有意思。你可能以为调度器是“每隔一段时间”才跑一次，实际上它是由事件触发的。主要触发点有几类：第一，进程主动让出CPU，比如调用sleep()、yield()，或者等锁、等I/O；第二，时钟中断到来，当前进程用完了时间片，调度器要检查是否有更高优先级任务；第三，进程被唤醒，比如I/O完成，新唤醒的进程可能抢占当前进程；第四，硬件中断或系统调用返回时，内核会借机检查是否需要重新调度。
其中“抢占”是需要单独拎出来说的概念。早期Linux用的是协作式调度，进程不主动让出CPU，别人就没机会跑。现在内核默认支持抢占式调度：一个进程即使正在运行，只要另一个进程更“急”，内核也可以强行打断它，把CPU交出去。这个机制极大提升了交互式应用的响应速度，但也带来了更复杂的并发安全问题。作为应用开发者，你可以不用管抢占的底层实现，但心里要清楚：你的进程随时可能被中断，任何对共享数据的访问都得考虑并发安全。
2. 选择调度策略：常见的几种调度器与算法
2.1 CFS 是怎么做到“公平”的
从2.6.23内核开始，Linux默认调度器换成了CFS，全称Completely Fair Scheduler，完全公平调度器。它取代了之前的O(1)调度器，核心思想从“按时间片轮转”变成了“按比例分配CPU时间”。
CFS的目标是让每个调度实体获得的CPU时间与其权重成正比。权重由nice值决定，nice值越小，权重越大。它不像老式调度器那样给每个进程固定一个时间片，而是维护一个叫vruntime的虚拟运行时间。每个进程运行后，vruntime都会增加，增加的速度和进程权重成反比。权重高的进程，vruntime涨得慢；权重低的进程，vruntime涨得快。调度器每次选择vruntime最小的进程投入运行，这样就保证了“跑得少的进程优先跑”，天然实现了公平。
这里有个常见误区：CFS不是让所有进程“平均”运行，而是“按权重公平”。一个nice值为0的进程和一个nice值为5的进程，在同等条件下，前者获得的CPU时间远多于后者。所谓“完全公平”指的是：如果两个进程权重相同，它们得到的CPU时间才完全一样。把这个想清楚，后面调优就不会犯低级错误。
2.2 nice 值、优先级与权重的关系
nice值是Unix世界的老古董，范围是-20到19，默认0。数值越小，进程越“不客气”，优先级越高；数值越大，进程越“谦虚”，优先级越低。但nice值只是一个对外接口，内核内部会把它映射成权重。映射关系大致是：每降低1个nice值，权重增加约1.25倍。换句话说，nice值每差1，CPU时间分配差25%左右，这不是线性关系，而是指数关系。
另外，实时进程和普通进程的优先级体系是分开的。普通进程的优先级范围是100到139（对应nice值-20到19），数值越小优先级越高。实时进程的优先级范围是0到99，比所有普通进程都高。这里说的优先级指的是进程的静态优先级，内核里还有一个动态优先级概念，但我们已经很少直接操作它了。
我见过不少开发者用nice命令调进程优先级，结果发现“没效果”，原因是他们调的进程根本不是CPU密集型的，而是在等I/O。比如一个进程大部分时间在等网络数据包，你把它的nice值调低，它也不会多消耗CPU，因为调度器只能在进程可运行的时候才有机会分配CPU。排查的时候先看进程到底在干什么，再决定要不要调优先级。
2.3 实时调度策略：SCHED_FIFO 和 SCHED_RR
除了默认的CFS（对应SCHED_NORMAL或SCHED_OTHER），Linux还有两种实时调度策略：SCHED_FIFO和SCHED_RR。这两个都是POSIX标准里的实时调度策略，内核为它们单独维护了实时运行队列，优先级范围是0到99，数字越大优先级越高。
SCHED_FIFO的意思是先入先出。一旦一个SCHED_FIFO进程进入运行状态，它会一直占用CPU，直到自己阻塞、主动让出、或者被更高优先级的实时进程抢占。注意，普通进程根本没有机会跟它抢CPU，即使普通进程的nice值调成-20也不行。所以把一个CPU密集型的进程设成SCHED_FIFO，如果代码里没有sleep()或者让出CPU的操作，系统上其他普通进程可能全部得不到响应，连SSH都可能卡住。
SCHED_RR是带时间片的轮转调度，可以理解成SCHED_FIFO加上时间片限制。同一优先级的SCHED_RR进程会轮流执行，每个进程运行一段时间后，即使没主动让出CPU，也会被调度器切换到同优先级的另一个进程。但高优先级的SCHED_RR进程仍然能抢占低优先级的SCHED_RR进程。
3. 核心概念拆解：虚拟运行时间与调度周期
3.1 虚拟运行时间 vruntime 的原理
CFS最有代表性的设计就是vruntime。要理解它，可以先忽略“虚拟”二字，想象一个平均数：每个进程都有一个“已经获得CPU的时间”计数器，但每个进程的计数器增长速度不同。权重高的进程，计数器走得慢；权重低的进程，计数器走得快。调度器每次都挑计数器最小的进程去跑。
为什么要把“实际运行时间”转成“虚拟运行时间”？因为不同权重的进程，跑同样的物理时间，公平性不一样。假设A进程权重是B的两倍，那么A运行1秒钟，在公平性层面只相当于B运行2秒钟的一半，也就是0.5秒。所以A的vruntime只增加0.5，B的vruntime增加1。调度器比较的是这个“归一化”之后的值。
CFS用红黑树来维护所有可运行进程的vruntime，每次从树的最左节点取出最小值，这个动作的时间复杂度是O(log N)，非常高效。当进程运行一段时间后，它的vruntime变大，会被重新插入红黑树中适当的位置。这种数据结构设计，让CFS在大量进程并发时依然能保持稳定。
3.2 调度周期和最小粒度
CFS引入了一个重要参数：调度周期sched_latency_ns，默认值通常是6毫秒。它的含义是：在理想情况下，所有可运行进程在1个调度周期内至少都会被调度一次。假如系统里只有两个权重相同的进程，那么每个进程在每个周期里大约运行3毫秒。如果进程数增多，单个进程分到的时间会变少，但CFS还有一个底线叫min_granularity_ns，默认0.75毫秒。每个进程至少能运行这么久，否则切换开销可能大过实际工作收益。
这就是为什么你写循环程序时，明明有100个线程在跑，每个线程看起来都时不时被暂停一下。调度器必须保证每个线程都有机会运行，同时避免频繁切换带来的性能损失。调度周期和最小粒度就是在这两个目标之间找平衡。
这两个参数会互相影响。进程很多时，如果所有进程都想在当前调度周期内各跑一次，但平均分到的时间已经小于最小粒度，CFS就会延长调度周期。这是内核的自我保护机制。排查高并发场景下的性能问题时，如果发现上下文切换次数特别高，可以先看看是不是调度周期被压缩得太紧、或者线程数太多。
3.3 新进程的 vruntime 起步值
新创建进程时，它的vruntime起点不是0，而是一个经过计算的值。如果直接从0开始，新进程会因为vruntime太小而长时间霸占CPU，老进程会饿肚子。内核做法是：新进程的vruntime起点设为当前运行队列中vruntime的最小值，并且还会减去一个额外的滞后值。
这个设计有讲究。为什么要减去一点？为了让新进程有轻微的“抢占优势”，保证它启动后能尽快获得CPU，改善交互体验。但是也不能减太多，否则新进程会长时间压制老进程，造成不公平。内核里这个偏移值跟进程的nice值权重有关，权重高的进程偏移量会相对小一些，不至于让一个高权重的新进程把所有CPU都抢走。
我建议你记住这个结论：新进程不会一出生就被饿死，也不会一出生就碾压全场，它处在“略占便宜”的位置。实际写程序时，如果你反复创建和销毁短生命周期进程，这些新进程的调度优势不会太明显，因为它们的运行总时长本来就很短，对整体公平性影响不大。
4. 从内核配置到实战：查看和调整调度器行为
4.1 查看当前调度策略和优先级
想确认一个进程到底用的哪个调度器，最简单的方式是chrt命令。例如：
chrt -p 1234输出会显示policy和priority。policy那一栏可能是SCHED_OTHER、SCHED_FIFO或SCHED_RR。如果你用的发行版比较新，显示更友好。也可以用ps命令：
ps -o pid,psr,pri,ni,comm -p 1234其中pri是内核视角下的优先级数值，ni是nice值。注意，ps输出的pri和POSIX线程优先级不是一回事，别直接拿来跟chrt的priority对比。看实时优先级还是要以chrt或者/proc/<pid>/sched里的内容为准。
如果想批量看系统里所有实时进程，可以扫描/proc目录：
for pid in $(ls /proc | grep -E '^[0-9]+$'); do chrt -p "$pid" 2>/dev/null; done这条命令只是示意，生产环境建议用优化版本，避免输出刷屏。排查实时进程是否过多时，我看ps -eo pid,comm,rtprio，配合排序会更快。此外，/proc/<pid>/sched文件里有很多CFS运行统计，比如nr_switches、vruntime等，做深度分析时很有用。
4.2 修改调度策略与 nice 值
普通进程调nice值，用nice命令启动新进程，用renice调整已有进程。比如把一个已经跑起来的编译任务调低优先级，避免影响线上服务：
renice -n 10 -p 2048这条命令把PID 2048的nice值调整为10，也就是降低它的CPU优先级。普通用户只能调高nice值（更“谦虚”），不能调低；只有root或者具备相应权限的用户才能调低nice值。
如果想把一个进程改成实时调度策略，用chrt：
chrt -f -p 10 2048这会把PID 2048设为SCHED_FIFO，优先级10。注意，优先级10在实时范围内的数值并不高，但即便如此，它仍然可以抢占所有普通进程。另一个常见用法是chrt -r -p 20 2048，设置SCHED_RR策略。设定之前一定要想清楚，尤其是对CPU密集型线程，别随手就把SCHED_FIFO挂上去，否则可能把整个系统拖死。
4.3 通过内核参数调整 CFS 行为
CFS的核心参数集中在/proc/sys/kernel/sched_*下。常用的是这几个：
sched_schedlatency_ns sched_min_granularity_ns sched_wakeup_granularity_ns sched_child_runs_first sched_autogroup_enabledsched_child_runs_first设置为1，表示fork子进程后让子进程先运行。这个参数在部分负载下能改善响应延迟，但也会改变原有进程的执行顺序，改的时候要谨慎。sched_wakeup_granularity_ns控制唤醒进程抢占当前进程的阈值，值越小，唤醒的进程越容易抢占当前进程，桌面交互会更跟手，但上下文切换开销也会增加。
还有一个容易被忽略的参数：sched_autogroup_enabled。它默认通常是开启的，内核会自动把同一次会话中产生的进程放到一个自动分组里，按组分配CPU时间。这个特性是为了改善终端和桌面环境下的响应度。但如果你在一个SSH会话里跑了多个CPU密集型任务，又想单独调nice值控制它们之间的优先级，自动分组的存在可能让调整“失效”——因为时间按组分配，组内的nice值调整作用被稀释了。我和同事排查过类似问题，最后发现就是autogroup在捣乱。改参数用sysctl或者直接写/proc文件都行：
sysctl -w kernel.sched_autogroup_enabled=0不过这会改变整机调度行为，测试环境随便试，生产环境建议先在灰度机器上验证。
5. 常见问题与排查技巧实录
5.1 为什么我的进程响应变慢了
最常见的场景是：一个后台服务CPU占用长期100%，但用户感觉响应突然变慢。第一反应通常是看CPU使用率，但CPU满不代表调度有问题。你要确认的是服务有没有“饿着”，也就是它的可运行状态线程是否经常得不到CPU。
我习惯先看/proc/loadavg和top里的运行队列长度，再看具体线程的状态。如果大量线程处于R状态却拿不到CPU，多半是CPU资源本身已经用完，或者有更高优先级的实时进程霸占了CPU。这时候可以用perf top或者ps -eo state,pid,comm | grep '^R'看看当前到底是谁在抢时间。记住，调度器本身没有“故意冷落”你的进程，它只是按规则办事，问题往往出在资源超卖或优先级配置不合理。
5.2 CPU 占用高但调度正常吗
CPU占用高并不可怕，可怕的是高占用伴随大量上下文切换。上下文切换可能来自线程间竞争、锁等待或者时间片耗尽。可以用vmstat 1或pidstat -w观察系统的cs（context switch）列。如果每秒上下文切换动辄几十万甚至上百万，说明系统切换开销已经占了大量CPU时间，真正的业务计算反而被挤占。
这种情况下，先检查线程数是否过多。一个进程开1000个线程，每个线程都在做一点点小工作，调度器需要在它们之间频繁切换，效率极低。我的排查思路是：先用pstree -p或top -H看线程数，再用perf sched record记录调度事件，最后用perf sched latency分析每个线程的等待时间。这个工具能直接告诉你哪个线程睡得最久、哪个线程频繁被抢占。
5.3 实时进程导致系统卡顿
这是比较经典的生产事故。某个服务为了降低延迟，把所有工作线程都设置成SCHED_FIFO，优先级还很高。结果一次突发流量让这些线程长时间占用CPU，系统上其他进程，包括SSH、监控agent，全都得不到调度。表面看CPU是空的，因为实时进程可能只在某些核上跑，但普通进程上不了CPU，整机就像冻住一样。
遇到这种情况，如果还能登录，立刻用chrt -p -o 0 <pid>把出错进程改回普通策略。如果已经卡到无法登录，只有重启。所以在设置实时优先级前，一定要评估工作量：实时线程里不能有长循环、不能有自旋等待、不能依赖调度器来让出CPU。如果业务代码里很有可能出现长时间占用，就不要用SCHED_FIFO，可以考虑SCHED_RR并设置较低优先级。
另外，SCHED_FIFO和SCHED_RR进程在多核CPU上默认也不是“锁死”在某个核上的，它同样可以被迁移。但实时进程通常会绑定CPU，避免缓存失效。绑定后再调度到其他核，反而会导致缓存命中率下降。这个问题容易被人忽略。
5.4 进程与线程的调度差异
前面提到线程才是调度实体，但实际开发时，很多人依然用ps -L查看线程，用taskset帮进程绑定CPU，却忘了线程可以跑在别的核上。taskset -p查看的是进程主线程的CPU亲和性掩码，如果进程创建了多个线程，它们各自可能有不同的亲和性设置，只改进程的亲和性未必生效。
正确的做法是用taskset -p -c指定具体线程，或者使用pthread_setaffinity_np()在代码里控制。如果你希望一个进程的线程都跑在特定CPU上，最简单的方式是在线程创建后，逐个用taskset绑定。还要注意，实时调度线程和普通线程的迁移策略不同，低优先级线程在CPU空闲时可能被迁移到任意核，实时线程则倾向于维持在一个核上。这些细微差异，在高性能计算场景下会让你抓狂，所以排查时一定要分清PID和TID。
6. 一些我踩过的坑和心得
6.1 别把优先级当成银弹
我见过一些优化经验贴，遇到性能问题就让“把nice调低”“设成实时”，听起来很省事，实际上副作用很大。先想明白性能瓶颈在哪里：如果是锁竞争，调优先级只是让任务在锁上等得更久；如果是I/O瓶颈，调优先级也不会让磁盘变快。优先级只能影响CPU调度顺序，不能解决资源不足。真正需要调整优先级的情况很少，多数问题靠减少线程数、降低竞争、优化代码结构就能解决。
6.2 nice 值不是线性调节
如果你要调整nice值，对变化有预期。nice值每差1，CPU时间大约差1.25倍。也就是说，你从nice=0调到nice=-5，理论上能获得约3倍于之前的CPU时间。但是这只在所有进程都吃满CPU时才严格成立，如果系统负载低，nice值根本没多大区别。所以调优时，先用top确认CPU是否跑满，再决定是否动nice值。别一上来就renice -n -20，以为能“起飞”，实际上可能只是心理安慰。
6.3 多核负载均衡与CPU亲和性
调度器不止要决定“谁先跑”，还要决定“在哪个核上跑”。内核的负载均衡机制会定期把任务从高负载核迁移到低负载核。这个机制对缓存不太友好，因为进程迁移后，之前在L1/L2缓存里的数据全部失效。所以对性能敏感的程序，我经常建议用taskset把关键线程绑定到固定的核上，关闭自动迁移。但绑核也会带来新问题：如果绑定的核上还有其他高负载任务，你的线程只能排队，不能利用其他空闲核。
正确的做法是区分场景。数据库、网络中间件这类延迟敏感型服务，绑核往往有好处；普通后台批量任务，别绑，让调度器自由调度更省心。还可以用cgroup的cpuset子系统和irqbalance做更细粒度的控制，但基础阶段先学会taskset就够了。
最后再分享一个小技巧。分析调度行为时，不要只盯着top，可以看看/proc/<pid>/schedstat文件，里面有进程的运行时间和等待时间。用两次采样做差值，就能算出真实等待比例。如果等待时间占比很高，说明调度器给的时间不够，或者有更高优先级任务抢跑。搞懂这些基础概念，再遇到“进程为什么慢”这类问题，心里就有谱了。
