10、多线程编程基础：pthread创建与销毁、线程同步（互斥锁、条件变量）的性能开销
多线程编程，说白了就是让程序同时干几件事。听起来很爽，对吧？但这里面的坑，我踩过不少。今天咱们就聊聊pthread的创建销毁，还有互斥锁、条件变量这些同步机制——它们到底有多“贵”，以及怎么用才划算。
10.1 pthread的创建与销毁：别小看这点开销
很多新手觉得，创建线程不就是调个pthread_create吗？能有多慢？我刚开始也这么想，直到有一次在嵌入式项目里，为了赶一个实时响应的deadline，我疯狂创建线程，结果系统直接卡死。
为什么会这样？因为线程创建的开销，比你想象的大得多。
| 操作 | 大致耗时（微秒） | 说明 |
|---|---|---|
| pthread_create | 10~100 | 分配栈空间、初始化TCB、调度 |
| pthread_join | 1~10 | 等待线程结束，回收资源 |
| pthread_detach | 0.5~2 | 分离线程，自动回收 |
你看，创建一次线程，少说也要几十微秒。如果你在循环里频繁创建销毁，那性能损耗是肉眼可见的。我个人的习惯是：能用线程池就别手动创建线程。线程池里的线程是复用的，省去了反复创建销毁的开销。
核心观点：线程创建是“重”操作，能复用就别重复造。
10.2 互斥锁：最常用的同步工具，但别滥用
互斥锁（mutex）是多线程编程的“门卫”。它保证同一时间只有一个线程能访问共享资源。但门卫多了，也会堵门。
互斥锁的性能开销，主要体现在两个地方：
- 加锁/解锁的指令开销：底层是原子操作，涉及内存屏障，大概几十纳秒。
- 锁竞争导致的上下文切换：这才是大头。当多个线程争同一把锁时，没抢到的线程会被挂起，等锁释放后再唤醒。一次上下文切换，动辄几微秒。
我曾经在一个网络服务器项目里，看到锁竞争导致CPU利用率飙升到90%，但吞吐量却上不去。后来用perf一分析，发现大量时间花在锁等待上。解决办法？把大锁拆成小锁，或者用读写锁替代互斥锁。
小技巧：如果临界区代码很短（比如就几行赋值），可以考虑用自旋锁（spinlock）代替互斥锁。自旋锁不会让线程休眠，而是原地“转圈”等待，避免了上下文切换的开销。但注意，自旋锁只适合短临界区，否则CPU空转更浪费。
10.3 条件变量：让线程学会“等通知”
条件变量（condition variable）通常和互斥锁配合使用。它的作用是：让一个线程等待某个条件成立，另一个线程在条件满足时通知它。
比如生产者-消费者模型：消费者发现队列为空，就调用pthread_cond_wait等待；生产者放入数据后，调用pthread_cond_signal唤醒消费者。
条件变量的性能开销，主要来自：
- pthread_cond_wait：释放锁、挂起线程、重新获取锁——三步走，每一步都有开销。
- pthread_cond_signal：唤醒一个等待线程，可能触发上下文切换。
- pthread_cond_broadcast：唤醒所有等待线程，开销更大，容易引发“惊群效应”。
注意：条件变量存在“虚假唤醒”的可能。也就是说，即使没有调用signal，wait也可能返回。所以，一定要在循环中检查条件，而不是用if。这是很多新手容易犯的错，我曾经也在这上面栽过跟头。
// 正确的用法：在循环中检查条件
pthread_mutex_lock(&mutex);
while (queue_is_empty()) {
pthread_cond_wait(&cond, &mutex);
}
// 处理数据...
pthread_mutex_unlock(&mutex);10.4 性能对比：到底谁更“贵”？
为了让你有个直观感受，我整理了一份性能对比表。数据来自我实际测试的一个嵌入式Linux平台（ARM Cortex-A72，2.0GHz）。
| 操作 | 平均耗时 | 备注 |
|---|---|---|
| pthread_mutex_lock（无竞争） | ~25 ns | 只是原子操作+内存屏障 |
| pthread_mutex_lock（有竞争） | ~5 μs | 包含上下文切换 |
| pthread_cond_wait | ~10 μs | 挂起+唤醒+重新加锁 |
| pthread_cond_signal | ~3 μs | 唤醒一个线程 |
| pthread_cond_broadcast | ~15 μs | 唤醒所有线程，惊群效应明显 |
你看，无竞争的锁操作只有25纳秒，但一旦有竞争，直接跳到5微秒——差了200倍！所以，减少锁竞争，是性能优化的关键。
10.5 避坑指南：我踩过的那些坑
- 锁的粒度太粗：我曾经把一个循环整个锁住，结果其他线程全在等。后来改成只锁关键操作，性能提升了好几倍。
- 忘记解锁：特别是函数中有多个return路径时，很容易漏掉pthread_mutex_unlock。我的习惯是：加锁后立即写解锁代码，再插入业务逻辑。
- 条件变量和互斥锁不匹配：wait前必须持有锁，signal时不一定需要锁。这个细节搞错了，程序就会死锁或崩溃。
- 过度使用broadcast：能用signal就别用broadcast。唤醒所有线程，大部分都是白忙活。
总结一下：多线程同步的性能开销，核心在于“竞争”和“上下文切换”。减少竞争、避免不必要的切换，你的程序就能跑得更顺。嗯，这些经验，都是我用线上故障换来的。
好了，关于pthread多线程同步的性能开销，就聊到这儿。记住一句话：同步机制是工具，不是目的。能用无锁设计，就别用锁；能用轻量级同步，就别用重量级的。 下次咱们聊聊更高级的同步原语——读写锁和屏障，看看它们又有什么门道。