Linux多线程编程核心：POSIX线程库pthread实战指南

搞Linux开发绕不开多线程，而只要聊到线程，POSIX线程库（pthread）就是那块绕不过去的基石。很多初学者在理解线程概念时觉得挺清楚，一到写代码就抓瞎：pthread_create的参数怎么填？线程退出到底用return还是pthread_exit？pthread_join和pthread_detach有什么区别？这些看似简单的问题，实际写起来全是坑。这篇文章就基于我实际使用POSIX线程库的经验，把线程控制相关的核心API一次讲透，从创建、退出、回收，到同步、互斥、条件变量，配合代码示例和踩坑记录，希望能帮你在Linux线程编程这条路上少走点弯路。

1. POSIX线程库设计与整体思路

1.1 为什么Linux线程编程绕不开pthread

先说个很多人忽略的事实：Linux内核里其实没有“线程”这个概念，内核只认识任务（task），线程在kernel眼里就是共享了地址空间、文件描述符表等资源的轻量级进程。所以用户在应用层写的线程，最终都是通过clone系统调用创建的，只是传入的参数不同，决定了父子任务之间共享哪些资源。

那为什么不直接封装clone，而要搞出一个pthread库？原因其实很务实。clone是系统调用，参数多、语义复杂、可移植性差，不同的Unix-like系统对“线程”的实现差异很大。为了让开发者在不同系统上写出一份可移植的多线程代码，POSIX标准定义了pthread线程接口，把底层的实现细节全部屏蔽掉。你写的pthread_create在Linux上可能映射到clone，在FreeBSD上可能是别的机制，但你的代码不用改。这就是pthread存在的最大价值：可移植性。

另一个层面的原因是，单纯创建内核任务根本不够用，线程的“控制”和“同步”才是真正复杂的地方。pthread库不仅提供线程的创建和回收，还提供了完整的同步原语：互斥锁、条件变量、读写锁、自旋锁、屏障，这些才是做并发编程的真正难点所在。

1.2 从NPTL说起：现代Linux的线程实现

早期Linux的线程实现是LinuxThreads，它有很多设计缺陷，比如线程信号处理不一致、getpid返回不同值导致一些库函数行为异常等。后来Red Hat主导开发了NPTL（Native POSIX Thread Library），从glibc 2.3.2开始成为默认实现，一直沿用到现在。

NPTL的核心设计理念是“1:1线程模型”，即一个用户线程对应一个内核任务。这样做的好处是线程调度由内核统一管理，多核CPU可以真正并行执行不同线程；缺点是每次线程创建和上下文切换都要陷入内核，性能比用户态线程模型（如早期的GNU Portable Threads）差一些，但换来的是简单性和强健壮性。

了解这个背景有助于理解后面的一些API行为。比如为什么pthread_join会阻塞？因为底层是内核任务，线程退出后需要回收其内核资源，join的过程相当于等待任务结束并回收资源。再比如为什么线程栈默认有8MB大小？那也是内核任务栈的映射策略决定的，用ulimit -s可以查看。

1.3 编译和链接的基础配置：一个参数引发的血案

很多新手第一次写pthread程序，编译时直接gcc test.c，报了一堆错，最经典的就是：

bash复制undefined reference to `pthread_create'

这不是代码问题，而是链接问题。pthread库不是libc的内置部分，从glibc 2.34开始才合并到libc里，在这之前都要显式链接：

bash复制gcc test.c -o test -pthread

注意这里是-pthread而不是-lpthread，两者有一定兼容性差异。-pthread不仅仅做链接，还会在编译期定义_REENTRANT宏，这个宏会影响某些头文件的声明行为，让一些函数变成线程安全版本。所以统一的建议是：一律用-pthread或-pthreads，不要用-lpthread。

另外还有个常见坑：在较老版本的glibc上，链接顺序也可能导致问题。如果写成gcc -lpthread test.c -o test，某些老版本编译器可能会因为依赖顺序问题报错，所以尽量把库放在源文件后面。

2. 线程生命周期管理：从创建到回收

2.1 pthread_create：透彻理解四个参数

先看函数原型：

c复制#include <pthread.h>

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

参数逐个拆解：

第一个参数是pthread_t指针，用于接收线程ID。注意这个ID是线程库层面的标识符，不是内核线程ID。pthread_t在不同平台上类型不同，在Linux glibc上是unsigned long类型，在别的系统上可能是指针。所以不要把pthread_t当成整数滥用，需要比较线程相等性时用pthread_equal()。

第二个参数是线程属性指针，传NULL表示使用默认属性。默认属性包括：线程栈大小8MB、调度策略为SCHED_OTHER、分离状态为joinable等。关于属性的详细设置在后面单独展开。

第三个参数是线程入口函数，接受void参数返回void。这其实就是线程执行的代码块，线程创建成功后，入口函数从头开始执行，执行完毕线程自动退出。

第四个参数是传给入口函数的参数。这里有一个高频坑：如果传的是一个局部变量的地址，而主线程在这个局部变量生命周期结束后才创建线程并读取，就会产生悬垂指针。正确的做法是传堆上分配的内存或static变量，线程使用完后自行释放。

2.2 线程的真正入口：start_routine的细节

入口函数的签名是void *(*start_routine)(void *)，这意味着它可以传递任意类型的数据，返回任意类型的数据。这种设计让线程的数据交换变得很灵活。

一个值得注意的细节是：线程入口函数如果直接返回，相当于在线程内部调用了pthread_exit(retval)。这个返回值会被pthread_join捕获，成为线程的退出状态。

如果入口函数想提前终止线程，可以调用pthread_exit()，它接受一个void*指针作为退出状态。一旦调用pthread_exit，该线程立即终止，其资源不会被自动回收（除非设置为detached），而是等待其他线程调用pthread_join来回收。

跑一个简单的例子：

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

void *worker(void *arg) {
    int id = *(int *)arg;
    printf("线程 %d 开始工作\n", id);
    sleep(1);
    printf("线程 %d 结束工作\n", id);
    return (void *)(long)(id * 10);
}

int main() {
    pthread_t t1, t2;
    int id1 = 1, id2 = 2;
    void *ret1, *ret2;

    pthread_create(&t1, NULL, worker, &id1);
    pthread_create(&t2, NULL, worker, &id2);

    pthread_join(t1, &ret1);
    pthread_join(t2, &ret2);

    printf("线程1返回: %ld, 线程2返回: %ld\n", (long)ret1, (long)ret2);
    return 0;
}

这里有个小细节：return (void )(long)(id * 10) 这种把整数转成指针再转回来的做法在C语言里是合法的，但要注意整数和指针的大小匹配。在64位系统上long是8字节，void也是8字节，没问题。在32位系统上int是4字节，如果直接return (void*)id会留下4字节的垃圾数据，所以要先转long再转指针。

2.3 pthread_join与pthread_detach：线程资源的回收机制

线程退出后，它的资源不会自动释放（除非设置了detach属性），这些资源包括线程栈、内核任务描述符等。如果一直不回收，就会积累成“僵尸线程”，类似于僵尸进程，慢慢耗尽系统资源。

pthread_join是阻塞式回收函数，调用后主线程会一直等待目标线程结束，然后回收其资源，并通过第二个参数接收线程的退出状态。适合需要知道执行结果的场景。

pthread_detach则将线程设为分离状态，分离后线程结束时会自动回收资源，不再需要join，也无法再join。调用detach之后，不能再对同一个线程调用join，否则行为未定义（通常直接出错）。

c复制pthread_t tid;
pthread_create(&tid, NULL, worker, NULL);
pthread_detach(tid);
// 之后不能再 pthread_join(tid, NULL)

选择策略很简单：需要线程结果的就join，不需要的就detach。但要注意detach和join只能二选一，不能同时用。

2.4 线程退出总动员：return、pthread_exit、pthread_cancel的区别

三个退出路径各有适用场景：

一是入口函数return，最自然的退出方式，函数结束线程即结束，返回值就是退出状态。适合正常的、预期内的结束。

二是pthread_exit()，在入口函数内部的任何位置手动调用，可以提前终止线程，适合处理错误分支或条件性退出。注意如果在主线程中调用pthread_exit，主线程会退出，但进程不会立即终止，其他线程会继续运行，直到所有非detach线程都退出后进程才退出。这和main函数return有本质区别。

三是pthread_cancel()，由其他线程发起取消请求，目标线程在取消点（cancellation point）被终止。这个机制比较微妙，后面说常见问题时会详细展开。

c复制void *worker(void *arg) {
    for (int i = 0; i < 10; i++) {
        if (i == 3) {
            pthread_exit((void *)"提前退出");
        }
        printf("处理 %d\n", i);
    }
    return (void *)"正常结束";
}

3. 线程ID与属性设置：细节决定成败

3.1 pthread_t、pthread_self与系统线程ID的辨析

先说结论：pthread_t不是线程ID。

pthread_t是POSIX线程库用来标识线程的句柄，在Linux上它是一个unsigned long整数，在其它系统上可能是结构体指针。它只在创建它的进程上下文中有意义，而且不能保证全局唯一。

要获取当前线程的pthread_t，用pthread_self()。要比较两个pthread_t是否相等，用pthread_equal(thread1, thread2)。

如果想获取内核线程ID（即PID/TID），需要调用系统调用syscall(SYS_gettid)或使用gettid()。在某些调试场景，比如用gdb attach到进程后想看某个线程的内核ID，就需要这个值。二者对应关系是NPTL下的一一映射，但业务代码里通常不需要关心内核TID，除非你是在做性能分析或者排查CPU占用异常。

3.2 pthread_attr_t：定制线程栈大小与调度策略

默认线程栈大小通常是8MB，但对某些场景来说太大了（嵌入式系统内存紧张），或者太小了（深度递归计算需要更大栈）。用pthread_attr_t可以在创建前设置栈大小。

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

int main() {
    pthread_attr_t attr;
    pthread_t tid;
    size_t stack_size;

    pthread_attr_init(&attr);
    pthread_attr_getstacksize(&attr, &stack_size);
    printf("默认栈大小: %zu bytes\n", stack_size);

    // 设置为16MB
    pthread_attr_setstacksize(&attr, 16 * 1024 * 1024);

    pthread_attr_getstacksize(&attr, &stack_size);
    printf("设置后栈大小: %zu bytes\n", stack_size);

    pthread_create(&tid, &attr, worker, NULL);
    pthread_join(tid, NULL);
    pthread_attr_destroy(&attr);
    return 0;
}

补充一个坑：pthread_attr_init之后一定要对应pthread_attr_destroy，虽然这个函数在Linux上几乎不做任何事，但为了可移植性，该写的还是要写。

另一个属性是detachstate，可以在创建时就指定分离状态：

c复制pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);

设置了detachstate之后，线程创建后自动变成分离状态，不需要再调用pthread_detach。这比创建后手动detach更保险，可以避免遗漏导致的资源泄漏。

3.3 调度策略与优先级：什么时候才需要关心

Linux下pthread默认调度策略是SCHED_OTHER（CFS完全公平调度），线程优先级概念在这个策略下意义不大。真正需要设置优先级时，一般是用SCHED_FIFO或SCHED_RR这两种实时调度策略。

注意设置实时调度策略需要root权限，否则pthread_create会返回EPERM错误。而且实时调度策略如果设计不好，可能把CPU耗尽，导致系统卡死，强烈不建议在生产环境随意使用。

c复制struct sched_param param;
param.sched_priority = 80;
pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
pthread_attr_setschedparam(&attr, &param);

如果只是想让某个线程优先级高一点，更安全的做法是用nice值或者设置CPU亲和性，而不是直接上实时调度。

4. 线程同步实战：互斥锁与竞态条件

4.1 从一次计数器增加引发的血案说起

先来看一个经典问题：两个线程同时对同一个全局变量执行++操作，每个线程循环100万次，最终结果是不是200万？

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

#define LOOP_COUNT 1000000

long counter = 0;

void *increment(void *arg) {
    for (int i = 0; i < LOOP_COUNT; i++) {
        counter++;
    }
    return NULL;
}

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

我实测了很多次，结果一般在120万到170万之间波动，极少达到200万。原因在于counter++不是原子操作，它底层对应三条指令：读取counter值到寄存器、寄存器加1、把新值写回内存。两个线程可能在读取到同一个值后都加1并写回，导致两个线程各加了一次，但内存里只增加了一次。这就是经典的竞态条件（race condition）。

4.2 互斥锁的核心API：从初始化到销毁

解决竞态条件最直接的武器就是互斥锁。POSIX提供的API主要就五个：pthread_mutex_init、pthread_mutex_lock、pthread_mutex_trylock、pthread_mutex_unlock、pthread_mutex_destroy。

使用流程很固定：

c复制pthread_mutex_t mutex;

// 方式一：静态初始化
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

// 方式二：动态初始化
pthread_mutex_init(&mutex, NULL);

// 加锁
pthread_mutex_lock(&mutex);
// 临界区代码
counter++;
// 解锁
pthread_mutex_unlock(&mutex);

// 销毁锁
pthread_mutex_destroy(&mutex);

PTHREAD_MUTEX_INITIALIZER静态初始化适用于默认属性的锁，不需要销毁。动态初始化更灵活，可以指定锁属性。

写一个正确版本：

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

#define LOOP_COUNT 1000000

long counter = 0;
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

void *increment(void *arg) {
    for (int i = 0; i < LOOP_COUNT; i++) {
        pthread_mutex_lock(&mutex);
        counter++;
        pthread_mutex_unlock(&mutex);
    }
    return NULL;
}

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

每次加锁解锁都涉及系统调用（futex），这个版本比无锁版本慢了很多，但结果是正确的，永远是200万。

4.3 互斥锁属性：错误检查锁、递归锁与优先级继承

pthread_mutexattr_t可以设置锁的类型，主要有三种：

PTHREAD_MUTEX_NORMAL对应普通锁，默认类型，不检测死锁。如果同一线程重复lock，就会死锁。

PTHREAD_MUTEX_ERRORCHECK是错误检查锁，内核会检测重复加锁的情况，返回EDEADLK错误而不是死锁。这个类型会带一点性能开销，但调试时非常有用。

PTHREAD_MUTEX_RECURSIVE是递归锁，允许同一个线程多次加锁。内部有计数机制，加锁几次就需要解锁几次。适用场景是递归函数内部需要加锁的情况，但一般来说能用递归锁解决的，换个设计思路可能更好。

c复制pthread_mutexattr_t attr;
pthread_mutex_t mutex;

pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK);
pthread_mutex_init(&mutex, &attr);

// 重复加锁返回EDEADLK
if (pthread_mutex_lock(&mutex) != 0) {
    printf("第一次加锁\n");
}
int ret = pthread_mutex_lock(&mutex);
if (ret == EDEADLK) {
    printf("检测到死锁，返回错误\n");
}

还有一个属性是协议相关的PTHREAD_PRIO_INHERIT，用于优先级反转场景。如果一个低优先级线程持有锁，而高优先级线程在等待这个锁，优先级继承协议会临时把低优先级线程的优先级提升到高优先级，避免高优先级线程被无限期阻塞。在实时系统中这个很重要，普通应用很少用到。

4.4 锁的作用范围与粒度控制心得

实践中我总结出一个简单原则：锁的粒度尽量小。临界区只放真正需要保护的代码，不要把无关计算塞进去。但粒度太小又会导致频繁加锁解锁的开销增加。怎么权衡？用数据说话，先写好正确版本，再用性能分析工具（perf）定位瓶颈，最后再看值不值得优化。

另一个容易忽略的地方：锁的顺序。多个线程持有多个锁的时候，一定要保持全局一致的加锁顺序，否则就会死锁。比如线程A先锁mutex1再锁mutex2，线程B先锁mutex2再锁mutex1，那么当A持有1等待2、B持有2等待1时，就进入死锁状态。实际工程中我习惯用一个文档记录所有锁的层级顺序，代码评审时重点检查这一步。

5. 条件变量与生产者消费者模型

5.1 为什么有了互斥锁还不够

互斥锁解决的是“同一时间只能一个线程访问资源”的问题，但有些场景需要“等待某个条件成立再继续”。比如生产者消费者模型中，消费者在队列为空时应该等待，而不是反复加锁检查队列是否非空。轮询检查浪费CPU，而且会引入严重的锁竞争。

条件变量就是用来解决这个问题的。它允许一个线程在条件不满足时进入睡眠等待，直到另一个线程修改了条件，主动发出通知，等待线程被唤醒继续执行。这比轮询高效得多。

5.2 pthread_cond_wait为什么必须传锁

条件变量的核心API：

c复制int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);
int pthread_cond_signal(pthread_cond_t *cond);
int pthread_cond_broadcast(pthread_cond_t *cond);

最关键的pthread_cond_wait有双重功能：一是让出CPU进入等着唤醒的队列，二是原子地释放传入的互斥锁。原子性这个细节很重要，它保证“线程在检查条件之后、进入睡眠之前”这段时间内，锁已经被释放，其他线程可以拿到锁修改条件。

如果这个释放不是原子的，就会出现经典的问题：消费者线程检查条件发现队列为空，还没来得及进入睡眠，它的时间片用完了；此时生产者线程拿到锁，向队列里放了一个元素并发送signal；消费者重新获得CPU后进入睡眠，错过了这个signal，永远无法被唤醒。

pthread_cond_wait内部帮你避免了这个问题，这就是它必须传锁的原因。这也解释了为什么调用pthread_cond_wait前必须已经持有锁，否则行为未定义。

5.3 为什么等待条件要放在while循环里

这是条件变量使用中最容易犯的错误。标准的等待模式是：

c复制pthread_mutex_lock(&mutex);
while (queue_empty()) {
    pthread_cond_wait(&cond, &mutex);
}
// 处理队列
pthread_mutex_unlock(&mutex);

为什么是while不是if？因为pthread_cond_wait返回并不代表条件一定成立。有两种情况：

一是虚假唤醒（spurious wakeup）。POSIX标准明确允许条件变量发生虚假唤醒，线程可能在没有任何signal的情况下从wait返回。虽然x86平台上的pthread实现里极少出现，但标准没有禁止，就一定要防御。

二是多个消费者等待同一个条件，生产者发送signal只唤醒一个消费者。如果这个消费者处理完队列中的一项，队列还有剩余项，另一个消费者被唤醒后再次检查条件发现仍有数据，可能造成数据被多个消费者重复处理。

用while循环重新检查条件，是最稳妥的防御方案，代价只是多一次条件判断，几乎可以忽略。

5.4 完整的生产者消费者模型代码

写一个单生产者、单消费者的例子，用互斥锁加条件变量实现。队列直接用链表简单实现，重点是同步逻辑。

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

#define QUEUE_SIZE 5

int buffer[QUEUE_SIZE];
int count = 0;
int head = 0;
int tail = 0;

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t not_full = PTHREAD_COND_INITIALIZER;
pthread_cond_t not_empty = PTHREAD_COND_INITIALIZER;

void put(int value) {
    pthread_mutex_lock(&mutex);
    while (count == QUEUE_SIZE) {
        pthread_cond_wait(&not_full, &mutex);
    }
    buffer[tail] = value;
    tail = (tail + 1) % QUEUE_SIZE;
    count++;
    pthread_cond_signal(&not_empty);
    pthread_mutex_unlock(&mutex);
}

int get() {
    pthread_mutex_lock(&mutex);
    while (count == 0) {
        pthread_cond_wait(&not_empty, &mutex);
    }
    int value = buffer[head];
    head = (head + 1) % QUEUE_SIZE;
    count--;
    pthread_cond_signal(&not_full);
    pthread_mutex_unlock(&mutex);
    return value;
}

void *producer(void *arg) {
    for (int i = 0; i < 20; i++) {
        put(i);
        printf("生产: %d\n", i);
        usleep(100000);
    }
    return NULL;
}

void *consumer(void *arg) {
    for (int i = 0; i < 20; i++) {
        int value = get();
        printf("消费: %d\n", value);
        usleep(200000);
    }
    return NULL;
}

int main() {
    pthread_t prod, cons;
    pthread_create(&prod, NULL, producer, NULL);
    pthread_create(&cons, NULL, consumer, NULL);
    pthread_join(prod, NULL);
    pthread_join(cons, NULL);
    pthread_mutex_destroy(&mutex);
    pthread_cond_destroy(&not_full);
    pthread_cond_destroy(&not_empty);
    return 0;
}

这个示例用四个线程同步要素：一个互斥锁保护共享队列，两个条件变量分别表示“队列非空”和“队列未满”。生产者在队列满时等待not_full，消费者在队列空时等待not_empty。生产者放入数据后signal not_empty，消费者取出数据后signal not_full，互相唤醒。

5.5 signal与broadcast的选择

pthread_cond_signal只唤醒一个等待线程，pthread_cond_broadcast唤醒所有等待线程。在单消费者场景下用signal就够了。多个消费者时，如果条件满足后每个消费者都能处理一项独立任务，可以用signal逐个唤醒；但如果条件变化影响所有等待者（比如一个全局标志位的变化），就必须用broadcast。

有个性能相关的细节：signal唤醒的线程是哪一个？POSIX没有规定调度顺序，可能是先进先出，也可能不是。如果你的业务依赖于唤醒顺序，那就别指望这个特性，应该自己设计调度策略。

6. 常见问题与排查技巧实录

6.1 编译期错误的快速定位

编译pthread程序时，最常见的错误就是链接失败。

bash复制/tmp/ccX8Fj4x.o: In function `main':
test.c:(.text+0x9c): undefined reference to `pthread_create'

这个错误就是漏了-pthread参数。检查gcc命令行，把-pthread加上。

另一种是头文件相关的错误，比如报pthread_t未定义。检查是否包含了pthread.h头文件。有些老教程会写#include <pthread.h>，这个没错，但如果在编译时加了-std=c99等严格标准选项，某些平台上会提示POSIX函数声明不可见，这时候可以在编译选项里加-D_POSIX_C_SOURCE=200809L或者干脆在源码开头加#define _GNU_SOURCE。

6.2 运行期崩溃的定位思路

线程程序崩溃后的第一反应不是看代码，而是用gdb。

bash复制gdb ./demo
(gdb) run
(gdb) bt

gdb可以显示崩溃线程的调用栈，配合core dump文件可以精确还原现场。

如果是段错误（Segmentation fault），优先检查：

• 线程入口函数是否访问了被释放的内存
• 传入线程的指针参数是否还在有效生命周期内
• 线程栈是否溢出（用pthread_attr_setstacksize设置了较小的栈，加上递归或者大数组，很容易栈溢出）

僵尸线程的问题不容易直接看到，但通过top或者pthread统计工具可以发现。排查思路是：检查所有pthread_join是否都被调用，或者线程是否需要设置detach。

6.3 死锁排查的实用技巧

死锁是线程同步里最头疼的问题。先写一个典型的死锁：

c复制void *thread_a(void *arg) {
    pthread_mutex_lock(&mutex1);
    sleep(1);
    pthread_mutex_lock(&mutex2);
    pthread_mutex_unlock(&mutex2);
    pthread_mutex_unlock(&mutex1);
    return NULL;
}

void *thread_b(void *arg) {
    pthread_mutex_lock(&mutex2);
    sleep(1);
    pthread_mutex_lock(&mutex1);
    pthread_mutex_unlock(&mutex1);
    pthread_mutex_unlock(&mutex2);
    return NULL;
}

排查技巧：

1. 先看能否复现，然后在gdb里用thread apply all bt查看所有线程的调用栈，确定每个线程卡在哪个锁上。
2. 使用gdb的线程调试命令：info threads查看所有线程，切换到某个线程后bt查看调用栈，可以看到当前线程在等待哪个锁。
3. Linux下也可以用pstack命令查看进程所有线程的栈。
4. 更实用的一招：设置ulimit -c unlimited生成core文件，然后gdb分析core，直接定位到死锁现场。

如果代码复杂，多个线程加多个锁，可以在加锁前增加日志输出，把每个线程加锁的顺序和时间打出来，死锁发生时对比日志，基本能找到问题锁。

6.4 虚假唤醒与信号丢失：条件变量的隐藏陷阱

前面提过虚假唤醒，还有一类问题是信号丢失。考虑这种场景：消费线程先检查条件不满足，然后调用pthread_cond_wait；但如果生产线程在消费线程调用wait之前已经发送了signal，而消费线程此时还没进入wait队列，这个signal就白白丢失了，消费线程在等待一个永远不会再来的signal，直接陷入永久睡眠。

这就是为什么标准用法一定要用互斥锁保护条件检查和wait调用。检查条件和进入wait必须在一个锁保护下原子完成，使signal要么在wait之前被消费线程看到（条件已经为真，不用wait），要么在wait之后由内核记录在等待队列上（消费线程在wait队列里，signal能正确唤醒）。

我见过不少团队在条件变量上踩过这个坑，原因是没理解pthread_cond_wait内部释放锁和重新获取锁的语义。记住一句话：条件变量的使用必须配合互斥锁，代码模式就是上面示例里的那个样子，不要自己发明新写法。

6.5 线程安全与信号处理的深水区

另一个容易出问题的是信号处理。信号是发给进程的，进程内有多个线程，哪个线程来处理信号？POSIX标准规定，通过pthread_kill可以向特定线程发送信号，但普通使用kill发送的信号，处理线程是不确定的。

如果信号处理函数里访问了线程共享的数据，一定要考虑并发问题，甚至可以说信号处理函数本身就是一种异步并发。在信号处理函数里调用printf都是不安全的，因为printf内部有锁。更安全的做法是信号处理函数里只写一个自管道或者使用sigwait单独用一个线程处理信号。

这个知识点平时用不到，但一旦用到就是大问题，建议提前了解。

6.6 性能优化：锁竞争是最大的敌人

最后聊点性能。多线程程序跑得慢，很大概率不是线程不够多，而是锁争抢太严重。当多个线程同时尝试获取同一把锁时，系统进入串行模式，线程越多反而越慢。

常见的优化方向：

• 细粒度锁：把一把全局大锁拆成多个小锁，比如读写锁就是一个典型优化，读操作不互斥，只有写操作才独占。
• 无锁数据结构：CAS原子操作（__sync_fetch_and_add，C11的atomic_compare_exchange）配合无锁队列，在特定场景可以大幅提升吞吐量。
• 线程本地存储：使用__thread关键字或pthread_key_t，把热点数据从共享改为线程私有，从根源上消除竞争。

具体选择哪个方案，要基于业务场景做压力测试，不能凭直觉。

7. 一页纸速查表：POSIX线程API关键点整理

为了方便查阅，把本文涉及的核心API整理成一张表：

还有一个私藏的小技巧：在调试线程程序时，可以用gdb的set scheduler-locking on锁住线程调度，这样你单步调试一个线程时，其他线程不会乱跑，很容易定位逻辑问题。等调试完再set scheduler-locking off恢复。

线程编程的核心理念其实不复杂：共享数据必须同步，同步必须谨慎，不能图省事就跳过。我见过太多线上事故都是因为少加一把锁或者多加了一把大锁引起的，前者导致数据不一致，后者导致性能雪崩。用pthread写代码，多想一想线程之间的交互关系，把每个共享变量的访问路径都列举出来，再看哪些路径需要锁保护，会让你省下很多排查问题的时间。