鸿蒙任务调度源码解析：并发模型与上下文切换深度拆解

我先把话说在前面：源码分析这件事，最忌讳的就是对着目录猜内容，对着注释复述逻辑。系列写到第二十四篇，很多基础概念我已经默认读者有印象了，比如进程怎么创建、消息队列怎么通信、内核对象怎么管理。今天这篇，我打算挑一个贯穿始终、但往往被一笔带过的核心机制来拆：任务调度与并发模型。鸿蒙的调度器设计，决定了应用卡不卡、系统稳不稳、功耗高不高，它不像某个具体API那样直观，但你把这块啃下来，再看其他源码模块，会有一种"原来如此"的通透感。

这篇内容会涵盖任务从创建到消亡的完整生命周期、就绪队列与优先级机制、任务切换现场保护的底层实现，以及我在实际项目中踩过的和任务调度直接相关的坑。如果你是刚接触鸿蒙源码的开发者，或者正被应用的响应速度、稳定性问题困扰，这篇文章值得你花二十分钟静下心读一遍。我会尽量用大白话把内核里那些看似高深的设计讲明白，也会给出可以直接落地的调优思路。

1. 任务调度整体架构：先把并发模型的地基看清楚

1.1 三种"任务"形态，别傻傻分不清

在鸿蒙的源码里，凡是能跑起来的执行单元，最终都会抽象成任务。但不同层次的代码里，"任务"这个词指的东西不太一样。我刚开始看源码的时候就被绕晕过，这里先帮你理清概念。

第一层是进程。在标准系统里，进程是资源分配的单位，每个进程有独立的地址空间、文件描述符表、页表。进程与进程之间默认隔离，需要通过IPC机制通信。这一层的代码主要在进程管理模块里，负责 fork、exec、exit 这些操作。

第二层是线程。线程是进程内的执行流，同一个进程的线程共享地址空间和其他资源，但各自拥有独立的栈和寄存器上下文。鸿蒙的线程模型和 Linux 的 pthread 比较接近，但实现细节上有很多自研的成分。你在应用层创建的每一个线程，最终都会对应内核里的一个任务控制块。

第三层是协程。协程不是内核概念，是用户态的轻量级执行流。鸿蒙的JS环境、部分框架层代码会用协程做异步化改造。协程的切换不涉及内核态，完全在用户态完成，所以切换成本极低。我后面会专门讲协程的妙用。

在阅读源码的时候，你先分清当前代码处在哪一层，再去看它操作的是进程控制块、线程控制块还是协程上下文，思路会清晰很多。很多新手读源码读不下去，就是因为这三层概念混在一起，越看越乱。

1.2 调度器在整个内核里的位置

调度器是内核的"大脑中枢"。时钟中断把 CPU 的使用权交还给内核，调度器决定下一个获得 CPU 的执行单元是谁，然后触发上下文切换，把新任务的寄存器恢复进去，让它继续跑。这个过程说起来简单，但设计取舍非常多。

鸿蒙的内核调度器有几个鲜明的特点。第一，它支持优先级抢占，高优先级的任务就绪后，能立刻打断低优先级任务的执行。第二，它支持时间片轮转，相同优先级的任务轮流使用 CPU，避免某个任务饿死其他任务。第三，它针对低功耗场景做了特殊优化，在无任务可运行时能迅速进入空闲态，而不是空转。

这三个特点相互配合，构成了鸿蒙在 IoT 设备和移动设备上都能跑的基础。在小内存设备上，系统只有几十上百 KB 的可用内存，调度器必须足够精简；在标准系统上，调度器又要面对多核、复杂交互的场景，需要更精细的负载均衡逻辑。同一套内核代码要同时满足这两种极端需求，难度不低，你看源码的时候会看到很多条件编译的分支，就是为这个服务的。

1.3 为什么说读懂调度器就能读懂大半个内核

任务调度牵扯的面太广了：内存管理要为任务分配栈空间；文件系统要为任务的文件操作提供服务；中断管理要把中断事件转化为任务唤醒条件；同步互斥机制要防止多个任务同时访问临界资源；就连功耗管理和调度器都是深度耦合的。

我举个例子。你在应用层调用一个简单的delay函数，它最终会走到内核的睡眠接口，把当前任务从就绪队列摘除，挂到休眠队列里，然后触发一次调度，让出 CPU。等延时时间到了，定时器回调又把任务重新放回就绪队列。这一个简单操作，背后涉及定时器模块、队列模块、调度器模块、中断模块四个部分的协同。你只看一两个模块永远理解不了全貌，只有把它们串成一条线，才算真正读懂。

所以这篇虽然标题是"源码分析"，但我的分析方式不是逐行贴代码，而是把关键数据结构、核心流程和设计意图讲透，然后告诉你去源码的哪个位置验证。授人以鱼不如授人以渔，你掌握了读源码的方法，后续看任何模块都能事半功倍。

2. 核心数据结构与任务生命周期：任务到底是怎么"活"的

2.1 任务控制块里装了什么

在鸿蒙源码里，每个任务都有一个对应的任务控制块。这个结构体是整个调度系统的基石，里面保存了任务的完整状态信息。虽然不同版本的源码结构体字段略有不同，但核心信息是稳定的。

任务控制块里最重要的几类信息包括：任务标识符和优先级；任务状态，也就是当前任务处于就绪、运行、阻塞、挂起还是退出状态；栈信息，包括栈底指针、栈顶指针和栈大小；上下文保存区，用于保存任务被切换出去时的寄存器现场；内核态和用户态的栈指针；任务所属的进程或调度组；以及链表节点，用来把任务挂到不同的队列中。

内存里把任务控制块数组称为任务池，任务池的大小决定了系统最多能同时创建多少个任务。这个值在编译时通过配置项确定，我见过不少开发者为了省内存把它调得很小，结果应用运行一段时间就报"创建任务失败"。这里提醒一下，调小任务池确实能省内存，但一定要评估好业务场景的并发峰值，否则得不偿失。

2.2 从创建到消亡：任务的一生

创建阶段

任务创建的入口在任务模块的创建接口里。应用层调用pthread_create或者框架层的任务创建API，最终都会收敛到内核的创建函数。这个过程的大致步骤是：从任务池中分配一个空闲的任务控制块；校验优先级、栈大小等参数的合法性；分配栈空间，并把栈底地址等关键信息填入任务控制块；初始化任务的上下文，让任务看起来就像"刚被切换出去过一样"；把任务挂到就绪队列，触发一次调度。

这里有个细节很多人没注意：创建任务时置的初始上下文，其实是在模拟一次任务切换完成后的现场。新任务第一次被调度器选中时，调度器会从它的上下文保存区恢复寄存器，然后跳到任务入口函数开始执行。栈指针被设置到栈顶位置，返回地址被设置成任务退出清理函数的地址。这么设计的好处是，任务的启动和退出路径非常统一，调度器不用区分"这是新任务"还是"老任务被切回"。

我在项目中遇到过一个和任务创建相关的诡异问题：某功能模块每次启动后，运行一段时间必定崩溃，且崩溃位置飘忽不定。排查了很久才发现，是创建任务时传入的栈大小参数被某个配置宏错误地覆盖了，实际分配的栈空间只有预期的一半。高并发场景下栈溢出，把相邻内存写坏了，才导致崩溃位置随机。所以创建任务时，栈大小的参数校验绝对不能省。

就绪与调度

任务一旦就绪，就会被挂到就绪队列。鸿蒙的就绪队列是按优先级组织的，相同优先级的任务放在同一个队列里。调度器查找最高优先级的非空队列，从队头取出一个任务执行。这就是前面提到的优先级抢占和时间片轮转的物理基础。

任务获得 CPU 后，可以一直运行到发生以下情况之一：任务主动让出 CPU，比如调用睡眠接口；任务被更高优先级的任务抢占；时间片用完，被调度器强制换出。每一次换出，都要把当前任务的寄存器值保存到它的上下文保存区，再把下一个任务的上下文恢复出来。这个过程就是上下文切换，是调度系统性能的关键点。

阻塞与唤醒

任务运行中如果申请不到资源，比如要获取一个被其他任务持有的互斥锁，它不会干等，而是把自己从就绪队列摘除，挂到资源对应的等待队列上，标记为阻塞状态。这样 CPU 不会被浪费，可以去做其他事情。当资源被释放时，内核会唤醒等待队列上的任务，重新把它加入就绪队列。

等待队列的实现也很有意思。每个等待队列维护一个链表，链表节点内嵌在任务控制块里。从资源角度看，它只需要知道有哪些任务在等自己；从任务角度看，它需要知道自己正在等什么资源。这种交叉引用的设计，让唤醒操作非常高效。你不需要遍历所有任务去找谁在等这个资源，直接从资源对象的等待链表头部开始唤醒就行。

休眠和阻塞的区别也值得注意。任务休眠是主动行为，和具体资源无关，单纯就是"我要等一段时间"。而阻塞通常是被动的，是任务拿不到资源时的无奈之举。内核为这两类情况设计了不同的队列，但唤醒机制底层是共通的。

销毁阶段

任务执行完主函数后，会进入退出清理流程。这个流程要释放栈空间、回收任务控制块、唤醒等待该任务结束的其他任务。任务退出时的清理工作做得干不干净，直接影响系统长稳运行的能力。我见过因为任务退出路径上某个资源没释放导致的严重内存泄漏，系统运行几天后可用内存越来越少，最终触发内存耗尽。

所以我的习惯是：给每个任务都设置清晰的退出条件，确保退出时持有的锁、申请的内存、打开的文件句柄都能被正确回收。靠系统兜底？那是最后的保险，不该成为设计的依赖。

2.3 优先级与抢占：为什么高优先级任务不会被饿死

鸿蒙的优先级数值越小，优先级越高。调度器每次调度都会找数值最小的优先级队列。如果就绪队列里有比当前任务优先级更高的任务，当前任务会被立刻抢占，CPU 切换到高优先级任务执行。

但这里有个经典的隐患叫优先级反转。假设有三个任务 A、B、C，优先级从高到低。C 先运行，持有一把锁。A 来了，需要同一把锁，于是阻塞等待。B 此时就绪了，B 的优先级比 C 高，于是 B 抢占了 C。C 被挂起，锁一直得不到释放，A 就算优先级再高也只能等。最终造成高优先级任务被低优先级任务间接阻塞的局面。

内核解决优先级反转的经典手段是优先级继承：当高优先级任务被低优先级任务持有的锁阻塞时，把低优先级任务的优先级临时提升到高优先级任务的级别，让它尽快运行完并释放锁。鸿蒙源码里，你可以在互斥锁的实现中找到这个逻辑。这块我后面讲排查技巧时会再说，现在先记得这个概念，它是面试高频考点，也是实战中容易出问题的点。

3. 调度核心流程拆解：一次任务切换到底发生了什么

3.1 调度入口的触发时机

调度器不会自己主动跑，它需要一个"推力"。推动调度的时机主要有三种：任务主动让出 CPU；定时器中断或者外部中断返回路径上发现需要调度；任务从阻塞态被唤醒后重新就绪。理解了触发时机，你就知道为什么中断处理程序里不能随便调用阻塞接口了，因为中断上下文和任务上下文是完全不同的运行环境。

以时钟中断为例。每次时钟中断到来，内核都会更新系统 tick 计数，检查有没有任务的延时到期，如果到期就唤醒它。中断退出前，内核会检查是否有更高优先级的任务已经就绪，如果有，就执行上下文切换，中断返回到高优先级任务继续运行。这就是抢占式调度的实现路径。

你如果看调度相关的汇编代码，会看到中断返回路径上有一个关键判断分支，专业术语叫"调度是否需要生效"。这个标志位是通过中断嵌套深度和锁状态综合算出来的。新手看到这段汇编容易晕，我的建议是先跳过汇编细节，把整体流程用图在脑子里画出来，先建立模型，再抠细节。

3.2 上下文切换时到底保存了什么

上下文切换的核心动作是保存旧任务的寄存器现场，恢复新任务的寄存器现场。具体要保存的内容包括：通用寄存器；程序计数器，也就是当前执行到的指令地址；栈指针；处理器的状态寄存器；以及浮点寄存器和向量寄存器，如果 CPU 支持且任务使用过浮点单元的话。

这个保存动作把 "CPU 正在执行什么" 完完整整地冻结下来，等任务重新获得 CPU 时，从保存的现场继续往下走，完全感知不到自己被切出去过。这正是操作系统能实现多任务并发最根本的机制。

这里有一个很多人忽略的性能点：任务切换时，旧任务的缓存状态其实是"凉"的，新任务的指令和数据需要重新加载到高速缓存里。如果系统频繁切换任务，缓存命中率会下降，整体性能不升反降。这就是"线程太多不一定是好事"的根本原因。你在做性能优化时，减少不必要的线程切换，可能比优化某一段代码逻辑的收益更大。

3.3 就绪队列与红黑树的双向奔赴

低内存设备上，任务数量不会太多，就绪队列直接用双向链表就能解决。但标准系统上，任务数量可能成百上千，调度器需要从大量就绪任务中快速找到最高优先级的那个。如果还按优先级遍历链表，最坏情况要遍历整个队列，性能不可接受。

我看过相关源码的演进，最近的标准系统调度模块已经引入了红黑树来组织任务。红黑树的查找、插入、删除操作都能在对数时间内完成，大大提升了高负载场景下的调度效率。这个设计让我想起之前看其他系统内核时的感受：调度器的数据组织结构，往往比调度算法本身更能决定系统在天量任务下的表现。

所以你在源码里看到类似树结构的代码，不要慌，它的核心作用就是把"从 N 个任务里快速找到下一个该运行谁"这个问题的时间复杂度降下来。调度算法最终选谁，还是根据优先级和时间片逻辑来决定，树结构只是加速检索的手段。

3.4 时间片轮转：让每个任务都有机会跑

同优先级的多个任务都就绪时，调度器不能只让第一个任务一直跑，否则其他任务会被饿死。鸿蒙的做法是给每个任务分配固定长度的时间片，时间片用完后，任务被重新放回队尾，调度器从队头取出下一个任务运行。

时间片的长度是调度系统的重要参数。太短，上下文切换开销占比过高，CPU 大量时间花在切换上；太长，交互式任务的响应速度变慢，用户明显感到卡顿。这个值通常要调多次才能找到适合业务场景的点。我在项目里会把频繁交互的任务适当调高优先级，同时保持默认时间片，效果比单纯加长时间片好得多。

4. 任务调度的调试与优化：从坑里爬出来的实用心得

4.1 优先级反转的典型案例与解决思路

我在项目里遇到过一次典型的优先级反转问题。现象是系统运行一段时间后，某个对实时性要求很高的任务开始出现偶发超时，但又不是每次必现，排查起来非常费劲。

最终看调度日志发现，低优先级任务在持有锁的情况下被中等优先级任务抢占了 CPU，而高优先级任务又在等那把锁。这一层套一层的阻塞，让系统看起来像是"僵住了"。定位到是优先级反转后，我们从两个方向解决：业务上，把共享资源的持有时间压到最短，尽量做到"拿锁即改，改完即放"；机制上，确认内核的互斥锁支持优先级继承，并且正确启用了相关配置。

另外，代码里如果存在长时间持锁的操作，就算有优先级继承，也只是缓解，不能根治。系统设计层面应该尽量避免，而不是把宝全押在内核机制上。我见过项目里把锁粒度做得很粗，一段耗时操作全程持锁，结果无论怎么调优先级，系统响应就是上不去。换了细粒度锁之后，问题立刻消失。

4.2 调用阻塞接口导致系统卡死

还有一次印象很深的问题，现象是系统整个界面像冻住了一样，任何操作都没反应。通过串口打印调度器的就绪队列信息，发现问题出在一个事件的回调函数里。

这个回调在任务上下文运行，但代码里直接调用了一个阻塞的等待接口。回调阻塞住之后，依赖该回调的任务无法继续，而唤醒它的条件又必须由这个任务来完成，形成了死等。系统里其他任务看似还能就绪，但整体逻辑已经卡住了。

这个问题本质上是：在应该使用异步通知的场景里用了同步等待，并且没有定义好回调的执行上下文。"回调函数里严禁做阻塞操作"这条铁律，我是用惨痛教训记住的。你现在看到这条，希望你不用再踩一遍。

4.3 动态优先级调整的正确姿势

有些业务场景需要任务在不同阶段拥有不同优先级。比如某个下载任务，启动时优先级低，不影响用户操作；但用户点击了"立即下载"，希望它能尽快跑完，这个时候就需要动态提升优先级。

鸿蒙的任务接口支持动态调整优先级。但在实际操作中，我总结出几个注意点：优先级变化要收敛，不能频繁抖动，否则调度器忙着换人，系统有效吞吐量下降；提升优先级的同时，要考虑它持有的锁的情况，避免引发新的优先级反转；创建任务时设置的初始优先级要结合业务峰值来定，而不是随便拍一个数。

4.4 任务栈大小的估算方法

任务栈大小怎么定，是新手最迷茫的问题。给大了浪费内存，给了小了溢出崩溃。我的做法是先按业务调用深度最深的路径估算，主函数调用子函数，子函数又调用子函数，每一层都可能有局部变量，链路上所有栈帧大小累加，再上浮百分之三十到百分之五十的安全余量。

如果项目已经跑起来了，更实际的方法是通过内核提供的栈水印机制，查看任务实际用到的最大栈深度，再把配置调到接近峰值的合理位置。调试版本打开栈溢出检测，填特定图案，任务切换时检查栈边界是否被改写。这个方法比拍脑袋可靠得多。

我一开始就吃过栈不足的亏，后来每建一个任务都会问自己一句：这个任务最深会调到哪里？栈给够了没有？全局搜索一下调用链，不要嫌麻烦。

4.5 任务数量的设计哲学

任务控制块资源、每个任务的栈空间、内核调度开销，都随任务数量线性增长。任务太多，调度器和内存都会成为瓶颈。我接手过一个极其卡顿的项目，排查发现系统里挂了近百个常驻任务，很多任务的职责高度重叠，甚至有的只是为了一段几乎永远不执行的逻辑而存在。

优化方式不是逐个精调，而是从业务架构层面把并发模型重新设计：同类职责的任务合并成一个，任务内部用状态机区分不同场景。任务数量砍掉一大半之后，调度开销降下来了，内存占用也降下来了，系统响应速度明显提升。

所以我的建议是：任务数量不是越多越好，能用状态机解决的问题就不要开新任务，能合并的职责就不要拆分。并发模型的优雅程度，往往比单个任务的执行效率更能决定系统质量。

5. 协程机制探秘：用户态调度带来的另一个世界

5.1 协程和线程的本质区别

协程和线程共享"并发执行"的概念，但实现完全不同。线程的调度由内核决定，切换要经过内核态，开销几千甚至上万条指令。协程的调度由用户程序自己控制，切换只涉及保存和恢复少量寄存器，开销小一个数量级以上。

但协程也不是没有代价。协程自己管理栈，通常栈空间远小于线程栈，如果协程里递归层数太深或者栈上分配的局部变量太大，很容易溢出。另外，协程是协作式调度，如果一个协程里发生了长时间阻塞，比如执行了一个真正的阻塞 IO，整个线程都被卡住，其他协程也没有机会运行。

鸿蒙的应用框架在 IO 密集场景大量使用协程做异步化，把阻塞 IO 操作放到独立线程池，IO 完成后回调唤醒对应的协程。这样既保留了顺序写代码的思维方式，又避免了大量的线程切换开销。

5.2 协程背后的实现要点

一个协程库的核心要素有三个：协程上下文，其实就是一套寄存器现场和私有栈；调度入口，对应协程例程中让出执行权的挂起点；全局调度表，记录哪些协程处于就绪状态。

协程切换的过程可以概括为：当前协程把寄存器现场保存到自己的上下文，然后从全局调度表中取出下一个就绪协程，恢复它的现场，跳到它上次让出的位置继续执行。这套机制和内核调度器异地同构，区别只是一个在用户态，一个在内核态。

我看过不少自研协程库，最初版本往往忽略了一个问题：协程里的局部变量在恢复现场后还能不能正确读取？答案是，只要协程切换时保存了完整的栈指针和寄存器，局部变量就还在原栈位置，恢复后自然可以访问。协程迁移线程时，原栈内容必须完整搬运到另一个线程的栈上，否则局部变量就全丢了。这个问题非常隐蔽，很多协程库的诡异 bug 都从这里来。

5.3 协程改造实践：一个 IO 密集场景的真实例子

我参与过某个网络代理类项目的重构，最初是每个连接创建一个线程，连接数上来之后，线程数量爆炸，上下文切换开销巨大，整体吞吐上不去。后来改成线程池加协程模型：少量常驻线程，每个连接对应一个协程，IO 等待时协程让出执行权，线程去服务其他连接。

改造之后，单机吞吐量提升了接近一个数量级，内存占用反而大幅下降。线程栈从每连接一栈变成了线程池数量的固定栈，连接状态压缩到协程上下文中。这里面的原理并不高级，核心就在于减少了调度开销和内存浪费，但带来的收益很可观。

如果你也在做类似的网络服务或者 IO 密集的框架层改造，建议先从热路径上的小模块试验，不要一上来就全量替换。协程的调试难度比线程高，刚上手时问题会很多，控制好改造范围，逐步建立信心。

6. 调度相关源码的阅读方法：给你一条直达核心的路线

6.1 我建议的源码阅读顺序

直接打开源码文件硬啃，很容易迷失在细节里。我推荐的顺序是先找调度器的主入口函数，搞清楚它从哪获得"下一个任务"，再顺着它的调用往回找，是谁在什么时机调用了它。

往前是触发源，包括各类中断返回前、任务主动让出 CPU 的路径、锁释放后的唤醒路径；往后是具体执行体，也就是上下文切换的核心实现。这两条线打通之后，再把任务控制块管理、就绪队列操作、时间片维护等相关模块填充进来。

这个顺序是有讲究的。先建立主干，再添加分支，遇到任何内容都能快速归类。很多人在源码里团团转，是因为他们从某个数据结构开始读，读完了还是不知道它被谁用到、在什么时机被操作。换一个"以流程为纲"的思路，效率会完全不同。

6.2 用好日志和调试工具

鸿蒙内核提供了丰富的调度相关日志能力，我建议你在研究阶段，把任务切换、优先级变更、锁获取释放这几类关键事件的日志开关打开，先跑一个简单示例，亲眼看看任务的创建、唤醒、切换、销毁长什么样。亲手看到日志里每一行对应代码的哪个位置，会比读十遍代码印象深刻得多。

串口日志、系统状态查询命令也是排查问题的利器。系统卡死时，通过命令导出当前所有任务的状态、栈使用率、锁持有关系，往往一眼就能定位问题。很多时候系统看似无规律崩溃，实际上是因为任务异常导致了连锁反应，从任务列表里能看出端倪。

6.3 官方文档和源码注释的价值

源码里的注释虽然不多，但每一句都值得抠。有些注释解释了设计者当时的取舍考量，比如"这里选择双向链表而不是数组，是因为任务频繁插入和删除"之类，读明白这些注释，你能理解很多代码形状背后的原因。

再加上官方文档里对任务管理模块的说明，两者互补使用，能达到最佳效果。我通常习惯按"官方文档先建立认知，源码里找实现细节，日志里验证理解"的顺序来学习一个新模块。这套方法在任务调度和其他内核模块上都适用。

7. 多核场景下的任务调度进阶：别只看单核的玩法

7.1 核间负载均衡是怎么运作的

单核系统的调度逻辑相对简单，多核系统的复杂度陡增。多核调度需要解决的核心问题是：每个 CPU 核上都应该有任务在跑，而不是一个核忙死，其他核闲死。理想状态是各核负载均衡。

鸿蒙在多核调度上采用 peer 模式，CPU 核之间通过核间中断互相唤醒。当一个核上的就绪任务太多，而其他核空闲时，负载均衡逻辑会参与调度决策，把任务迁移到空闲核上执行。但是任务迁移不是免费的，需要把任务的上下文从当前核切换到目标核，涉及缓存、内存屏障等多方面开销。

我在实际项目中观察到的现象是：负载均衡在峰值负载时非常关键，但在轻载场景反而不一定总带来收益。系统设计目标不同，迁移策略也不同。有些场景更看重低功耗，希望在轻载时把任务集中在少数核上，其他核进入休眠；有些场景更看重吞吐，希望所有核都尽可能跑满。

7.2 CPU 亲和性与缓存利用

多核系统里还有一个重要概念叫 CPU 亲和性，也就是任务倾向于在固定的核上运行。设置亲和性之后，任务大概率复用该核的高速缓存，减少缓存失效带来的额外开销。内核的调度器会尽量维持这种亲和性，但负载均衡时也可能改变任务的核归属，这是性能和均衡的权衡。

当任务在两个核之间频繁迁移时，值得注意。迁移会带来极高的缓存失效成本。我在性能分析时遇到过相互依赖的两个任务被调度到不同核上，产生大量核间通信，性能反而不如单核顺序执行。解决方式很简单：让相互依赖的任务尽量处于同一个核的调度组，或者干脆用亲和性锁死。程序性能优化的很多坑，最后都落在缓存和调度这类底层机制上。

7.3 多核并发的锁竞争优化实践

多核系统上的锁竞争比单核严重得多。单核上多任务是时间片交错，同一时刻只有一个是运行态，锁竞争很少发生。多核上两个任务真心实意同时争一把锁，内核的调度器和锁实现需要更多手段来减少争用。

实践中第一个办法是使用读写锁，读多写少的场景下，多个读者可以共享持有；第二个办法是使用无锁数据结构，利用原子操作避免加锁，适合简单场景；第三个办法是锁粒度细化，把一把大锁拆成多把小锁，减少竞争窗口；第四个办法是使用原子操作计数。这几种方式我都用过，效果排序取决于具体场景，没有银弹。但最基本的原则没有变：缩短临界区，减少持锁时间，锁永远不是你业务逻辑的救世主。

8. 常见问题速查表：调度这潭水，坑都替你踩过了

我把这几年遇到的任务调度问题整理成了一份速查表，内容全是实际经验，没有教科书式的空话。

排查问题的时候，我一般先看现象是偶发还是必现。偶发问题优先找并发相关的竞争条件，比如锁、队列操作；必现问题优先查逻辑漏洞，比如参数错误、越界访问。这个分类方法能帮我快速缩小范围，不至于像无头苍蝇一样乱翻日志。

9. 最后再聊聊我读源码的一些习惯

如果你能把任务调度这块源码啃下来，再看鸿蒙的其他模块，会觉得顺畅很多。因为任务调度是内核的中枢，每一个其他模块都或多或少要和它打交道：中断要唤醒任务，IPC 要阻塞和唤醒任务，定时器要触发任务就绪。理解了中枢，其他模块的很多设计就不再是孤立的知识点，而是围绕"怎么更好地服务任务执行"这个目标展开的。

读这类源码时，我强烈建议准备一个专门的笔记本，把每个核心数据结构的字段含义、每个关键流程的触发条件、每个函数的设计意图记录下来。这份笔记将成为你自己的源码地图。隔一段时间回看时，你会发现很多当初不理解的设计，现在都能和业务场景对上号了。

回到实践层面，看源码和做工程是相互成就的。架构设计时多想想任务怎么组织，出了问题调试时多想想调度器在做什么，性能优化时多想想切换成本。带着问题去读源码，效果远好于漫无目的地刷代码。希望这篇内容，能帮你少走一些我当年走过的弯路。