刚接手一个服务时，我有个习惯：先跑十分钟top，盯着PR列和NI列看半天。你别笑，线上 CPU 跑满、进程卡死、某个任务抢不到执行机会，很多时候把问题一层层剥离，最后都会落到“进程切换”和“优先级”这两件事上。它们是操作系统教科书里的经典章节，可一旦落到实战，分分钟能让你在凌晨两点抱着监控面板怀疑人生。
这篇文章我准备从原理讲到命令，再讲到实战里的坑。适合两类人：一类是把 Linux 当日常工具、偶尔发现某个进程优先级不对但不敢乱动的开发者；另一类是刚接触系统内核、想弄明白调度器到底在忙什么的学生或运维新人。你先搞懂“为什么”，再照着命令去操作，心里就有底得多。
1. 进程切换：系统在幕后到底忙什么
1.1 一次进程切换，到底切了什么
进程切换也叫上下文切换。拿追剧来打比方，CPU 是一个只能同时看一个频道的电视机，进程就是各个频道的节目。你以为电视一直在流畅播放，其实它每秒钟已经在几百个频道之间来回跳了上万次。观众感觉不到换台，是因为换台速度足够快。系统里的进程切换，做的就是“记忆当前频道播放到哪，然后立刻调到下一个频道”这件事。
这个过程在 Linux 里大概长这样：内核调用schedule()选出下一个要运行的进程，然后调用context_switch()真正切换。切换时需要保存旧进程的“全部现场”，包括通用寄存器、程序计数器、栈指针、标志寄存器、浮点寄存器状态，以及它用到的内存页表信息。这些现场会存到进程自己的task_struct和内核栈里，下次轮到它时再原样恢复。
这里有个容易忽略的细节：每次切换不只是换寄存器，内核栈也要跟着换，因为每个进程在核心态有自己独立的栈。栈一换，用户态地址空间也得换，否则新进程一执行立刻就会访问到别的进程的内存空间。整个动作是纯汇编级完成的，也就是内核里的__switch_to那一串代码。它快，但快不等于没有代价。
1.2 哪些时机触发进程切换
触发进程切换通常有四种场景。
第一种是时间片被耗尽，或者调度器判定当前进程“已经运行太久”，需要让位给其他进程。在现在的CFS调度器里，没有固定时间片的概念，而是通过虚拟运行时间来动态决定谁该被抢占。第二类是进程自己主动让出 CPU，比如它要等磁盘 I/O、等网络数据、调用了sleep、或者获取互斥锁失败。这种情况下进程进入睡眠状态，调度器立刻选别的进程上台。第三类是更高优先级的进程被唤醒，比如实时进程收到了信号，或者某个等待 I/O 的高优先级进程数据到了，内核会检查它是否应该抢占当前进程。第四类是中断处理结束返回时，内核发现need_resched标志被置位，于是趁机会进行一次调度。
日常排查时，区分主动切换和被动切换很有用。主动切换往往表示进程在等待资源；被动切换往往表示进程被内核强制换下去，比如被高优先级进程抢了。你可以用cat /proc/<pid>/status查看voluntary_ctxt_switches和nonvoluntary_ctxt_switches这两个计数器，前者是主动切换次数，后者是被动切换次数。如果被动切换数字猛涨，那就要看看是不是有东西在频繁抢占它了。
1.3 切换的代价，比你想象中大
很多人以为上下文切换只是保存几个寄存器，没什么成本。真这么想，就太小看它了。
寄存器保存恢复本身确实只有几百纳秒量级，但真正的开销大头在间接成本。进程一换，地址空间跟着换，CPU 的 TLB（快表）缓存大量失效，L1/L2 缓存里本来热乎乎的指令和数据也基本白搭了，新进程进来之后又要重新把所需数据从内存慢慢加载。这一来一回，一次上下文切换在几十微秒量级，看起来不算大，但如果每秒发生几万次，那消耗的 CPU 就有好几个百分点，甚至十几个百分点。
你用vmstat 1能直接看到系统每秒上下文切换次数，就是cs那一列。我见过一个极端案例：某服务线程数开得特别多，又到处用锁，上线后cs值飙到每秒十几万次，CPU 光顾着切来切去，实际业务吞吐反而上不去。后面把大量无谓的共享状态拆开、减少锁竞争，cs降了一个数量级，吞吐立刻回来了。所以当服务性能不对劲时，先看上下文切换次数，往往比瞎调参数更有用。
2. 优先级：排队规则与调度设计
2.1 nice 值：从“谦让”说起
Linux 里最常打交道的优先级概念是nice，中文就是“谦让”的意思。默认情况下你启动一个进程，它的nice值是 0，取值范围在 -20 到 19 之间，数值越小优先级越高，-20 是最高优先级的普通进程，19 是几乎“礼让到卑微”的进程。
为什么说nice是谦让而非“优先级”？因为一个 nice 值为 10 的进程并不是优先级降低，而是它主动表示“我不急，你们先跑”。在系统负载不高时，这种谦让几乎感觉不到影响，反正 CPU 闲着也是闲着；一旦系统繁忙，nice 值越低的任务就会越先获得 CPU 资源。
内核内部还有一个更底层的静态优先级概念。对普通进程来说，静态优先级 = 120 + nice 值。也就是说 nice 0 对应内核优先级 120，nice -20 对应 100，nice 19 对应 139。这个数值范围非常重要，你等会看top输出时，会发现普通进程的PR值基本都是 20 起步，原因正在于此。
2.2 实时优先级与普通优先级的分层世界
Linux 的优先级体系其实分两套：实时优先级和普通优先级。实时优先级范围是 0 到 99，数值越小优先级越高，对应SCHED_FIFO和SCHED_RR两种实时调度策略。普通进程的优先级范围是 100 到 139，对应常见的SCHED_OTHER（即默认策略）、SCHED_BATCH和SCHED_IDLE。
这两套世界有个铁律：只要系统里存在一个可运行的实时进程，普通进程就永远靠边站，因为实时调度类拥有绝对优先权。这也是很多新手踩坑的重灾区——某个进程被不小心设置成实时调度，结果普通进程全部陪跑，系统卡成幻灯片。
你还可以用chrt -m查看当前系统支持的调度策略列表和实时优先级范围。多数桌面和服务器环境都会显示SCHED_FIFO优先级范围 1 到 99，SCHED_RR也是 1 到 99。这里有个细节：优先级 0 通常保留了特殊用途，不建议普通应用去设置，所以实际操作时，实时优先级最常见的选择是 1 到 50。
2.3 完全公平调度器（CFS）在公平什么
现代 Linux 默认用 CFS，全称“完全公平调度器”。它其实不是平均分配时间片，而是保证每个进程获得 CPU 的“公平份额”，并且这个份额由优先级来调节。
CFS 的核心数据结构是一棵红黑树，树上的每个节点代表一个可运行的进程，键是vruntime，虚拟运行时间。进程运行得越久，vruntime 就越大，会越来越靠后；调度器每次选最左边的节点，也就是 vruntime 最小的进程来运行。这么做的目的是让所有进程的 vruntime 尽量接近，谁的进度落后了，就多给谁机会。
nice值在这里面起了决定性作用：它对应一个权重表。nice 0 的进程权重是 1024，nice 5 变成 335，nice 10 变成 95，nice 19 只有 15。vruntime 增长速率和权重成反比，权重越高，vruntime 涨得越慢，也就更容易被调度器选中。所以两个进程同时竞争 CPU，nice 0 的任务能拿到大约 91% 的 CPU，nice 10 的任务只能拿到 9%——这不是四舍五入的误差，而是有意设计的倍率关系。
3. 从命令到实战：掌控进程优先级
3.1 三件套命令：top、ps、chrt
真到排查的时候，第一个要会用的是top。进去之后看两列就够了：PR和NI。普通进程的PR值基本等于 20 + nice 值，默认 nice 0 显示 20；如果是实时进程，PR会显示成rt，你一眼就能揪出来。想看哪些进程吃 CPU 最猛，按下大写P按 CPU 占用排序，优先级对实际占用的影响立刻一目了然。
ps命令更清爽，我经常用的一招是：
ps -eo pid,comm,nice,pri,psrcomm是命令名，nice直接展示 nice 值，pri是当前优先级，psr是进程当前跑在哪个 CPU 核上。注意不同发行版对pri列的显示规则略有差异，有些直接显示内核优先级数值，有些做了偏移，别过度纠结它的绝对值，看nice列反而更准确、更通用。
查看某个特定进程的调度策略，可以用chrt -p <pid>。比如chrt -p 1通常会显示SCHED_OTHER，而在某些系统上，init 进程可能采用了其他策略，这也是排查系统行为时的关键线索。
3.2 nice 与 renice：启动时与运行时的调整
启动一个进程时想指定 nice 值，语法很简单：
nice -n -5 ./myapp-n后面接 nice 值，这里 -5 表示提高优先级。注意：负数 nice 值需要 root 权限，普通用户只能在 0 到 19 之间调。
进程跑起来之后才发现优先级不对，就用renice调整。先看一下：
renice -n -5 -p 1234-p指定进程 PID。如果想一次调整整个进程组，可以用-g，调整某个用户的所有进程则用-u。我多次踩过教训：先确认 PID 再动手，别手指一快把 1234 打成 12340，把一个无辜的高优先级任务给“礼让”到泥土里。调完之后记得再用top看下PR是否如预期变化。
3.3 chrt 与 taskset：实时优先级的进阶玩法
chrt是调度策略和实时优先级的总控制台。想把一个正在跑的进程改成 FIFO 实时调度，优先级 50，命令是：
chrt -f -p 50 1234想改成 RR 轮转实时调度，把-f换成-r。还有一种用法是在启动进程时指定策略和优先级：
chrt -f 50 ./myapp在动实时优先级之前一定要想清楚：实时进程会无条件排在所有普通进程前面。为了不让它把一个物理核完全占死，通常要搭配 CPU 绑定。taskset就是干这个的：
taskset -c 2 ./myapp这句把myapp绑到第 2 个 CPU 核上。绑核之后，这个核基本就会变成它的“专属座位”，其它核上的普通进程不会受它影响。做实时调度实验时，我建议永远把“绑核 + 起始低优先级”当成默认姿势，宁可多花两步操作，也不要冒系统被冻死的风险。
4. 排查实录与避坑手册
4.1 权限报错：为什么 renice 被拒绝
总有同学反馈：执行renice -n -5 -p 1234，系统冷酷甩回来一句Operation not permitted。这多数是因为当前用户既不是进程所有者，也没有 root 权限。普通用户只能降低自己进程的优先级，也就是调高 nice 值；想降低 nice 值、提高优先级，必须要有CAP_SYS_NICE权限，这个权限通常只有 root 或容器特权的进程才有。
如果你真需要让某个服务以更高优先级运行，最稳妥的做法是：在启动脚本里用nice -n -5或chrt直接指定，而不是运行之后再去renice。因为很多服务的守护进程会把 nice 值重置回 0，你后续renice可能还会被系统安全策略拦下。另一点是容器环境里，即使宿主机是 root，容器内的默认 capabilities 也未必包含CAP_SYS_NICE，所以容器里改实时优先级会莫名失败，别硬顶着操作，先检查权限模型。
4.2 实时进程把系统“冻住”的惨案
我目睹过一桩极其生动的翻车现场：某同学想给自己的一个用户态程序设置实时优先级，直接chrt -f 99给安排上了。程序本身是个while(1)死循环。启动之后不到十秒，系统鼠标开始卡顿，SSH 半天没有反应，最后只能靠物理重启。原因不难理解：SCHED_FIFO 优先级 99 已经到顶，它独占了一个 CPU 核并且永远主动让出机会，普通进程连排队的资格都没有。如果它没有被绑核，它还会像饿狼一样跳到其它核上继续抢占，把整个系统搞瘫。
正确做法是：第一，从低优先级开始调，比如chrt -f 50或更低，实测确实不够再往上加；第二，第一时间搭配taskset -c绑核；第三，别让实时任务跑无意义的忙循环，如果有条件在循环里加nanosleep让出 CPU，哪怕很小的时间片，对系统整体的“呼吸感”也是巨大的救赎。
4.3 从 /proc 状态看进程被切换的真相
进程为什么被切换掉，单看top很难判断。这时我习惯直接看/proc/<pid>/status里的两个数值：
grep -E "voluntary_ctxt_switches|nonvoluntary_ctxt_switches" /proc/1234/statusvoluntary_ctxt_switches高，说明进程经常主动睡眠或等待资源，常见于 I/O 密集应用和锁竞争严重的多线程程序；nonvoluntary_ctxt_switches高，说明它频繁被调度器或高优先级进程抢占，常见于 CPU 密集任务。配合vmstat 1观察cs列，再配合perf sched latency看调度延迟分布，基本能定位到问题方向。
如果需要更细粒度的切换耗时，可以看/proc/schedstat，里面有每个 CPU 的运行队列统计。说实话这些指标在常规排障时未必每次都用到，但在做性能调优、确认“上下文切换开销占了多少 CPU”这类问题时，它们是打破迷雾的利器。我印象最深的一次优化就是靠/proc/<pid>/status定位到某个线程疯狂被抢占，最后发现是对面有个高优先级进程在不停唤醒该线程竞争锁——问题解决之后，整体性能直接上一个台阶。
我个人在实际排查中慢慢养成了一个习惯：无论什么时候上线新服务，都会先看一眼默认的 nice 值和调度策略。没有特殊需求就不要碰实时优先级，设置实时优先级的时候永远默认搭配绑核。切换开销确实是真实存在的系统成本，多线程不是开得越多越好，很多性能问题在把锁拆掉、把线程数降下来之后，奇迹般地消失了。你先从这些基础动作开始，遇到问题再往深处挖，思路就不会乱。
