Linux多线程编程指南：从pthread创建到锁与线程管理

1. 先想清楚一个问题：进程和线程到底差在哪

1.1 线程和进程的边界：别只会背定义

每次面试 Linux 方向的技术岗，我几乎都会问一个问题：进程和线程到底差在哪？能立刻说出 pthread_create 的人不少，但真正能把创建、同步、回收、取消这条完整链路说清楚的人，其实没有想象中多。这个现象挺有意思，因为 pthread 库的 API 数量真不算大，难的是理解 API 背后的机制——Linux 线程到底是怎么被内核调度的？为什么线程崩溃会带崩整个进程？为什么加了锁程序反而更慢？这篇文章我想把这些问题串起来，帮大家从“会调接口”走到“理解线程控制”。

先说最基础的概念。进程是资源分配的单位，有自己独立的地址空间、文件描述符表、信号处理函数；线程是调度的单位，同一进程内的线程共享代码段、数据段、堆、打开的文件描述符，但每个线程有自己独立的栈、寄存器上下文和 TID。你可以把进程想象成一栋楼里各自独立的房间，任意一个房间里的东西坏了不会影响隔壁；而线程更像是一群人在同一套房子里合租，厨房厕所都是共用的，一个人乱动冰箱，另一个人可能会当场发现牛奶少了。

在 Linux 上，这个“共享”不是抽象概念，而是真实的系统调用行为。glibc 的 pthread_create 内部最终调用的是 clone，它会通过 CLONE_VM、CLONE_FS、CLONE_FILES 这些标志把地址空间和文件描述符表共享给新创建的线程。所以这里有个很容易被忽略的推论：线程之间天然没有内存隔离，一个线程里野指针越界写坏了堆，整个进程都可能直接崩掉。这一点，和 fork() 产生的子进程完全不同。

1.2 线程控制到底控制什么：一张全局地图

很多教程是按 API 逐条讲的，背了一堆 pthread_mutex_lock、pthread_cond_signal 的知识点，但一到项目里还是不知道自己该怎么搭框架。我习惯把线程控制拆成四个维度，这样心里始终有张地图：

• 创建：pthread_create 加线程属性 pthread_attr_t，解决“线程以什么配置跑起来”的问题。
• 退出与回收：return、pthread_exit、pthread_join、pthread_detach，解决“线程结束后的资源去哪儿了”的问题。
• 同步互斥：互斥锁、条件变量、读写锁、自旋锁、原子操作，解决“多个线程同时碰同一份数据怎么不打架”的问题。
• 取消与生命周期：pthread_cancel、cleanup 回调、线程局部存储，解决“不想让这个线程继续跑了怎么安全收场”的问题。

别小看这张地图。我见过不少线上事故，本质都是这四个维度没打通：有人只学了创建和加锁，不知道线程退出后要 join 或 detach，结果内存和栈一路涨；有人用 pthread_cancel 硬取消线程，却没有清理回调，锁没释放，直接造成死锁。后面几节我就按这个地图一层层展开。

1.3 这种场景下，我更倾向选线程而不是进程

什么时候该用多线程，什么时候该用多进程，其实比“怎么调 pthread”更重要。我从实际项目里的体会是：

第一，如果多个任务需要频繁共享大块内存数据，选线程。进程之间共享数据要么走管道、要么走共享内存，代码复杂度会明显上升；线程共享地址空间，一个全局结构体大家直接访问，模型最简单。

第二，如果对启动速度和调度开销敏感，选线程。线程创建比 fork 快不少，上下文切换的成本也更低。当然，线程的切换仍然不便宜，线程数也不是越多越好。我在服务端项目里见过有人一台 8 核机器开 200 个线程，每个线程都在抢锁，结果 CPU 全部耗在上下文切换和自旋上，吞吐反而比 32 线程还低。线程数量建议先围绕“可并行任务数 + IO 等待数”设计，而不是无脑开满。

第三，如果你需要很强的故障隔离，选进程。比如跑用户提交的不信任代码，或者核心业务不能因为一个子模块崩溃就全挂，进程隔离是更安全的选择。现实里也有很多混合架构，主进程用多线程处理高并发请求，关键重模块单独拉成子进程守护，各取所长。

2. pthread 库核心 API：从创建到回收的完整链路

2.1 创建线程前，先理解 pthread_create 的完整面貌

先看函数签名，这是所有 pthread 程序的入口：

c复制#include <pthread.h>

int pthread_create(pthread_t *thread,
                   const pthread_attr_t *attr,
                   void *(*start_routine)(void *),
                   void *arg);

四个参数分别是线程 ID 输出、线程属性、线程入口函数、入口函数参数。这里有几个新手最容易踩的坑：

第一个坑是 attr 传 NULL 到底意味着什么。传 NULL 表示使用默认属性，默认情况下线程栈大小由系统决定。在 glibc 的 Linux 实现里，默认线程栈大小通常是 8MB。注意，这个 8MB 是虚拟内存的预留，不是每创建一个线程就立刻占满物理内存，但如果你创建 1000 个线程，光栈虚拟内存就会占掉 8GB 的地址空间。在 32 位程序里，这个数字直接逼近整个地址空间上限，所以老嵌入式项目里很少有人开上千线程。如果你确实需要大量线程，就用 pthread_attr_setstacksize() 显式调小栈，比如设为 256KB，而且你要确定线程函数里不会深递归、不会有大的局部数组，否则轻则段错误，重则踩坏相邻内存。

第二个坑是返回值。pthread 家族的函数基本上都是“成功返回 0，失败返回错误码”，它不像 open、write 那样设置 errno。所以你收到非零返回值时，不能用 perror() 去打印，而要用 strerror(ret)：

c复制int ret = pthread_create(&tid, NULL, worker, NULL);
if (ret != 0) {
    fprintf(stderr, "pthread_create failed: %s\n", strerror(ret));
    exit(EXIT_FAILURE);
}

常见错误码里，EAGAIN 表示系统线程资源不够或超出 RLIMIT_NPROC 限制，EINVAL 说明属性参数不合法，ENOMEM 是内存不足。排查创建失败时先对着这几个码看，能省很多时间。

第三个坑是你传给线程的参数生命周期。我经常在代码评审里看到这种写法：

c复制for (int i = 0; i < 4; i++) {
    pthread_create(&tid[i], NULL, worker, &i);  // 危险
}

i 是主线程栈上的局部变量，每个线程拿到的是同一个地址。最终四个线程读到的值可能全是 4，或者线程启动时机不同读到的值各不相同。解决办法是给每个线程单独分配一块小内存存放参数，线程函数里自行负责释放：

c复制int *arg = malloc(sizeof(int));
*arg = i;
pthread_create(&tid[i], NULL, worker, arg);

void *worker(void *p) {
    int val = *(int *)p;
    free(p);
    // ...
}

2.2 join 还是 detach：线程资源回收的二选一

线程创建后，摆在面前的第一道选择题就是：到底要不要 pthread_join。pthread_join 的作用是阻塞等待目标线程结束，并回收它的资源，同时可以取回线程的返回值：

c复制int pthread_join(pthread_t thread, void **retval);

如果主线程只 pthread_create 却从不 join，也不 detach，线程结束后它占用的栈、线程控制块、TLS 资源都不会被系统回收。这个问题在短命线程上尤其隐蔽：每次创建线程泄漏一点，长时间运行后进程的内存和线程数会缓慢上涨，直到创建失败。所以有一条硬规矩：要么 join，要么 detach，不要留着线程资源不管。

那 detach 是什么？pthread_detach(tid) 是把线程标记为“分离状态”，分离线程结束之后由系统自动回收资源，你不能再对它调用 pthread_join，否则会返回 EINVAL。哪些场景适合 detach？比如线程池里只干活、结果通过队列或全局变量传递、完全不需要调用方等待的工作线程。再比如一次性后台任务，跑完就结束，也没人关心返回值，直接 detach 最简单。

我这里给一个完整示例，展示 join 取返回值的常见写法：

c复制#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <pthread.h>

void *worker(void *arg) {
    int id = *(int *)arg;
    sleep(id);
    return (void *)(long)(id * 10);
}

int main(void) {
    pthread_t tid[3];
    int ids[3] = {1, 2, 3};

    for (int i = 0; i < 3; i++) {
        int ret = pthread_create(&tid[i], NULL, worker, &ids[i]);
        if (ret != 0) {
            fprintf(stderr, "create failed: %s\n", strerror(ret));
            exit(EXIT_FAILURE);
        }
    }

    for (int i = 0; i < 3; i++) {
        void *retval = NULL;
        pthread_join(tid[i], &retval);
        printf("thread %d returned: %ld\n", i, (long)retval);
    }
    return 0;
}

注意两点：一是 (void *)(long) 这种整数与指针之间的转换，是为了绕过“从指针转整数截断”的告警，实际业务里返回指针也可以；二是 join 一个已经 detach 的线程是非法的，反过来先 join 后 detach 也没有意义，二者只能选其一。

2.3 编译链接必须用 -pthread，而不是只加 -lpthread

这是我想单独拎出来讲的一个点，因为太多人在编译这一步踩坑。很多老资料会告诉你链接线程库要加 -lpthread，这在大多数情况下确实能链接成功，但它并不完整。正确做法是编译和链接都加 -pthread：

bash复制gcc -O2 -g -pthread -o demo demo.c

为什么？-lpthread 只做了一件事：链接 libpthread 库。而 -pthread 除了链接，还会给编译过程定义 _REENTRANT 之类的宏，影响 glibc 头文件的声明。典型影响是，某些函数在多线程环境下需要提供可重入版本，比如 errno 会从普通全局变量替换为线程局部存储版本。如果只用 -lpthread，运气好程序能跑，但可能遇到一些诡异的线程安全问题。我建议所有新项目统一用 -pthread，别在这上面省事。

另外提醒一句，使用 CMake 时在 target_link_libraries 里写 Threads::Threads，并加 find_package(Threads REQUIRED)；这比手写 -pthread 更通用，跨平台时不用改。

3. 线程同步：锁、条件变量和读写锁怎么选

3.1 互斥锁：最基本也最容易写错的同步原语

没有同步的共享数据访问，是绝大多数线程 bug 的根源。先看一个经典的实验，两个线程各自对同一个全局变量做一千万次自增：

c复制#include <pthread.h>
#include <stdio.h>

static long counter = 0;
#define LOOP 10000000

void *inc(void *arg) {
    for (long i = 0; i < LOOP; i++) {
        counter++;
    }
    return NULL;
}

int main(void) {
    pthread_t t1, t2;
    pthread_create(&t1, NULL, inc, NULL);
    pthread_create(&t2, NULL, inc, NULL);
    pthread_join(t1, NULL);
    pthread_join(t2, NULL);
    printf("counter = %ld\n", counter);
    return 0;
}

用 -O2 -pthread 编译后跑几次，结果大概率不是 20000000，而是 1500 万左右，每次结果还不一样。原因很简单：counter++ 对应的机器指令是“读内存、寄存器和加一、写回内存”，两个线程可能同时读到同一个旧值，各自加一后写回，最终只增加了一次。这就是数据竞争。

加入互斥锁之后，问题立刻解决：

c复制static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;

void *inc(void *arg) {
    for (long i = 0; i < LOOP; i++) {
        pthread_mutex_lock(&lock);
        counter++;
        pthread_mutex_unlock(&lock);
    }
    return NULL;
}

这里 PTHREAD_MUTEX_INITIALIZER 是静态初始化锁的宏，等价于在 main 里调用 pthread_mutex_init(&lock, NULL)。关于互斥锁的使用，我有几条经常在代码评审里重复的忠告：

第一，临界区要尽量短。锁里面只放必须保护的共享数据修改，不要把 IO、复杂计算、日志打印都塞进去。我曾经在一个项目里见过有人把整段业务逻辑都包在锁里，结果 64 线程并发退化成接近串行，吞吐惨不忍睹。

第二，加锁和解锁必须成对。任何一条提前 return 的路径，都可能造成锁没释放，别的线程永远阻塞。所以复杂函数里更推荐“先算完，最后再上锁改共享状态”的策略，让临界区单点进出。

第三，尽量不要用递归锁。PTHREAD_MUTEX_RECURSIVE 允许同一个线程多次加同一把锁，听起来很方便，但它经常掩盖代码里混乱的调用关系。默认的非递归锁如果出现同线程重入，会返回 EDEADLK，这其实是在帮你暴露问题。

第四，别忘了销毁锁。进程退出前对锁调用 pthread_mutex_destroy，如果返回 EBUSY，说明还有线程持有锁，你要先处理完线程再销毁。虽然进程退出时系统会清理，但在长生命周期进程中动态创建销毁锁的场景，漏掉 destroy 同样会积累资源。

3.2 条件变量：让线程等一个“状态”而不是死转

互斥锁解决的“互斥访问”问题，但很多时候我们还需要“等待某个条件成立”。最原始的写法是轮询：

c复制while (flag == 0) {
    usleep(1000);
}

这种写法很浪费 CPU，而且延迟不可控。条件变量就是为了解决这个问题的。它让一个线程阻塞等待条件成立，另一个线程在状态变化后发出通知。API 核心是四件套：

• pthread_cond_wait(cond, mutex)：阻塞等待通知，同时原子性地释放互斥锁；
• pthread_cond_signal(cond)：唤醒一个等待线程；
• pthread_cond_broadcast(cond)：唤醒所有等待线程；
• 配套的全局状态变量。

条件变量有两个极其重要的细节，新手几乎都会踩：

第一个细节是条件变量必须和共享状态变量一起用。你不太可能在没有任何状态标志的情况下仅仅靠 cond 完成同步。因为 signal 本身没有记忆，如果线程 A 在“生产者”还没有 signal 之前就去 wait，那没问题；可如果生产者先执行完 signal，消费者还没来得及 wait，这个信号就丢了。所以在 wait 之前要先检查状态标志，状态不满足才进入等待。

第二个细节是 wait 返回后不能假设条件一定满足，必须用 while 重新检查状态，而不是 if。所谓“虚假唤醒”在 POSIX 里是被允许发生的，另外也可能有多个消费者被同一个 signal 唤醒，竞争到锁的线程不一定就是你。所以标准写法永远是：

c复制pthread_mutex_lock(&mtx);
while (ready == 0) {
    pthread_cond_wait(&cond, &mtx);
}
// 现在拿到了锁，并且 ready == 1
pthread_mutex_unlock(&mtx);

一个典型的生产者-消费者代码骨架大致长这样：

c复制pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
int ready = 0;

void *consumer(void *arg) {
    pthread_mutex_lock(&mtx);
    while (ready == 0) {
        pthread_cond_wait(&cond, &mtx);
    }
    printf("consume done\n");
    pthread_mutex_unlock(&mtx);
    return NULL;
}

void *producer(void *arg) {
    usleep(100000);
    pthread_mutex_lock(&mtx);
    ready = 1;
    pthread_cond_signal(&cond);
    pthread_mutex_unlock(&mtx);
    return NULL;
}

pthread_cond_wait 内部会先释放 mtx，然后阻塞；被唤醒后会重新抢回 mtx 再返回。这个过程保证了“修改状态”和“检查状态”不会交叉，你不需要在 wait 前后手动解锁。如果要在超时时间内等待，可以用 pthread_cond_timedwait，传入绝对时间，返回 ETIMEDOUT 表示超时。

这里我还想多提醒一句：signal 只唤醒一个线程，broadcast 唤醒所有。如果多个线程等在同一个条件上，比如“主任务完成，所有子任务都开始处理”，就应该用 broadcast；如果只是“队列里有新任务”，并且你有一堆消费者在抢任务，那用一个 signal 唤醒一个消费者通常效率更高。

3.3 读写锁与自旋锁：什么时候才值得换

互斥锁的问题是它完全不区分读和写。如果某个共享数据结构是“读多写少”，比如配置表、路由表，每次读都用互斥锁保护，多个读线程会互相阻塞，白白浪费并发能力。这种场景适合读写锁 pthread_rwlock_t：

c复制pthread_rwlock_rdlock(&rwlock);   // 读锁，可多个线程同时持有
// 只读数据...
pthread_rwlock_unlock(&rwlock);

pthread_rwlock_wrlock(&rwlock);   // 写锁，独占
// 修改数据...
pthread_rwlock_unlock(&rwlock);

读写锁的语义是：多个读者可以同时进入临界区，但写者和读者互斥、写者和写者也互斥。使用它的收益非常依赖实际读写比例。如果你的代码里写操作也很多，读写锁可能比互斥锁更慢，因为它内部要维护读者计数和等待队列，开销更大。我在项目里习惯先加互斥锁上线，性能测试发现读并发确实成为瓶颈后，再考虑换成读写锁，避免过早优化。

自旋锁则是另一条路线。pthread_spinlock_t 的特点是：拿不到锁时不睡眠，而是原地忙等，一直循环检测锁状态。它避免了线程睡眠和唤醒的上下文切换开销，代价是占满一个 CPU 核心。所以自旋锁只适合临界区极短且线程不会长时间持锁的场景，比如多核环境下对一个计数器加一。如果临界区里有系统调用、IO、pthread_cond_wait 这类可能阻塞的操作，绝对不能使用自旋锁，否则就是自旋 + 睡眠的死循环组合。

我把三种锁的使用场景整理成一张表，方便对照选择：

无论用哪种锁，我建议你多打一个原则：能用原子操作解决的，优先用原子操作。C11 的 atomic_*、__atomic_add_fetch 这类原语，比锁轻量得多。比如前面那个 counter++ 的累加，用 __atomic_add_fetch(&counter, 1, __ATOMIC_SEQ_CST) 一行就能解决，完全不需要锁。锁解决的问题是“临界区里的多步操作”，原子操作解决的是“单个内存操作”，两者边界要分清。

4. 线程生命周期管理：取消、分离与局部存储

4.1 pthread_cancel 不是强杀：取消点和取消状态才是重点

当你想让一个线程停下来，C 语言里没有“kill 线程”这种暴力接口。最接近的是 pthread_cancel(tid)，但它只发送一个“取消请求”，线程并不会立刻死亡。默认情况下，目标线程的运行状态是 PTHREAD_CANCEL_DEFERRED，也就是延迟取消：线程要运行到下一个取消点才会真正退出。

取消点是指那些可能导致线程阻塞的系统调用或库函数，比如 read、write、nanosleep、pthread_cond_wait、pthread_join 等。这些函数在进入阻塞前会检查取消请求，如果已被取消，就触发线程终止。反过来，如果线程一直在纯计算循环里跑，没有任何取消点，那么调用 pthread_cancel 后线程会一直执行下去，看起来像取消失败。如果你希望这个计算循环能被快速取消，可以在循环体里手动加一个取消点：

c复制pthread_testcancel();

pthread_testcancel 专门用来检查挂起的取消请求，如果没有请求，它立刻返回，开销极小。

还可以更进一步，用 pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL) 把线程改成异步取消。这个模式下线程可能在任何指令处被终止，资源释放和一致性都无法保证，我强烈建议业务代码不要用。事实上，异步取消带来的不确定性远大于方便，除非你彻底清楚线程的每一条指令边界。

还有一个容易被忽略的点：pthread_cancel 只对目标线程发起请求，不等待它退出。如果你要等它确实退出了再继续，需要再做一次 pthread_join。标准做法是：pthread_cancel(tid) 之后立即 pthread_join(tid, &retval)，这样既发了取消请求，又能确认线程真的结束了。

4.2 cleanup 回调：取消时正确释放锁和内存

取消请求到达取消点时，线程会立即终止，这意味着线程栈上正在执行的函数不会继续，free、pthread_mutex_unlock 这类“之后再做”的清理代码就不会执行了。Pthread 提供了线程清理回调机制，专门解决这个问题。API 是成对出现的：

c复制void pthread_cleanup_push(void (*routine)(void *), void *arg);
void pthread_cleanup_pop(int execute);

push 注册一个清理函数，pop 弹出注册的函数并决定是否执行它。我通常这样用：

c复制void cleanup(void *arg) {
    pthread_mutex_unlock((pthread_mutex_t *)arg);
}

void *thread_func(void *arg) {
    pthread_mutex_lock(&mtx);
    pthread_cleanup_push(cleanup, &mtx);

    // 这里阻塞在取消点上，如果线程在这里被取消，
    // cleanup 函数仍会被调用，锁得以释放。
    while (1) {
        pthread_cond_wait(&cond, &mtx);
    }

    pthread_cleanup_pop(1);
    return NULL;
}

关键点有三个：push 和 pop 必须写在同一作用域内，因为它在底层是用宏实现的，展开后是一对 __do 循环，跨作用域会导致语法错误；pthread_cleanup_pop(1) 表示弹栈并执行清理函数，传 0 则只弹栈不执行；如果线程正常 return 或 pthread_exit，所有尚未弹出的清理函数也会在退出时自动执行。这意味着你可以在每个可能被取消的临界区外面挂好清理回调，让线程无论怎么死都不会漏释放锁和内存。

4.3 线程局部存储：每个线程自己的“私有空间”

多个线程共享全局变量的同时，有时又需要“每个线程一份独立副本”。最典型的例子就是 errno，每个线程发生错误时记录自己的错误码，不能被其他线程覆盖。C 语言提供了 __thread 关键字，声明方式很简单：

c复制static __thread int thread_local_value = 0;
static __thread char buf[512];

__thread 修饰的变量，每个线程都有一份独立实例。它比传统做法（用线程 ID 查数组）高效得多，编译后通常落到 ELF 的 .tbss 段，访问时通过线程控制块偏移量定位，几乎零开销。

如果你需要更动态的线程局部存储，比如在库代码里为每次调用创建不同大小的对象，可以用 pthread_key_t 家族：

c复制pthread_key_t key;

void destructor(void *v) {
    free(v);
}

void init(void) {
    pthread_key_create(&key, destructor);
}

void worker(void) {
    int *local = pthread_getspecific(key);
    if (local == NULL) {
        local = malloc(sizeof(int));
        pthread_setspecific(key, local);
    }
    // 使用 local
}

注意 pthread_key_create 可以同时注册一个析构函数，线程退出时会自动调用，把 malloc 出来的内存释放掉。PTHREAD_KEYS_MAX 限制了系统中同时存在的 key 数量（Linux 上一般是 1024），所以 key 也要在合适时机 pthread_key_delete。相比之下，__thread 范围更简单直接，在业务代码里优先用它，只有需要“按需创建 + 自动析构”时才考虑 pthread_key_t。

5. 多线程排障：从工具链到常见坑位

5.1 排查基本功：top -H、ps -L 与 gdb thread

多线程程序出问题，第一件事不是看代码，而是看现场。top 默认只显示进程维度的 CPU，加 -H 参数后每个线程一行，能快速看出哪个线程吃满了 CPU、哪个线程处于 R 状态死循环。如果想确认具体哪个线程对应执行到哪儿，配合 ps -L -p <pid> 能列出进程内所有线程的 LWP，也就是线程 ID。

拿到可疑线程 ID 后，用 gdb 一帧一帧看：

bash复制gdb -p <pid>
(gdb) thread apply all bt
(gdb) thread <id>
(gdb) bt

thread apply all bt 是所有线程栈一把梭，排查死锁时尤其有用。你能直接看到线程 A 等锁，线程 B 持有锁并且也在等另一把锁，锁的循环等待链条一目了然。另外调试多线程时记得设置 scheduler-locking on，否则默认情况下 gdb 单步某个线程时会随机切换到其他线程，干扰判断逻辑。加了这个设置后，单步执行就只走当前线程，不会再被别的线程打断。

5.2 用 Valgrind 抓数据竞争和死锁的隐形 bug

前面讲的数据竞争，很多是偶发性的，运行十次可能只错一次。人工排查效率太低，这时候上 Valgrind。两个工具：helgrind 和 drd，都能检测内存竞争和锁的使用错误。

bash复制gcc -O0 -g -pthread demo.c -o demo
valgrind --tool=helgrind ./demo

使用 Helgrind 前编译要带 -g，优化级别建议 -O0，否则行号和变量信息会失真。它会报告哪条指令访问了哪个变量、与哪条线程指令发生竞争，还会检测出解锁不匹配、重复解锁之类的问题。drd 也可以做类似检测，两者选一个熟悉即可。注意检测工具对性能影响较大，适合在测试环境和 CI 里跑，不适合生产环境久跑。

如果程序只是偶尔卡死但无法稳定复现，可以在现场用 gdb -p 批量抓几次线程栈，或者用 pstack <pid> 抓瞬间栈。卡死问题往往是锁顺序不一致造成的死锁，修复思路是给所有锁定义全局顺序，按同一顺序加锁，避免循环等待。

5.3 常见问题速查表

我把这几年实际运维和开发中遇到的多线程问题整理成了一张速查表，遇到现象直接对着找方向：

还有一个我特别想强调的坑：不要在主线程之外的线程里随意调用 exit()。exit() 会终止整个进程，所有线程都会被强制结束，哪怕其他线程正在修改关键数据。如果业务线程需要结束，使用 return、pthread_exit 或让进程走统一的退出流程，千万不要直接调 exit 让整个服务突然消失。

在实际项目里还有一个体会想分享：线程代码写多了之后你会发现，90% 的问题不是 pthread API 本身，而是共享数据的设计。谁拥有这份数据、谁负责修改、谁负责释放，这些责任划分清楚了，锁和条件变量只是顺手的工具。每次代码评审时，我会特别关注全局变量被几处访问、锁的粒度是不是过粗、线程退出时有没有清理回调这三件事。把这三件事守住，多线程程序基本就稳了一大半。