线程调试技巧：让多任务程序不再“抽风”

写过多线程程序的人都知道，有时候程序跑着跑着就卡住，或者数据突然不对，查来查去找不到原因。这多半是线程在“捣乱”。特别是在涉及硬件交互的场景，比如读取传感器数据、控制电机运转时，多个线程同时操作资源，问题更容易暴露。

别靠打印“猜”问题

很多人一出问题就在代码里狂加 print 或 log，指望通过输出顺序理清执行流程。可在线程环境下，打印本身也会干扰调度，看到的日志顺序未必真实反映执行逻辑。更糟的是，加了打印后问题可能“神奇消失”，这就是典型的“观察者效应”。

用调试器挂起所有线程

现代调试器比如 GDB 或 IDE 自带的调试工具，支持同时查看所有线程的状态。当程序卡住时，暂停运行，直接看每个线程当前停在哪一行。你会发现某个线程正卡在锁上，另一个在等待条件变量，问题一目了然。

gdb ./my_program
(gdb) thread apply all bt

这条命令能打印所有线程的调用栈，快速定位谁在等谁。

警惕共享资源的访问

两个线程同时改同一个变量，结果往往不可预测。比如一个线程在读取温度传感器的值，另一个正在重置校准参数，数据就可能错乱。解决办法是使用互斥锁（mutex），确保同一时间只有一个线程能访问关键资源。

pthread_mutex_t temp_mutex = PTHREAD_MUTEX_INITIALIZER;

void* read_sensor(void* arg) {
    pthread_mutex_lock(&temp_mutex);
    // 读取传感器数据
    double value = read_hardware_temp();
    pthread_mutex_unlock(&temp_mutex);
    return NULL;
}

避免死锁的小技巧

锁用多了容易死锁。比如线程 A 拿了锁1等锁2，线程 B 拿了锁2等锁1，互相僵持。一个实用做法是给所有锁定义固定的获取顺序，大家都按顺序来，就不会绕成死结。也可以用带超时的锁尝试，比如 pthread_mutex_trylock，失败就先退一步，过会儿再试。

利用日志记录线程行为

比起零散打印，集中化的结构化日志更有用。记录每个线程进入和离开关键区域的时间点，配合时间戳，能还原出执行时序。比如发现两个线程几乎同时进入临界区，那很可能是忘了加锁。

模拟高负载场景

有些问题平时不出现，一到设备长时间运行就冒出来。可以在测试时人为制造高并发，比如启动几十个线程反复读写硬件寄存器，逼出潜在竞争条件。这种压力测试就像给程序做“跑步机”，提前暴露耐力问题。

硬件断点也能帮上忙

某些开发板或调试器支持硬件断点，能在特定内存地址被访问时暂停程序。如果你怀疑某个全局变量被某个线程误改，设个数据断点，一触即停，直接抓现行。