深入理解PX4飞控系统：多线程并发、原子操作与单例模式完全指南

深入理解PX4飞控系统：多线程并发、原子操作与单例模式完全指南

前言

在学习PX4飞控源码时，你是否遇到过这样的困惑：

1std::atomic<MulticopterRateControl*> MulticopterRateControl::_object{nullptr};
2
3MulticopterRateControl *instance = new MulticopterRateControl(vtol);
4if (instance) {
5    _object.store(instance);
6    _task_id = task_id_is_work_queue;
7    if (instance->init()) {
8        return PX4_OK;
9    }
10}
11

• 为什么要用std::atomic？
• 为什么要在堆上创建实例？
• 什么是单例模式？为什么需要它？
• PX4的多线程是如何工作的？
• 什么时候需要原子操作？

本文将系统性地解答这些问题，带你深入理解PX4的并发控制架构。适合有C++基础、正在学习PX4源码或从事飞控开发的工程师阅读。

关键词：PX4、多线程、原子操作、单例模式、线程安全、飞控系统、并发控制

目录

1. 线程的本质：破除常见误区
2. 多线程并发问题详解
3. 原子操作：硬件级的并发保护
4. 原子操作的硬件实现原理
5. 单例模式深度剖析
6. PX4的线程安全策略
7. 完整的启动流程分析
8. 什么时候需要原子操作
9. 常见误区与最佳实践
10. 总结与核心要点

1. 线程的本质：破除常见误区

1.1 常见误区澄清

很多初学者有这样的误解：

❌ 错误理解：

• 一个.cpp文件 = 一个线程
• 一个类 = 一个线程
• 一个函数 = 一个线程

✅ 正确理解：

• 线程是执行者（就像厨师）
• 代码是指令（就像菜谱）
• 多个线程可以执行同一份代码（多个厨师用同一本菜谱）

1.2 生活类比

想象一个厨房做饭的场景：

1┌─────────────────────────────────────┐
2│ 厨房 = 程序                          │
3│ 菜谱(cpp文件) = 代码文件             │
4│ 菜谱中的步骤(函数) = 具体操作        │
5│ 厨师 = 线程(执行者)                  │
6└─────────────────────────────────────┘
7
8一个厨师(线程)可以：
9✓ 读多本菜谱(多个cpp文件)
10✓ 执行多个步骤(多个函数)
11✓ 炒菜、切菜、煮汤(调用不同函数)
12
13多个厨师(多线程)可能：
14⚠ 同时操作同一个锅(共享变量) → 竞态条件!
15⚠ 一个在加盐，另一个在加糖 → 数据竞争!
16

1.3 PX4中的实际例子

1// mc_rate_control.cpp 文件
2
3class MulticopterRateControl : public ModuleBase<MulticopterRateControl> {
4private:
5    // 静态成员变量(所有线程共享!)
6    static std::atomic<MulticopterRateControl*> _object;
7    
8public:
9    void Run();              // 工作队列线程定期调用
10    int custom_command();    // 命令行线程调用
11    static int task_spawn(); // 主线程调用
12};
13

关键认识：

• 一个cpp文件中的代码被多个不同线程执行
• 同一个函数可能被多个线程调用
• 所有线程访问同一个共享变量(_object)

2. 多线程并发问题详解

2.1 什么是并发问题？

当多个线程同时访问共享资源时，如果没有适当的同步机制，就会出现数据竞争（Data Race）。

2.2 真实场景：同时启动冲突

1// 场景：两个终端同时输入 "mc_rate_control start"
2
3// 时刻T0：两个线程同时执行 task_spawn()
4
5// 线程A(主线程)执行：
6int task_spawn() {
7    if (_object.load() == nullptr) {  // ✓ 检查通过(nullptr)
8        auto instance = new MC_RateControl();  // 创建实例A
9        _object.store(instance);  // 存储实例A
10    }
11}
12
13// 线程B(初始化线程)同时执行：
14int task_spawn() {
15    if (_object.load() == nullptr) {  // ✓ 检查通过(nullptr) 
16        auto instance = new MC_RateControl();  // 创建实例B
17        _object.store(instance);  // 存储实例B (覆盖实例A!)
18    }
19}
20
21// 灾难性结果：
22// ❌ 实例A内存泄漏(没人持有指针了)
23// ❌ 创建了两个控制器实例(违反单例模式)
24// ❌ 两个控制器同时争夺飞机控制权 → 飞机崩溃!
25

2.3 场景可视化

1时间轴 →
2
3线程A(主线程):     [启动]                    [检查状态]
4                      ↓                          ↓
5                  task_spawn()              custom_command()
6                      ↓                          ↓
7                  创建实例A                  读取_object
8                      ↓                          
9                  _object.store()            
10
11线程B(工作队列):        [空闲]  [执行]  [执行]  [执行] ...
12                                   ↓       ↓       ↓
13                               Run()   Run()   Run()
14                                   ↓       ↓       ↓
15                            读取_object 读取_object
16
17线程C(命令行):                        [用户输入]
18                                          ↓
19                                    custom_command()
20                                          ↓
21                                     读取_object
22
23共享变量_object:   [null]  [ptr]  [ptr]  [ptr]  [ptr]
24                          ↑
25                      ⚠ 所有线程竞争访问这里!
26

3. 原子操作：硬件级的并发保护

3.1 原子操作的定义

原子操作(Atomic Operation)：一个不可分割、不可中断的操作，要么完全执行，要么完全不执行，不存在"执行到一半"的中间状态。

3.2 生活类比：ATM取钱

1非原子操作(危险)：
21. 检查余额: 1000元
32. 扣除金额: 1000 - 100 = 900元  ← ⚡这时断电!
43. 吐出钞票: (未执行)
5结果: 钱被扣了，但没拿到现金!
6
7原子操作(安全)：
8整个取钱过程是一个不可分割的整体
9要么: 扣钱+吐钱都完成
10要么: 完全不执行
11

3.3 CPU指令级的问题

1// 看似简单的一行代码
2counter = counter + 1;
3
4// 实际编译成3条CPU指令：
5LOAD  temp, counter    // 1. 从内存读取到寄存器
6ADD   temp, temp, 1    // 2. 寄存器中加1
7STORE counter, temp    // 3. 写回内存
8
9// 多线程交错执行：
10线程A: LOAD  (读到0)
11线程B: LOAD  (也读到0)
12线程A: ADD   (计算得1)
13线程B: ADD   (计算得1)
14线程A: STORE (写入1)
15线程B: STORE (写入1)  ← 覆盖了A的结果!
16
17// 期望: counter = 2
18// 实际: counter = 1 ❌
19

3.4 原子操作的使用

1#include <atomic>
2
3// 普通变量(非原子)
4int normal_counter = 0;
5
6// 原子变量
7std::atomic<int> atomic_counter{0};
8
9// 普通指针(非原子)
10MulticopterRateControl *normal_ptr = nullptr;
11
12// 原子指针(PX4中使用)
13std::atomic<MulticopterRateControl*> _object{nullptr};
14
15// 原子操作示例
16_object.store(instance);     // 原子存储
17auto ptr = _object.load();   // 原子加载
18atomic_counter.fetch_add(1); // 原子递增
19

4. 原子操作的硬件实现原理

4.1 三大核心技术

技术1：总线锁定（Bus Lock）

1CPU多核架构：
2
3        CPU核心0              CPU核心1
4           |                     |
5        L1缓存                L1缓存
6           |                     |
7        L2缓存                L2缓存
8           |_____________________|
9                    |
10              内存总线 ← 🔒 这里加锁!
11                    |
12                主内存
13                
14原子操作时：
151. CPU核心0执行 _object.store()
162. 🔒 锁定内存总线 (LOCK信号)
173. 其他核心被阻塞，无法访问该地址
184. 写入完成后释放总线
195. 其他核心才能继续访问
20

实际效果：

1// 线程A (CPU核心0)执行：
2_object.store(instance);
3// 硬件锁定总线 → 独占访问内存
4
5// 线程B (CPU核心1)同时尝试：
6auto ptr = _object.load();
7// 被硬件阻塞，必须等待线程A完成
8// 不可能读到"一半被写入"的数据
9

技术2：内存屏障（Memory Barrier）

问题：CPU指令重排序

1// 代码顺序
2instance = new MulticopterRateControl();  // 步骤1
3instance->init();                         // 步骤2
4_object = instance;                       // 步骤3
5
6// CPU可能优化成：
7_object = instance;                       // 步骤3提前!
8instance = new MulticopterRateControl();  // 步骤1
9instance->init();                         // 步骤2
10
11// 其他线程可能看到：
12auto ptr = _object;  // 读到了指针
13ptr->Run();          // 但对象还没创建完! 💥崩溃!
14

原子操作的解决方案：

1// 原子操作自带内存屏障
2instance = new MulticopterRateControl();
3instance->init();
4_object.store(instance);  // ← 这里插入内存屏障
5
6// 编译成汇编：
7// ... 创建对象的指令 ...
8// ... init()的指令 ...
9DMB ISH           // 🛡️ Data Memory Barrier: 内存屏障指令
10STLR x0, [x1]     // 原子存储
11
12// 保证：
13// ✓ store之前的所有指令都已完成
14// ✓ 不会重排序到store之后
15// ✓ 其他核心看到的顺序是正确的
16

技术3：缓存一致性（Cache Coherence）

问题：多核缓存不一致

1初始状态: _object = nullptr
2
3CPU核心0:                    CPU核心1:
4L1缓存: _object = nullptr    L1缓存: _object = nullptr
5   ↓                            ↓
6执行: _object = 0x1234        执行: auto p = _object
7L1缓存: _object = 0x1234      L1缓存: _object = nullptr  ← 读到旧值!
8主内存: _object = 0x1234      (还没刷新缓存)
9

原子操作触发缓存同步：

1// CPU核心0执行：
2_object.store(instance);  // 地址0x1234
3
4// 硬件自动执行：
5// 1. 写入核心0的L1缓存
6// 2. 标记该缓存行为"已修改"(Modified)
7// 3. 通过缓存一致性协议(MESI)发送消息
8// 4. 使其他所有核心的该缓存行失效
9// 5. 写入主内存
10
11// CPU核心1执行：
12auto ptr = _object.load();
13
14// 硬件自动执行：
15// 1. 检查L1缓存 → 发现"已失效"
16// 2. 从主内存重新加载 → 读到0x1234
17// 3. 更新L1缓存
18

4.2 ARM汇编实现对比

1// C++代码
2_object.store(instance);
3
4// 编译后的ARM汇编(原子指令)
5STLR  x0, [x1]    // STore-reLease: 原子存储指令
6                  // 硬件保证: 整个操作不可被中断
7                  // 自带内存屏障和缓存同步
8
9// 对比普通指令(非原子)
10STR   x0, [x1]    // 普通存储: 可能被中断、重排序、缓存不一致
11

5. 单例模式深度剖析

5.1 什么是单例模式？

单例(Singleton) = 全局只有一个实例的类

1// 飞机上的飞控系统：
2✓ 只能有一个姿态控制器 (不能同时有两个争夺控制权)
3✓ 只能有一个位置控制器
4✓ 只能有一个电机混控器
5
6如果有两个姿态控制器：
7控制器A: "向左倾斜10度!"
8控制器B: "向右倾斜15度!"
9飞机: "我该听谁的?" → 💥崩溃!
10

5.2 静态实例指针的作用

1class MulticopterRateControl {
2private:
3    // 【静态】= 属于类，不属于某个对象
4    // 【实例指针】= 指向这个类的唯一实例
5    static std::atomic<MulticopterRateControl*> _object;
6    //     ↑                ↑                      ↑
7    //   静态成员        类型(指针)            变量名
8};
9

为什么需要"静态"？

1// ❌ 非静态成员变量(错误)
2class RateController {
3    MulticopterRateControl *_instance;  // 非静态成员
4    
5    // 问题: 这个变量属于"某个RateController对象"
6    // 每创建一个对象，就有一个独立的_instance
7};
8
9RateController ctrl1;  // ctrl1有自己的_instance
10RateController ctrl2;  // ctrl2有自己的_instance
11// 无法实现"全局唯一"!
12
13
14// ✅ 静态成员变量(正确)
15class MulticopterRateControl {
16    static MulticopterRateControl *_object;  // 静态成员
17    
18    // 这个变量属于"整个类"，不属于任何对象
19    // 无论创建多少个对象，_object只有一份
20};
21
22// 即使不创建任何对象，也可以访问
23MulticopterRateControl::_object;  // 通过类名直接访问
24

为什么需要"指针"？

1// ❌ 静态对象(不灵活)
2class RateController {
3    static MulticopterRateControl _object;  // 静态对象
4};
5// 问题：
6// 1. 对象在程序启动时就创建(可能还不需要)
7// 2. 无法控制创建时机
8// 3. 占用内存即使不使用
9
10
11// ✅ 静态指针(灵活)
12class MulticopterRateControl {
13    static MulticopterRateControl *_object;  // 静态指针
14};
15// 优势：
16// 1. 初始状态: _object = nullptr (不占用内存)
17// 2. 需要时才创建: _object = new MC()
18// 3. 不需要时可以销毁: delete _object; _object = nullptr;
19// 4. 可以检查是否存在: if (_object != nullptr)
20

5.3 完整的单例实现

1// src/modules/mc_rate_control/MulticopterRateControl.hpp
2class MulticopterRateControl : public ModuleBase<MulticopterRateControl> {
3private:
4    // 1️⃣ 静态实例指针(唯一的实例)
5    static std::atomic<MulticopterRateControl*> _object;
6    
7    // 2️⃣ 私有构造函数(防止外部创建实例)
8    MulticopterRateControl(bool vtol = false);
9    
10    // 3️⃣ 禁止拷贝(防止复制出多个实例)
11    MulticopterRateControl(const MulticopterRateControl&) = delete;
12    MulticopterRateControl& operator=(const MulticopterRateControl&) = delete;
13    
14public:
15    // 4️⃣ 静态创建方法(控制实例创建)
16    static int task_spawn(int argc, char *argv[]);
17    
18    // 5️⃣ 静态访问方法(获取实例)
19    static MulticopterRateControl* instantiate(int argc, char *argv[]) {
20        return _object.load();
21    }
22    
23    // 6️⃣ 静态销毁方法(控制实例销毁)
24    static int task_stop();
25};
26
27// 定义静态成员
28std::atomic<MulticopterRateControl*> 
29    MulticopterRateControl::_object{nullptr};
30

5.4 何时需要单例模式？

✅ 需要单例的场景

1// 场景A: 硬件资源的唯一性
2class GPSDriver {
3    int _serial_fd;  // 串口文件描述符
4    
5    // 如果两个驱动同时读同一个串口：
6    // 驱动A读到: $GPGGA,12345...
7    // 驱动B读到: 6.78,N,123.45...
8    // 数据被两个驱动分割，都无法解析! ❌
9};
10
11// 场景B: 全局状态管理
12class ParameterManager {
13    std::map<std::string, float> _params;
14    
15    // 如果有多个ParameterManager：
16    // 实例A: MC_ROLL_P = 6.5
17    // 实例B: MC_ROLL_P = 5.0
18    // 控制器读取哪个? 配置不一致! ❌
19};
20
21// 场景C: 资源协调
22class ActuatorMixer {
23    void mix_and_output() {
24        // 协调所有电机输出
25        // 如果有两个混控器同时输出：
26        // 电机接收到冲突指令! 危险! ❌
27    }
28};
29

6. PX4的线程安全策略

6.1 工作队列架构（主要模式）

PX4大部分控制器使用工作队列(Work Queue)架构，这是一种天然避免并发问题的设计。

1// 工作队列特点：单线程执行，无并发冲突
2
3WorkQueue wq_rate_ctrl("wq:rate_ctrl");
4
5class MulticopterRateControl : public WorkItem {
6private:
7    // ❌ 这些变量都不需要原子保护
8    float _roll_rate_setpoint{0.0f};
9    float _pitch_rate_setpoint{0.0f};
10    matrix::Vector3f _rates_prev{};
11    
12public:
13    bool init() {
14        // 注册到工作队列(共享线程池)
15        ScheduleOnInterval(4_ms);  // 每4ms执行一次Run()
16        return true;
17    }
18    
19    void Run() override {
20        // ✅ 这个函数永远只被一个工作队列线程调用
21        // ✅ 不需要担心并发问题!
22        
23        _roll_rate_setpoint = get_setpoint();  // 普通访问
24        _rates_prev = current_rates;           // 普通赋值
25        
26        // 完全不需要原子操作或锁!
27    }
28};
29

6.2 不同场景的同步机制

6.3 性能对比

1// 方案1：互斥锁(慢)
2pthread_mutex_t mutex;
3
4void access_with_lock() {
5    pthread_mutex_lock(&mutex);      // ~100-1000 CPU周期
6                                      // 可能涉及系统调用
7                                      // 可能导致线程休眠/唤醒
8    auto ptr = _object;
9    pthread_mutex_unlock(&mutex);    // ~100-1000 CPU周期
10}
11
12// 方案2：原子操作(快)
13std::atomic<MulticopterRateControl*> _object;
14
15void access_with_atomic() {
16    auto ptr = _object.load();       // ~1-10 CPU周期
17                                      // 单条硬件指令
18                                      // 无系统调用
19                                      // 无阻塞
20}
21
22// 🚀 性能差异: 原子操作比互斥锁快 10-100倍!
23

7. 完整的启动流程分析

7.1 单例启动保护

1int MulticopterRateControl::task_spawn(int argc, char *argv[]) {
2    // 步骤1️⃣: 原子检查
3    if (_object.load() != nullptr) {
4        PX4_WARN("already running");
5        return -1;
6    }
7    
8    // 步骤2️⃣: 在堆上创建实例
9    MulticopterRateControl *instance = new MulticopterRateControl(vtol);
10    
11    if (instance) {
12        // 步骤3️⃣: 原子发布
13        _object.store(instance);
14        // release语义保证:
15        // ✓ new操作完全完成
16        // ✓ 对象构造完全完成
17        // ✓ 其他线程load时能看到完整的对象
18        
19        // 步骤4️⃣: 标记为工作队列模式
20        _task_id = task_id_is_work_queue;
21        
22        // 步骤5️⃣: 初始化
23        if (instance->init()) {
24            return PX4_OK;
25        }
26    }
27    
28    // 启动失败，清理资源
29    delete instance;
30    _object.store(nullptr);
31    _task_id = -1;
32    
33    return PX4_ERROR;
34}
35

7.2 为什么在堆上创建实例？

1// ❌ 栈上创建(错误)
2int task_spawn() {
3    MulticopterRateControl instance;  // 栈上对象
4    _object = &instance;
5    
6    return PX4_OK;
7}  // ← instance在这里被销毁! 指针变成野指针!
8
9
10// ✅ 堆上创建(正确)
11int task_spawn() {
12    MulticopterRateControl *instance = new MulticopterRateControl();
13    _object.store(instance);
14    
15    return PX4_OK;
16}  // ← instance继续存在于堆上
17

堆上创建的关键优势：

1. 生命周期可控：对象存活直到显式delete
2. 全局访问：指针可以被多个模块共享
3. 按需创建：只在需要时才分配内存
4. 可以销毁：不需要时可以释放资源

8. 什么时候需要原子操作

8.1 核心原因：控制器的两个层面

1// 【层面1】控制逻辑 - 不需要原子操作
2class MulticopterRateControl : public WorkItem {
3private:
4    // ❌ 这些成员变量都不是原子的
5    float _roll_rate_sp;
6    float _pitch_rate_sp;
7    
8public:
9    void Run() override {
10        // ✅ 工作队列保证单线程执行
11        _roll_rate_sp = calculate_rate();
12    }
13};
14
15
16// 【层面2】生命周期管理 - 需要原子操作
17class MulticopterRateControl {
18private:
19    // ✅ 这个指针是原子的
20    static std::atomic<MulticopterRateControl*> _object;
21    
22public:
23    static int task_spawn();   // 启动
24    static int task_stop();    // 停止
25};
26

8.2 PX4中所有需要原子操作的场景

场景1：模块生命周期管理（最重要）

1// 几乎所有PX4模块都需要
2template<class T>
3class ModuleBase {
4protected:
5    // ✅ 必须是原子的
6    static std::atomic<T*> _object;
7    
8public:
9    static int task_spawn();
10    static int task_stop();
11};
12

场景2：性能计数器

1class PerformanceCounter {
2private:
3    // ✅ 原子计数器
4    std::atomic<uint64_t> _count{0};
5    
6public:
7    void count() {
8        _count.fetch_add(1);
9    }
10};
11

场景3：线程退出标志

1class SensorDriver {
2private:
3    // ✅ 原子退出标志
4    std::atomic<bool> _should_exit{false};
5    
6    static void* thread_entry(void *arg) {
7        while (!driver->_should_exit.load()) {
8            driver->read_sensor();
9        }
10    }
11};
12

场景4：状态标志位

1class VehicleStatus {
2private:
3    // ✅ 原子状态标志
4    std::atomic<bool> _armed{false};
5    std::atomic<uint8_t> _nav_state{0};
6};
7

场景5：发布-订阅计数器

1class uORB::DeviceNode {
2private:
3    // ✅ 原子版本号
4    std::atomic<unsigned> _generation{0};
5};
6

8.3 决策流程图

1需要原子操作吗？
2    |
3    ├─ 变量是否被多个线程访问？
4    │   ├─ 否 → ❌ 不需要
5    │   └─ 是 → 继续
6    │
7    ├─ 访问模式？
8    │   ├─ 只在启动时设置，之后只读 → ❌ 不需要
9    │   ├─ 只被一个工作队列线程访问 → ❌ 不需要
10    │   └─ 多线程读写 → 继续
11    │
12    ├─ 操作类型？
13    │   ├─ 简单赋值/递增/标志位 → ✅ 使用原子操作
14    │   └─ 复杂多步骤操作 → ✅ 使用互斥锁
15

9. 常见误区与最佳实践

9.1 常见误区

误区1：原子变量的所有操作都是原子的

1std::atomic<int> counter{0};
2
3counter++;              // ✅ 原子操作
4counter = counter + 1;  // ❌ 非原子! (读和写分离了)
5
6// 正确写法:
7counter.fetch_add(1);   // ✅ 原子操作
8

误区2：过度使用原子操作

1// ❌ 过度使用
2class Controller {
3    std::atomic<float> _gain;      // 不必要
4    
5    void Run() {
6        // Run()只被一个线程调用，不需要原子
7    }
8};
9

9.2 最佳实践

1// ✅ 实践1：封装原子操作
2class ThreadSafeFlag {
3private:
4    std::atomic<bool> _flag{false};
5    
6public:
7    void set() { _flag.store(true); }
8    bool is_set() const { return _flag.load(); }
9};
10
11// ✅ 实践2：选择合适的内存序
12// 高频操作用relaxed
13_counter.fetch_add(1, std::memory_order_relaxed);
14
15// 同步点用acquire/release
16_ready.store(true, std::memory_order_release);
17
18// ✅ 实践3：最小化原子操作范围
19class Module {
20    static std::atomic<Module*> _instance;  // 需要原子
21    float _gain;     // 不需要（私有，单线程）
22};
23

10. 总结与核心要点

10.1 关键认识

1✅ PX4的核心理念:
2   "通过架构设计避免并发，而不是通过同步机制解决并发"
3
4核心策略:
51️⃣ 工作队列架构 → 消除大部分并发需求 (90%)
62️⃣ uORB消息传递 → 封装线程安全细节
73️⃣ 单例+原子操作 → 保护关键共享资源 (5%)
84️⃣ 最小化共享状态 → 减少同步开销
9
10结果:
11✓ 90%的代码不需要考虑线程安全
12✓ 原子操作只用于少数关键场景
13✓ 代码简洁，性能高效，易于维护
14

10.2 原子操作的三大硬件保证

11️⃣ 总线锁定 (Bus Lock)
2   → 独占内存访问，其他核心被阻塞
3
42️⃣ 内存屏障 (Memory Barrier)
5   → 禁止指令重排序，确保操作顺序
6
73️⃣ 缓存一致性 (Cache Coherence)
8   → 强制刷新所有核心缓存，保证一致性
9

10.3 单例模式的五大要素

1完整的单例模式 = 5个关键要素:
2
31️⃣ 静态实例指针
4   static std::atomic<MyClass*> _object;
5
62️⃣ 私有构造函数
7   private: MyClass() { }
8
93️⃣ 禁止拷贝
10   MyClass(const MyClass&) = delete;
11
124️⃣ 静态创建方法
13   static int task_spawn() { ... }
14
155️⃣ 原子操作保护
16   _object.compare_exchange_strong(...)
17

10.4 记忆口诀

1原子操作七大场景：
21. 模块指针要原子（生命周期管理）
32. 性能计数要原子（多线程递增）
43. 退出标志要原子（一写多读）
54. 状态标志要原子（多线程查询）
65. 版本序号要原子（发布订阅）
76. 引用计数要原子（资源管理）
87. 事件统计要原子（并发记录）
9
10工作队列无需愁（单线程执行）
11局部变量不用管（栈上独立）
12只读数据很安全（启动后不变）
13