信号量与线程池实战：Linux多线程同步与复用机制解析

1. 信号量：一个被很多新手误用的同步原语

1.1 从互斥锁到信号量：能计数就不只是锁

聊Linux线程，前面几篇我们一直在打交道的是pthread_mutex_t和pthread_cond_t。互斥锁解决的是"能不能进去"的问题，条件变量解决的是"什么时候能进去"的问题，但这两者都有一个共同的短板：它们的状态只有0和非0，没法表达"还剩几个资源"。信号量(sem_t)补上的正是这个缺口。

我之前第一次在项目里用信号量，是在做连接池的时候。一个连接池最多放8个连接，客户端来借连接，有就借走，没有就排队等着。如果用互斥锁硬写，你得自己维护一个计数变量，再加一个条件变量，每次借还都得小心翼翼地通知。信号量一行sem_wait就解决了——初始值设成8，每借走一个就减1，全借光了自然阻塞，还回来的时候sem_post加1再唤醒一个等待者。这就是信号量最朴素的用法：计数器 + 原子操作 + 阻塞唤醒。

但这里有个特别容易被误解的地方：信号量不是"更高级的互斥锁"。恰恰相反，信号量表达的是资源数量，不是访问权限。你完全可以用初始值为1的信号量当互斥锁用，但这样做既没有性能优势，又容易在逻辑上给自己挖坑——因为信号量是允许任何线程去sem_post的，甚至不是持锁方的线程也能post，这就破坏了互斥锁的"所有权"语义。信号量的正确打开方式是：线程间不关心谁加谁减，只关心资源余额。

1.2 sem_init / sem_wait / sem_post 的核心用法与语义

用信号量之前，先初始化：

c复制#include <semaphore.h>

sem_t sem;
int ret = sem_init(&sem, 0, 8);
// pshared = 0：线程间共享；非0：进程间共享
// value = 8：初始资源数

这里第一个要记住的点是pshared参数。标题讲的是线程，所以pshared固定填0。一旦你把它填成非0，内核会把这个信号量放到映射内存里，允许fork出来的子进程访问，那走的就是另一套进程间同步的玩法了。我见过有同事在写线程同步时手一抖填了1，结果行为变得极其诡异——父进程创建线程，子进程却也能碰到这个信号量，排查了半天才找到原因。

P操作（等待/获取资源）和V操作（释放/发出资源）对应两个函数：

c复制sem_wait(&sem);       // 阻塞式P，资源不足时挂起等待
sem_trywait(&sem);    // 非阻塞P，资源不足立即返回-1，errno=EAGAIN
sem_timedwait(&sem, &abs_timeout); // 限时P，超时返回-1，errno=ETIMEDOUT

sem_post(&sem);       // V操作，释放资源，并唤醒一个sem_wait阻塞者

sem_wait的返回值也必须检查。在Linux环境里，如果进程收到了信号（比如SIGINT），sem_wait会返回-1并把errno设成EINTR。很多人不检查返回值，结果线程悄无声息地退出，任务队列就卡死了。严谨的写法是：

c复制while (sem_wait(&sem) != 0) {
    if (errno != EINTR) {
        // 真正的错误，处理并退出
        break;
    }
    // EINTR的话，重新等待
}

1.3 信号量做生产者消费者时最容易踩的坑

生产消费模型我至少写过五六版，信号量版是看起来最优雅的，但坑也最多。网上常见的写法是双信号量：

c复制sem_t empty; // 初始 N，表示空闲槽位
sem_t full;  // 初始 0，表示已占用槽位
pthread_mutex_t mutex; // 保护队列本身

// 生产者
sem_wait(&empty);
pthread_mutex_lock(&mutex);
queue_push(...);
pthread_mutex_unlock(&mutex);
sem_post(&full);

// 消费者
sem_wait(&full);
pthread_mutex_lock(&mutex);
queue_pop(...);
pthread_mutex_unlock(&mutex);
sem_post(&empty);

这个模式本身是对的，但有两个细节必须注意。

第一个坑是初始值的含义。empty的初始值不能随便设，它必须等于队列容量的上限。如果你开了一个长度10的数组队列，empty初始值是5，那生产者在队列还没满的时候就开始阻塞，队列利用率只剩一半。反过来，empty初始值大于队列容量，就会出越界。我调试过最难受的一个bug就是队列本来只放了6个元素，empty初始值却是10，生产者又往里塞了4个，直接踩坏了相邻内存。

第二个坑是信号量和互斥锁的顺序。信号量的wait应该在外面，互斥锁的lock在里面。如果把顺序反过来——先加锁再等信号量，一旦信号量不足线程阻塞住了，那把锁就没人释放了，其他线程全部卡在lock上，直接死锁。这种错线上环境一压测就现原形，而且特别难查，因为时序不定，不是每次都能复现。

1.4 信号量的本质：内核计数器加等待队列

如果只是背API，信号量就算白学了。把它拆开看就清楚多了：sem_t底层其实是一个内核维护的整数计数器，外加一个等待队列。sem_wait做的事情是原子的"检查-减值-决定是否挂起"，sem_post是原子的"加值-检查等待队列中有没有人-有则唤醒一个"。

和std::atomic<int>自己实现自旋等待相比，信号量最大的优势是没有忙等。自旋锁在锁冲突激烈的时候CPU占用率会飙升到100%，而信号量让线程挂起后CPU完全释放出来，这是调度器层面的睡眠唤醒，不占用CPU。代价是线程被挂起和唤醒涉及内核态切换，性能比自旋稍差。所以实践中信号量适合等待时间不确定或者较长的场景，自旋锁适合临界区极短且锁冲突概率低的场景。

2. 线程池设计：先从懂"池化"原理开始

2.1 为什么不用来一个任务开一个线程

这是线程池最核心要回答的问题。做一个高频请求的服务器程序，如果不加控制，每来一个请求pthread_create一个线程，请求量一上来系统就撑不住了。线程不是免费的午餐：创建线程需要进内核分配线程描述符、建立栈空间（主线程栈之外的线程栈默认8MB虚拟内存），销毁线程还要回收资源。频繁创建销毁线程，开销很多时候比任务本身的处理时间还高。

更关键的是，操作系统能同时运行的线程数是有限的。一个8核的CPU，如果同时跑500个线程，每个线程分到的CPU时间片就非常少，大量时间都花在线程上下文切换上——保存寄存器、切换页表、刷新TLB，这些都是实打实的性能损耗。线程池的核心思路就是：控制并发上限，复用已创建的线程，不让线程无限膨胀。

用银行业务做类比更直观：如果不设柜台限流，所有客户都直接进来找一个柜员办业务，大厅就会挤爆。线程池相当于设置了一批固定柜员（工作线程），客户来了先在取号机排队（任务队列），柜员办完一个叫下一个号。这样无论来多少客户，大厅里同时办业务的永远是那么几个柜员。

2.2 线程池的基本组成与工作流程

线程池不管怎么扩展，核心组件就四块：

• 任务队列：存放待执行的函数对象/任务，通常是一个std::queue<std::function<void()>>。
• 工作线程集合：一堆线程从任务队列里取任务并执行。
• 同步协调机制：工作线程在队列为空时休眠，有新任务时被唤醒。这里用条件变量最自然，也可以用信号量当"任务到达"通知，用互斥锁保护队列。
• 生命周期管理：线程池需要提供关闭/停止接口，确保所有线程优雅退出，不会卡死或泄漏。

基本工作流程是：外部提交任务到队列 → 通知某个空闲的工作线程 → 工作线程从队列取任务执行 → 执行完继续取下一个，队列空了就阻塞等待。文字描述起来简单，但代码要写对不容易，尤其是关闭接口的设计。

关闭线程池我最开始写的是"直接设一个退出标志，然后唤醒所有线程"。结果线程正在执行任务就被强制吞噬了，任务队列里还剩一堆任务没跑。正确做法是分两步：先设置停止标志，然后让所有线程把手头的任务执行完，并且把队列里剩余的任务也执行完，最后再退出。实现上，工作线程的循环里要同时判断"停止标志"和"队列是否还有任务"：

cpp复制while (true) {
    std::function<void()> task;
    {
        std::unique_lock<std::mutex> lock(mutex);
        cv.wait(lock, [this] {
            return !queue.empty() || stop;
        });
        if (stop && queue.empty()) {
            return; // 队列清空且池已停止，才退出线程
        }
        task = std::move(queue.front());
        queue.pop();
    }
    task();
}

注意条件变量等待的谓词，是"队列非空 或 停止标志置位"才能被唤醒。退出条件是"停止标志为true 且 队列为空"。这两条缺一不可，否则会出现线程池停止后还有线程因队列空而阻塞，或者线程在停止后仍然继续处理任务的错误。

2.3 任务队列选型：条件变量阻塞队列还是无锁队列

任务队列是线程池的心脏。我工作的环境里，最常用的方案是互斥锁加条件变量加std::queue，代码量少、逻辑清晰、不容易出错。但如果你追求极致性能，或者队列的入队出队频率特别高，锁竞争会成为瓶颈。

无锁队列（比如boost::lockfree::queue）在多生产者多消费者场景下并不完美：实现复杂，内存管理要考虑ABA问题，而且实际性能未必比加锁队列好——在锁冲突不严重的情况下，加锁队列的开销其实是可接受的。我做过的压测里，单生产者单消费者场景下无锁队列有优势，但多生产者多消费者场景加锁队列反而更稳。

所以我的选型原则很简单：默认用条件变量阻塞队列，代码好维护；真正到了性能瓶颈，先用perf验证锁竞争问题，再升级无锁方案，不要一开始就炫技。

2.4 submit 和 execute：两个入口背后的设计取舍

这两个入口代表线程池对外暴露的两种接口风格，直接对应Java的ThreadPoolExecutor.execute()和submit()，C++线程池通常也借鉴这套设计。

• execute(callable)：只负责执行，不关心返回值。入参是一个std::function<void()>或者任意无返回值的可调用对象，丢进队列就完了。
• submit(callable)：需要拿到执行结果。内部会先把可调用对象包装进std::packaged_task，然后返回一个std::future。调用方可以future.get()拿到返回值，或者捕获任务执行过程中抛出的异常。

submit的实现核心在于对调用对象的包装，我第一次写的时候没处理好类型推导，编译报了一堆模板错误。一个简洁的例子是：

cpp复制template<typename F>
auto submit(F&& f) -> std::future<decltype(f())>
{
    using RetType = decltype(f());
    auto task = std::make_shared<std::packaged_task<RetType()>>(
        std::forward<F>(f)
    );
    std::future<RetType> result = task->get_future();
    execute([task]() { (*task)(); });
    return result;
}

这里有一个坑：如果直接传std::bind或lambda引用捕获了外部对象，外部对象生命周期得确保在线程执行完之前还有效，否则就是悬空引用。一般建议用值捕获或者std::shared_ptr来传状态，千万不要裸指针。

3. 线程池的七个参数与动态调优思路

3.1 七个参数的逐一拆解

面试题里经常问"线程池的七个参数"，在Java的ThreadPoolExecutor里是corePoolSize、maximumPoolSize、keepAliveTime、timeUnit、workQueue、threadFactory、handler。C++写线程池虽然没有标准库自带实现，但设计参数同样可以按这个维度来。

我把它们翻译成C++线程池的设计维度：

3.2 线程数设置：从理论公式到实际压测

"CPU密集型的线程数设成N+1，IO密集型的设成2N"——这个经验公式大家应该都听过。N就是CPU核数。为什么CPU密集型是N+1？因为线程偶尔会有页错误、调度停顿或其他原因，多一个线程能弥补这个短暂的空白期，又不至于造成明显上下文切换。为什么IO密集是2N？因为线程大部分时间阻塞在IO等待上，CPU空闲，多开线程能提升吞吐。

但公式只能是起点。我实际调参从来都是先按公式估算，再用压测工具（比如ab、wrk或自己写多线程压测客户端）去压，观察几个关键指标：CPU使用率、线程阻塞率、任务队列积压长度、RT（响应时间）分位数。调优的目标不是"线程数越大越好"，而是在CPU利用率、队列延迟、响应速度之间找到平衡。

有一个很实用的参考思路：如果压测时CPU使用率还没上去，但RT已经很高，说明线程数太多，大量时间花在了上下文切换上，应该减少线程数。反过来，如果CPU使用率已经接近100%，但队列还在积压任务，说明线程数不够，或者任务本身有瓶颈。

3.3 拒绝策略与饱和处理

当任务队列满了，线程数也已经到最大上限，新的任务该怎么处理？Java默认抛RejectedExecutionException，但这往往不是生产系统想要的——直接抛异常会导致瞬时大量请求失败。更务实的策略有几种：

• 调用者执行（CallerRunsPolicy）：新任务不丢进队列，直接让提交任务的线程自己执行。这样既不会丢任务，又提供了一种天然的背压——提交任务的线程被任务执行拖慢，从而放慢提交速度。
• 丢弃最旧任务（DiscardOldestPolicy）：丢弃队列头部的任务，把新任务放进去。适合任务时效性很强的场景，旧任务的价值低于新任务。
• 丢弃当前任务（DiscardPolicy）：静默丢弃新任务。适合允许少量丢数据的场景，比如实时日志采样。

C++里没有官方实现，需要自己动手。我项目里用的策略是"调用者执行 + 兜底告警"，保证数据不丢，同时把饱和情况记录下来，之后根据告警频率决定是否扩容线程池。

3.4 动态扩容与回收，怎么做到不剧痛

固定大小的线程池实现简单，但业务负载往往是波动的。流量高峰时需要更多线程，低谷时只要少数线程就够。动态扩容回收的思路是：在任务提交时观察队列积压情况，如果队列长度超过阈值，并且当前线程数没达到最大值，就新建一个线程去消费队列；如果线程空闲超过了存活时间，就让它退出。

这个逻辑用一句话描述很轻松，写起来就有不少边界问题。比如，扩容的触发条件不能只看一次，要用连续几次提交都超过阈值才算，避免流量瞬时抖动导致线程数反复震荡。回收的时候，不能让工作线程自己刚处理完一个任务就退出，至少要保证队列已经空了再退出，否则就可能出现"队列还剩任务，线程却退了，线程池死等"的尴尬。

我见过一个比较取巧的做法：工作线程在循环里每次都检查一下当前线程池的活跃线程数和队列长度，如果发现线程数量大于核心线程数，且队列空了一段时间，就主动把自己从线程池移除并退出。这相当于让线程自己"失业下岗"，虽然简单粗暴，只要加上足够的日志和监控，实际效果反而很稳定。

4. 封装线程类：从裸std::thread到可维护的Thread

4.1 std::thread为什么值得再包一层

现代C++写线程，首选肯定是std::thread，它把pthread_create的C风格API包装成了面向对象的接口。但直接用std::thread，有几个让人很难受的地方。

一是生命周期不清不楚。std::thread对象析构时，如果它还是个joinable的状态，程序会直接std::terminate。这导致你在写异常安全的代码时非常麻烦——函数中途抛异常，局部std::thread析构就把进程干掉了。二是没有线程名。排查线上问题时，用ps -eLf看到一堆线程都叫thread，根本分不清哪个线程是干嘛的。三是返回值和异常处理不方便。线程回调里抛出的异常，如果你没在回调内部catch住，会直接调用std::terminate。

所以我封装线程类的核心目的有三个：管理生命周期、给线程命名、提供统一的异常入口。

4.2 Thread类设计：回调、命名、生命周期管理

一个最基本的封装，我给团队定的版本是：

cpp复制class Thread {
public:
    using Callback = std::function<void()>;

    Thread(Callback cb, const std::string& name = "")
        : cb_(std::move(cb)), name_(name) {}

    void start() {
        thread_ = std::thread([this] {
            if (!name_.empty()) {
                pthread_setname_np(pthread_self(), name_.substr(0, 15).c_str());
            }
            cb_();
        });
    }

    void join() {
        if (thread_.joinable()) {
            thread_.join();
        }
    }

    void detach() {
        if (thread_.joinable()) {
            thread_.detach();
        }
    }

    ~Thread() {
        // 这里必须做出选择：join or detach
        if (thread_.joinable()) {
            std::terminate(); // 或 log + detach，二选一
        }
    }

private:
    Callback cb_;
    std::string name_;
    std::thread thread_;
};

这个版本里最重要的设计决策在析构函数。我把它设成std::terminate()就是为了强制使用者在析构前显式调用join或detach，把生命周期管理暴露出来，避免"我以为析构会等我，其实直接炸了"的隐性bug。有些团队会选择析构时自动detach，但detach后线程可能会访问已经析构的Thread对象成员，这比提前terminate更隐蔽、更难排查。两害相权，我宁可它炸在测试环境，也不要线上悄悄内存错误。

4.3 封装线程时最隐蔽的this指针陷阱

上面的start()实现里有个大坑：thread_ = std::thread([this] { ... cb_(); });。这个lambda捕获了this指针。如果Thread对象先被析构了，而线程还在运行，lambda再去访问name_和cb_就是访问悬空指针，行为未定义。

我踩过的真实案例是：在一个类里持有Thread成员，类析构时先析构成员（包括Thread），但线程执行体还在跑，结果线程里访问到了已经释放的虚函数表指针，程序直接段错误。排查手段只能靠gdb+pstack看core文件，特别费劲。

解决办法要么是禁止拷贝、只允许在堆上管理（std::shared_ptr<Thread>），要么在线程回调里用weak_ptr或"自持有"机制。更简单的思路是：确保先join线程，再析构对象。比如在持有方类的析构函数里，先调用thread_.join()，让线程执行完毕，再让Thread成员析构。这个顺序写对了，this陷阱就掐死在源头。

4.4 可变参数模板与完美转发：把接口做漂亮

线程封装如果只能接受无参回调，用起来还是不够爽。更通用的封装是接受任意签名，像std::thread那样支持多参数：

cpp复制template<typename Func, typename... Args>
void start(Func&& f, Args&&... args) {
    thread_ = std::thread(
        [this](Func&& f, Args&&... args) {
            cb_ = std::bind(std::forward<Func>(f), std::forward<Args>(args)...);
            cb_();
        },
        std::forward<Func>(f), std::forward<Args>(args)...
    );
}

这里必须用std::forward做完美转发，否则参数的左值右值特性会丢失。比如你传入一个std::unique_ptr，如果不转发，编译就会报错，因为unique_ptr只能移动不能拷贝。另外要注意std::bind把参数都拷贝了一份，std::reference_wrapper可以用std::ref显式包装，避免大对象被拷贝。

封装完线程类之后，线程池里的工作线程就可以直接用它了，命名、启动、回收都变得统一规范。

5. 一套能直接跑的信号量+线程池综合示例

5.1 整体设计逻辑

如果把信号量和线程池放在一起做一个综合项目，我脑海里浮现的经典场景是：一个任务提交系统，使用信号量做任务队列的容量控制，使用线程池消费任务。生产者和消费者之间用信号量传递"队列还有几个空闲槽位"和"队列里有多少个待处理任务"，线程池里的工作线程只负责从队列取任务执行，不关心任务从哪来。

这样设计有一个好处：信号量天然适合表达"队列槽位数"这类资源概念，而线程池解决的是并发度和线程复用问题，两者各司其职。我不会用信号量去实现线程池的整个唤醒机制——那个用条件变量更清晰，但信号量作为容量上限控制，比mutex + condvar + 手动计数简洁得多。

5.2 关键代码与说明

我来写一个精简但完整的版本。先定义基于信号量的有界任务队列：

cpp复制#include <queue>
#include <mutex>
#include <semaphore.h>
#include <functional>

class SemaphoreQueue {
public:
    explicit SemaphoreQueue(size_t capacity)
        : capacity_(capacity) {
        sem_init(&empty_, 0, capacity);
        sem_init(&full_, 0, 0);
    }

    ~SemaphoreQueue() {
        sem_destroy(&empty_);
        sem_destroy(&full_);
    }

    void push(std::function<void()> task) {
        sem_wait(&empty_);
        {
            std::lock_guard<std::mutex> lock(mutex_);
            queue_.push(std::move(task));
        }
        sem_post(&full_);
    }

    std::function<void()> pop() {
        sem_wait(&full_);
        std::function<void()> task;
        {
            std::lock_guard<std::mutex> lock(mutex_);
            if (queue_.empty()) {
                // 理论上不会走到这里，因为full_ > 0才被唤醒
                sem_post(&full_);
                return nullptr;
            }
            task = std::move(queue_.front());
            queue_.pop();
        }
        sem_post(&empty_);
        return task;
    }

private:
    size_t capacity_;
    sem_t empty_;
    sem_t full_;
    std::mutex mutex_;
    std::queue<std::function<void()>> queue_;
};

注意pop()里那个if (queue_.empty())的判断，是为了防止某些极端情况下信号量计数和队列长度不一致。虽然正常流程不会出现，但防御性检查值得保留。

线程池部分直接复用前面讨论过的设计：execute提交任务到有界队列，工作线程循环pop执行。我使用信号量的容量控制之后，execute在队列满时会自动阻塞等待，这就是天然背压，不需要额外的拒绝策略。

5.3 验证与压测观摩

简单写个测试程序，提交10000个任务，每个任务打印当前线程ID和任务序号：

cpp复制ThreadPool pool(4, 100); // 4个工作线程，队列容量100

for (int i = 0; i < 10000; ++i) {
    pool.execute([i] {
        std::cout << "task " << i << " run in thread "
                  << std::this_thread::get_id() << std::endl;
    });
}
pool.wait(); // 等待所有任务执行完毕

跑起来会看到线程ID只有4个，但任务的顺序是乱序的——因为4个线程同时从队列里取任务。这个例子验证了线程复用和任务消费的正确性。如果队列容量小于任务总数，execute会阻塞，生产者不会无限制地往内存里塞任务，这就是有界队列的意义。

5.4 实测中的性能与安全加固

实际压测中我发现，信号量队列的吞吐量比mutex + condvar版本略低一点点。原因是sem_wait和sem_post各是一次系统调用，而pthread_cond_wait内部在有竞争时也会进入内核，但无竞争时（队列非空）条件变量检查可以作为快速路径，不用进内核。所以如果你的工作线程几乎总是能立刻拿到任务，条件变量版本更快；如果任务经常要等待，信号量版本语义更清晰、代码更直观。性能差距在几十纳秒级别，一般业务系统根本感知不到。

安全加固方面，一定要记得sem_destroy。还有一个容易被忽略的点：pthread_setname_np设置的线程名长度限制是16字节（含结尾的\0），超过15个字符会被截断。我早期给线程起名"worker-io-service-pool-1"这种长名字，被截断成了"worker-io-servi"，排查日志时差点没认出来。后来统一用了短名字加编号，比如"wk-01"、"wk-02"。

6. 我在生产环境中排查线程问题常用的几条经验

线程这个东西，写起来一时爽，线上出故障排查起来火葬场。我总结了几个最实用的排查手法。

第一，看线程数别只看top。 top里看到的线程数是瞬时值，最好用top -H -p <pid>看每个线程的CPU占用，或者用ps -eLf | grep <进程名>看到线程列表、PID、TID。加了pthread_setname_np之后，这里会直接显示线程名，一眼就能看出哪个线程在忙、哪个线程在睡、哪个线程卡死了。没有线程名的话，只能靠gdb attach进去一个个打印，效率极低。

第二，死锁排查用gdb三板斧。 步骤是：gdb attach <pid> → thread apply all bt → 看到所有线程的调用栈。如果发现某个线程卡在__lll_lock_wait或者sem_wait上，再看它等待的锁/信号量地址，去找谁持有这个资源。这个流程做熟练了，死锁定位基本在五分钟以内。我踩过的很多死锁都是"两个线程分别持有对方请求的锁"，就是经典的AB-BA问题，平时写代码一定要保持加锁顺序一致。

第三，线程池不是越大越好，一定要配监控。 我上线线程池后必做的一件事就是在线程池里埋点：当前活跃线程数、队列积压长度、拒绝次数、平均任务执行时间、最大任务执行时间。这些指标打到监控系统CMDB里，设置告警阈值。队列积压超过1000告警、活跃线程数长时间等于最大线程数告警，这样系统还没彻底卡死之前就能提前介入。

第四，线程栈大小要心里有数。 Linux下pthread_create可以设置线程栈大小，默认8MB。如果一个进程创建了500个线程，光栈虚拟内存就占了4GB，虽然虚拟内存不占物理内存，但在32位环境下地址空间会先耗尽。遇到内存问题，先检查是不是线程栈太大造成的。递归过深或者局部变量超大数组，也会让线程栈溢出，表现为段错误，gdb里经常看到栈已经踩到了一个奇怪的地址。

第五，能值捕获就别引用捕获。 在线程回调里使用外部变量，优先用值捕获或者std::shared_ptr管理生命周期。引用捕获的变量在线程执行时可能已经被析构，这种隐性问题在压力测试时才会随机爆发，而且极难复现。我们团队后来干脆在代码规范里规定：线程回调一律不允许裸引用捕获局部变量，即使性能损失一点，也要保证安全。

写完这篇，信号量、线程池、线程封装这三块就凑成了一个比较完整的Linux线程工具箱。日常项目里，信号量控制资源上限，线程池管理并发，线程封装统一生命周期管理，三者在同一个系统代码里配合使用，几乎能应对我遇到过的所有多线程需求。如果只是背API，遇到真实场景还是会手忙脚乱；多写几个综合示例，多把项目跑起来压一压，那些API之间的配合关系自然就清楚了。后面如果大家对"无锁队列实现线程池"或者"协程和线程池的混合调度"感兴趣，我再单独开一篇细讲。