我们可以把“多线程编程 (Multi-threaded Programming)”理解为“并发管理”。
1. 核心比喻：厨房与厨师
进程 (Process)=一家餐厅（厨房）。
它有独立的冰箱（内存）、独立的煤气管道（资源）。
餐厅倒闭了（进程崩溃），里面的东西都没了。
线程 (Thread)=厨房里的厨师。
单线程：厨房里只有一个厨师。他必须先切菜，切完再炒菜，炒完再装盘。客人等得花儿都谢了。
多线程：厨房里有三个厨师。
厨师 A 负责切菜。
厨师 B 负责炒菜。
厨师 C 负责装盘。
优势：大家同时干活，效率极高（利用多核 CPU）。
风险：他们共享同一个冰箱（内存/PlanContext）。如果厨师 A 正在拿肉，厨师 B 突然把冰箱门关了夹住 A 的手，或者两人同时抢一把刀，就会出事。
2. 为什么要搞多线程？（自动驾驶场景）
在你的PlanningNode里，如果只有单线程，代码是这样跑的：
等激光雷达数据进来（耗时 10ms）...
等定位数据进来（耗时 5ms）...
开始规划路径（耗时 50ms）...
发送控制指令。
后果：车子在等数据的时候是“发呆”的，规划频率极其低下，车子开起来一顿一顿的，甚至会因为反应慢撞墙。
引入多线程后：
线程 1（收发员）：专门负责收 ROS 消息（Callback）。有数据来就塞进
PlanContext，不用等规划算完。线程 2（计算员）：专门负责算 OSQP（Timer Loop）。不管有没有新数据，我每 100ms 必须算一次，保证车子一直有指令。
这就是“异步高效”的本质。
3. 多线程编程的三个核心要素
在 C++ 代码中，你主要会遇到这三个东西：
A. 创建线程 (Create)
#include <thread> void task() { // 具体的干活逻辑 } int main() { std::thread t1(task); // 创建并启动线程 t1 t1.detach(); // 让它自己去跑，不管它了 // 或者 t1.join(); // 主线程在这里等，直到 t1 干完活才继续 }B. 资源共享 (Sharing)
就像大家共用一个冰箱。
在你的项目中，PlanContext就是那个最大的共享资源。
ROS 回调线程往里面写。
规划主线程从里面读。
C. 同步与互斥 (Synchronization & Mutex)
这是最难的地方。因为大家共用资源，所以必须立规矩。
竞态条件 (Race Condition)：两个线程同时改一个变量，导致结果错误。（就是刚才说的“抢刀”）。
互斥锁 (Mutex)：解决竞态条件的工具。（刚才讲的“试衣间锁”）。
死锁 (Deadlock)：
厨师 A 拿着刀，等锅。
厨师 B 拿着锅，等刀。
两人僵持不下，厨房彻底停摆。
4. 你的代码架构中的体现
回头看你的架构图，多线程是这样运作的：
ROS 2 的底层：ROS 2 默认就是一个多线程的中间件。当你定义了多个
Subscription（订阅）时，ROS 内部会有线程池（Executor）帮你去“监听”数据。回调并发：当
LocalizationPose（定位）和ObstacleArray（感知）同时到达时，可能会有两个不同的线程同时试图调用PlanContext::updateData。保护机制：所以
PlanContext里必须有std::mutex。谁先抢到锁，谁先写，另一个排队。
5.提醒：
敬畏全局变量：只要你定义了一个全局变量或者静态变量（单例），就要立刻想到：“这会被多个线程同时访问吗？”
加锁要用 RAII：永远使用
std::lock_guard或std::unique_lock，不要手动lock()和unlock()，防止死锁。多看 Log：多线程的 Bug 很难复现（因为是概率性的）。如果程序偶尔崩溃，大概率是哪里没加锁。
