第二章 Zephyr内核基础：线程、调度、优先级、时间片与线程状态机

Zephyr RTOS 作为一个面向资源受限嵌入式系统的实时操作系统，其内核核心价值在于提供确定性的任务调度与资源管理能力。本章将深入剖析 Zephyr 内核的线程模型，从线程控制块（TCB）的底层结构出发，逐步讲解调度器的工作机制、优先级抢占规则、时间片轮转策略以及线程状态机的完整迁移路径。我们将通过实际代码示例与工程案例，帮助您建立对 Zephyr 线程生命周期的系统性认知，为后续驱动开发与蓝牙协议栈集成打下坚实基础。

2.1 线程核心原理：从TCB到执行实体

在 Zephyr 中，线程（Thread）是内核调度的最小执行单元，其本质是一个独立的执行上下文，包含 CPU 寄存器组、栈空间、调度元数据以及同步资源。每个线程在内核中由一个 struct k_thread 结构体（即线程控制块 TCB）唯一标识。TCB 不仅保存了线程的运行状态，还通过链表节点将线程挂接到不同的内核队列中（如就绪队列、等待队列）。理解 TCB 的布局是掌握 Zephyr 线程管理的第一步。

线程的创建过程实质上是初始化 TCB 并分配栈空间。Zephyr 提供静态与动态两种创建方式：静态创建使用 K_THREAD_DEFINE() 宏，在编译期分配 TCB 和栈；动态创建则使用 k_thread_create() 函数，从内核堆中分配内存。静态方式适合数量固定、生命周期明确的系统，而动态方式则更灵活，但需要关注内存碎片问题。

2.2 调度器工作机制与优先级抢占

Zephyr 默认使用基于优先级的抢占式调度算法。内核维护一个就绪队列，该队列按优先级从高到低排序，同优先级线程按时间片轮转。调度器在以下时机触发重新调度：当前线程主动让出 CPU（如调用 k_yield() 或阻塞）、中断处理完成后、或更高优先级线程变为就绪状态。

优先级数值在 Zephyr 中越小表示优先级越高。系统保留 0 作为最高优先级（通常用于中断处理线程），而用户线程优先级范围一般为 1 到 14（CONFIG_NUM_PREEMPT_PRIORITIES 可配置）。此外，Zephyr 还支持协作式优先级（Cooperative Priority），其数值为负数，协作式线程不会被抢占，只能主动让出 CPU。

调度器的核心数据结构是 _wait_q 和 _ready_q。就绪队列采用位图加速查找：内核维护一个 32 位位图，每一位对应一个优先级，当某优先级队列非空时，对应位置 1。调度器通过计算位图中最高置位位置，即可在 O(1) 时间内找到最高优先级的就绪线程，这保证了调度延迟的确定性。

2.3 时间片轮转与线程状态机

时间片（Time Slice）是防止同优先级线程饿死的重要机制。当多个线程具有相同优先级时，调度器为每个线程分配一个时间片（默认 2.5ms，可通过 CONFIG_TIMESLICE_SIZE 配置）。当线程的时间片耗尽时，即使没有更高优先级线程就绪，当前线程也会被强制切换，让同优先级的下一个线程运行。

// 时间片配置示例
#define TIMESLICE_SIZE_MS 10
#define TIMESLICE_PRIORITY 7

void timeslice_config(void) {
    k_sched_time_slice_set(TIMESLICE_SIZE_MS, TIMESLICE_PRIORITY);
    // 仅对优先级高于或等于 7 的线程启用时间片轮转
}

线程状态机是理解线程生命周期的核心。Zephyr 线程存在五种基本状态：就绪（Ready）、运行（Running）、阻塞（Blocked）、挂起（Suspended）和终止（Terminated）。状态迁移由内核 API 和调度事件驱动：

• 就绪 → 运行：调度器选中该线程，执行上下文切换。
• 运行 → 阻塞：线程调用 k_sem_take()、k_msgq_get() 等阻塞 API，或调用 k_sleep() 延时。
• 阻塞 → 就绪：等待的条件满足（如信号量被释放）或超时到期。
• 运行 → 挂起：线程调用 k_thread_suspend() 或系统调用挂起操作。
• 挂起 → 就绪：调用 k_thread_resume() 恢复线程。
• 任意状态 → 终止：线程函数返回或调用 k_thread_abort()。

2.4 线程创建与管理实战：多传感器采集系统

让我们通过一个实际案例来综合运用上述知识。假设我们需要设计一个环境监测节点，包含温度传感器（I2C 接口）和湿度传感器（SPI 接口），要求每 100ms 采集一次数据，并通过 UART 输出。系统约束：CPU 为 Cortex-M4 @ 64MHz，RAM 仅 64KB。

初始方案设计：

1. 创建两个线程：temp_thread（优先级 5）和 hum_thread（优先级 5），分别负责两种传感器采集。
2. 创建 uart_thread（优先级 3），负责数据打包与输出。
3. 使用信号量实现采集线程与 UART 线程的同步。

关键代码实现：

#define STACK_SIZE 1024
K_THREAD_STACK_DEFINE(temp_stack, STACK_SIZE);
K_THREAD_STACK_DEFINE(hum_stack, STACK_SIZE);
K_THREAD_STACK_DEFINE(uart_stack, STACK_SIZE);

struct k_thread temp_thread_data;
struct k_thread hum_thread_data;
struct k_thread uart_thread_data;

K_SEM_DEFINE(temp_sem, 0, 1);
K_SEM_DEFINE(hum_sem, 0, 1);
K_MSGQ_DEFINE(uart_msgq, sizeof(struct sensor_data), 10, 4);

void temp_thread_entry(void *a, void *b, void *c) {
    struct sensor_data data;
    while (1) {
        k_sem_take(&temp_sem, K_FOREVER);
        data.type = TEMP;
        data.value = read_temp_sensor();  // I2C 读取
        k_msgq_put(&uart_msgq, &data, K_NO_WAIT);
    }
}

void uart_thread_entry(void *a, void *b, void *c) {
    struct sensor_data data;
    while (1) {
        k_msgq_get(&uart_msgq, &data, K_FOREVER);
        uart_send_packet(&data);  // UART DMA 发送
    }
}

void main(void) {
    k_thread_create(&temp_thread_data, temp_stack, STACK_SIZE,
                    temp_thread_entry, NULL, NULL, NULL, 5, 0, K_NO_WAIT);
    k_thread_create(&hum_thread_data, hum_stack, STACK_SIZE,
                    hum_thread_entry, NULL, NULL, NULL, 5, 0, K_NO_WAIT);
    k_thread_create(&uart_thread_data, uart_stack, STACK_SIZE,
                    uart_thread_entry, NULL, NULL, NULL, 3, 0, K_NO_WAIT);
    
    // 启动定时器，每 100ms 释放信号量
    k_timer_start(&sample_timer, K_MSEC(100), K_MSEC(100));
}

问题分析与优化：初始方案中，两个采集线程优先级相同，依赖时间片轮转。但时间片切换可能发生在传感器读取过程中，导致读取时序不稳定。优化方案：将 temp_thread 优先级提升至 4，hum_thread 保持 5，确保温度采集优先完成。同时，UART 线程优先级设为 3，保证数据及时输出。

性能对比：

复盘经验：在实时系统中，优先级分配应遵循"速率单调"原则——执行频率越高的任务优先级越高。同时，要避免优先级反转问题，必要时可使用优先级继承互斥量（K_MUTEX）来缓解。

2.5 常见误区与调试技巧

在实际开发中，工程师常犯以下错误：

• 误区一：认为线程优先级越高越好。实际上，过高的优先级会饿死低优先级线程，导致系统功能缺失。
• 误区二：在循环中使用 k_busy_wait() 代替 k_sleep()。前者会阻塞调度器，浪费 CPU 周期。
• 误区三：忽略 CONFIG_PREEMPT_ENABLED 配置。若关闭抢占，所有线程变为协作式，调度行为完全不同。

调试线程问题时，推荐使用 Zephyr 内置的 k_thread_debug 功能（需开启 CONFIG_THREAD_DEBUG），可以实时查看线程状态、栈使用率和调度次数。此外，通过 CONFIG_THREAD_STACK_INFO 可以获取栈水位线，帮助定位栈溢出风险。