第20章多线程网络编程

课程目录第20章多线程网络编程

第20章：多线程网络编程：多线程Web服务器设计、线程安全的socket操作、连接池的设计、事件驱动与多线程的结合

网络编程这块，说实话，是很多C语言开发者从「单机选手」迈向「系统架构师」的一道坎。我记得刚入行那会儿，写个单线程的echo服务器就觉得挺牛了，直到线上流量一上来，连接直接卡死，我才意识到——多线程网络编程，不是「开几个线程」那么简单。

这一章，我会把多线程Web服务器的设计思路、线程安全的socket操作、连接池的玩法，以及事件驱动怎么跟多线程结合，掰开了讲清楚。嗯，都是我在实际项目中踩过的坑和总结的经验。

20.1 多线程Web服务器的设计思路

一个多线程Web服务器，说白了就是「主线程负责接客，工作线程负责干活」。但怎么接、怎么分、怎么干，这里头门道不少。

我个人习惯把架构分成三种模型：

一连接一线程（Thread-per-Connection）：来一个连接，就创建一个线程。简单粗暴，但连接多了线程数暴涨，上下文切换能把CPU拖死。
线程池模型（Thread Pool）：预先创建一批线程，连接来了扔到任务队列里，线程池里的线程去抢着干。这是最常用的方案。
Reactor + 线程池：事件驱动处理IO，业务逻辑交给线程池。这是高性能服务器的标配。

我在项目中遇到过一个问题：用「一连接一线程」模型写了个内部工具，上线后连接数一上2000，服务器直接OOM。后来改成线程池，问题就解决了。你想想看，线程不是越多越好，线程的创建和销毁是有代价的。

核心原则：IO密集型任务可以多开线程，CPU密集型任务线程数不要超过核心数。Web服务器通常是IO密集型，但也要控制线程池大小，避免资源耗尽。

20.2 线程安全的socket操作

多线程环境下操作socket，最怕什么？数据错乱、资源竞争、死锁。我见过最典型的坑是：两个线程同时往同一个socket写数据，结果客户端收到的是「你好世界」和「再见世界」的字节交错——变成了「你再见好世界世界」。

为什么会这样？因为send()和recv()本身不是原子操作。多线程共享同一个socket描述符时，必须加锁。

我的做法是：

每个socket配一个读写锁（pthread_rwlock_t），读多写少时性能更好。
或者用互斥锁（pthread_mutex_t）保护整个socket操作，简单但并发度低。
更高级的做法：每个连接分配独立的发送缓冲区和接收缓冲区，线程只操作缓冲区，由专门的IO线程负责真正的收发。

// 线程安全的socket写操作示例
void safe_send(int sockfd, const char *data, size_t len) {
    pthread_mutex_lock(&sock_mutex[sockfd]);
    ssize_t sent = send(sockfd, data, len, 0);
    if (sent < 0) {
        // 错误处理
        perror("send failed");
    }
    pthread_mutex_unlock(&sock_mutex[sockfd]);
}

注意：千万不要在信号处理函数里调用socket操作，也不要在锁内做阻塞IO。我曾经在锁里调了recv()，结果对方不发了，整个线程池全部卡死——这就是典型的死锁场景。

20.3 连接池的设计

连接池这东西，说白了就是「复用」。每次请求都创建新连接，开销太大了。TCP的三次握手、TLS握手，都是成本。连接池的核心思想是：提前创建一批连接，用完了放回去，下次接着用。

我设计连接池时，一般考虑这几个要素：

要素	说明
最大连接数	防止资源耗尽，一般设为CPU核心数的2~4倍
最小空闲连接	保证有连接可用，避免突发请求时临时创建
连接超时	空闲连接超过一定时间就关闭，释放资源
健康检查	定期ping一下，确保连接没断开

连接池的线程安全是个大问题。我习惯用「双锁检测」模式：先检查空闲列表有没有连接，没有的话再加锁创建。这样可以减少锁竞争。

// 连接池获取连接（伪代码）
Connection *get_connection(ConnectionPool *pool) {
    if (pool->idle_count > 0) {
        pthread_mutex_lock(&pool->lock);
        if (pool->idle_count > 0) {
            return pop_idle(pool);
        }
        pthread_mutex_unlock(&pool->lock);
    }
    // 没有空闲连接，创建新连接
    return create_new_connection(pool);
}

小技巧：连接池不要只用一个全局锁。可以分多个桶（shard），每个桶有自己的锁，这样并发度更高。我在一个高并发网关项目里就是这么干的，性能提升了30%以上。

20.4 事件驱动与多线程的结合

事件驱动（比如epoll、kqueue）处理IO事件非常高效，但事件回调里如果做耗时操作，就会阻塞事件循环。所以，业界通用的做法是：事件循环只做IO，业务逻辑扔给线程池。

我常用的架构是这样的：

一个主线程跑epoll事件循环，负责监听新连接和读写事件。
事件到来时，把任务封装成一个结构体，扔到线程池的任务队列里。
工作线程从队列里取任务，处理完后把结果写回缓冲区，再通知事件循环去发送。

这种模式的好处是：事件循环不会被阻塞，能处理海量连接；线程池又能充分利用多核CPU。

我曾经在一个项目中，把事件循环和业务处理混在一起，结果一个慢查询把整个服务器拖慢了。后来改成事件驱动+线程池，吞吐量直接翻倍。嗯，这个坑我印象很深。

// 事件驱动+线程池的简化流程
void on_readable(int fd) {
    // 读取数据
    char buf[4096];
    int n = read(fd, buf, sizeof(buf));
    if (n <= 0) return;
    
    // 封装任务，扔到线程池
    Task *task = malloc(sizeof(Task));
    task->fd = fd;
    task->data = strdup(buf);
    thread_pool_add_task(g_pool, task);
}

void worker_thread_func(void *arg) {
    Task *task = (Task *)arg;
    // 处理业务逻辑（比如HTTP请求解析、路由分发）
    process_request(task->fd, task->data);
    free(task->data);
    free(task);
}

关键点：事件循环和线程池之间的数据传递，必须用线程安全的队列。我推荐用无锁队列（lock-free queue）或者用条件变量+互斥锁的阻塞队列。千万别用全局变量裸传，那会出大问题。

20.5 本章知识体系总览

下面这张图，是我梳理的多线程网络编程的核心知识结构。你可以把它当作一张地图，遇到问题时回来看看，思路会清晰很多。

多线程网络编程，说白了就是「怎么让多个线程安全、高效地处理网络IO」。没有银弹，每种方案都有适用场景。我个人建议：先从线程池+互斥锁做起，跑通了再优化。别一上来就搞无锁队列、io_uring，容易把自己绕进去。

好了，这一章的内容就到这里。记住：写多线程网络代码，心里要时刻绷着一根弦——「这个资源会不会被别的线程动？」。多问自己几遍，bug就能少一半。

公众号：蓝海资料掘金营，微信deep3321

📚 课程目录