清浅池塘做网络服务开发的人，多半都经历过这样一个阶段：先照着书上例子写一个socket服务端，accept一个连接就处理一个请求，跑通了之后沾沾自喜。等真正需要同时服务几十上百个客户端时，才发现程序卡得跟PPT一样，前面一个请求处理慢了，后面所有客户端都得排队等着。于是你开始思考多线程，开始搜索Linux多线程网络服务器开发的相关资料，然后被各种概念淹没——线程安全、锁竞争、线程池、IO模型、惊群效应……这篇内容不打算做那种面面俱到的教科书式铺陈，而是从我自己实际调试、压测、推翻重写的真实过程出发，把Linux下多线程网络服务器从最基础的阻塞模型一路解剖到线程池、再到多线程与epoll的配合方式，顺带把那些字符设备文件、现场排查中容易被忽略但往往会坑你一把的细节一并交代清楚。无论你是刚写完第一个C/S模型的在校生，还是在嵌入式Linux项目里被并发问题折磨的开发者，这篇内容都按着"先跑通、再优化、最后想明白为什么"的顺序来组织，读完至少能少走几次弯路。
1. 从单线程阻塞模型说起：为什么"可以跑"不等于"能用"
很多教材演示TCP服务器时都长一个样：socket()创建套接字，bind()绑定地址，listen()监听，然后一个while(1)循环里不断accept()。能跑，但仅限于演示级的"能跑"。这种模型技术上有它存在的意义，但你如果把它直接搬到业务场景里，第一个遇到的就是阻塞问题。
1.1 阻塞点到底卡在哪里
我们用一段非常典型的代码看这个问题。这里故意保留最朴素的写法，方便对照你手头可能已有的代码：
c复制#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#define PORT 8888
#define BUFFER_SIZE 1024
int main() {
int server_fd = socket(AF_INET, SOCK_STREAM, 0);
if (server_fd < 0) {
perror("socket");
return 1;
}
int opt = 1;
setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
struct sockaddr_in addr;
memset(&addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_port = htons(PORT);
addr.sin_addr.s_addr = INADDR_ANY;
if (bind(server_fd, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
perror("bind");
return 1;
}
if (listen(server_fd, 5) < 0) {
perror("listen");
return 1;
}
printf("server listening on port %d\n", PORT);
while (1) {
struct sockaddr_in client_addr;
socklen_t client_len = sizeof(client_addr);
int client_fd = accept(server_fd, (struct sockaddr*)&client_addr, &client_len);
if (client_fd < 0) {
perror("accept");
continue;
}
char buffer[BUFFER_SIZE] = {0};
int bytes = read(client_fd, buffer, sizeof(buffer) - 1);
if (bytes > 0) {
printf("received: %s\n", buffer);
const char* response = "hello from server";
write(client_fd, response, strlen(response));
}
close(client_fd);
}
close(server_fd);
return 0;
}
这段代码的问题非常明显：accept()会阻塞，read()会阻塞。当第一个客户端连上来之后，如果它迟迟不发数据，服务端的read()就一直挂着，后续所有连接都在accept()那里排队。我实际测试过，用浏览器开两个标签页同时访问，第二个请求能等到超时。更糟心的是，如果某个客户端发来一个执行很慢的请求——比如查询一个超大数据库——那这段时间内整个服务器对外是零响应状态。
1.2 什么样的场景还可以勉强救一下
不是说阻塞模型一无是处。在内部工具、调试服务、设备管理这类并发量极低、请求处理极快、客户端数量基本恒定的场景下，单线程阻塞模型其实是最稳的：没有锁竞争、没有上下文切换开销、代码逻辑从头到尾一条直线，出问题也最容易定位。我见过有些嵌入式设备上的管理端口，就是靠这种模型活了十几年没动过。
但一旦进入下面这些情况，就得立刻换思路：
- 客户端数量动态变化，高峰期可能同时几十上百个
- 单个请求处理时间不稳定，甚至可能秒级
- 需要支持长连接，而不是"连上来发一条就断"
- 服务器需要同时主动推送数据给多个客户端
这些需求有一个共同特征：服务器的瓶颈不再是单个连接的处理逻辑，而是"如何同时伺候好一堆连接"。这时候多线程几乎是Linux平台上最自然的选择——每个连接一个线程，连接之间天然隔离，代码逻辑基本可以沿用单线程那套，加锁的地方少之又少。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 多线程改造：从pthread到临界区的实战要点
Linux原生的线程接口就是POSIX线程，也就是pthread。它不给线程贴花花绿绿的壳，直接给你全套底层操作能力。对写网络服务的开发者来说，需要掌握的核心操作其实就那么几个：创建线程、等待线程、给线程传参数、保护共享数据。
2.1 用pthread实现"一连接一线程"的骨架
我们先延续上面的例子，把每次accept()到的客户端连接交给一个独立线程处理。改造后的核心逻辑是：
c复制#include <pthread.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#define PORT 8888
#define BUFFER_SIZE 1024
void* handle_client(void* arg) {
int client_fd = *(int*)arg;
free(arg); // 释放主线程malloc的内存
char buffer[BUFFER_SIZE] = {0};
int bytes = read(client_fd, buffer, sizeof(buffer) - 1);
if (bytes > 0) {
printf("thread [%lu] received: %s\n", pthread_self(), buffer);
const char* response = "hello from thread server";
write(client_fd, response, strlen(response));
}
close(client_fd);
return NULL;
}
int main() {
int server_fd = socket(AF_INET, SOCK_STREAM, 0);
if (server_fd < 0) {
perror("socket");
return 1;
}
int opt = 1;
setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
struct sockaddr_in addr;
memset(&addr, 0, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_port = htons(PORT);
addr.sin_addr.s_addr = INADDR_ANY;
if (bind(server_fd, (struct sockaddr*)&addr, sizeof(addr)) < 0) {
perror("bind");
return 1;
}
if (listen(server_fd, 10) < 0) {
perror("listen");
return 1;
}
printf("multi-thread server listening on port %d\n", PORT);
while (1) {
struct sockaddr_in client_addr;
socklen_t client_len = sizeof(client_addr);
int client_fd = accept(server_fd, (struct sockaddr*)&client_addr, &client_len);
if (client_fd < 0) {
perror("accept");
continue;
}
// 注意：这里不能直接传client_fd的地址，因为下一次循环会改变它的值
int* pfd = malloc(sizeof(int));
*pfd = client_fd;
pthread_t tid;
if (pthread_create(&tid, NULL, handle_client, pfd) != 0) {
perror("pthread_create");
close(client_fd);
free(pfd);
}
// 注意：这里没有pthread_join，让线程自己跑完自己退出
pthread_detach(tid);
}
close(server_fd);
return 0;
}
这里有一个新手特别容易踩的坑：直接在pthread_create里传&client_fd。看起来没问题，但主线程的client_fd变量在一次循环结束后就会被下一次accept()覆盖，如果子线程还没来得及执行read()，拿到的就是一个损坏的甚至完全无效的文件描述符。我在早期的代码里就吃过这个亏，当时的症状非常随机——有时连接正常，有时连接直接被read()返回-1，程序还不报错，非常令人恼火。正确做法是像上面一样，每次循环用malloc分配独立的整数，把值拷贝进去再传给子线程，子线程用完之后自己free。
2.2 线程安全不止是"加锁"这么简单
一连接一线程的模型确实解决了并发接入的问题，但随之而来的是一类更隐蔽的问题：多个线程同时访问共享数据。典型的共享数据包括日志文件描述符、统计计数器、配置信息、任务队列等。
很多初学者对线程安全的理解就是"多线程访问共享变量需要加锁"，但关键是要搞清楚哪些操作需要锁。我们用一个最普通的例子：多个线程同时调用printf打印日志。你可能会觉得printf是库函数，内部应该已经处理好了。实际上printf内部确实有锁（stdio的锁），它能保证一行输出不被拆碎，但它不能保证多个线程的日志顺序符合你的预期。这种程度的问题还不算严重，真正严重的是下面这种：
c复制int count = 0;
void* worker(void* arg) {
for (int i = 0; i < 100000; i++) {
count++; // 看似一行代码，实际是三条指令：读、加、写
}
return NULL;
}
两个线程同时对count执行自增，理论上count最后应该是200000。但由于"读-加-写"这三个步骤不是原子操作，存在典型的竞态条件，最终结果往往小于200000。我在给学生演示时跑过这个例子，结果从180000到199000不等，每次都不一样。这个案例也常用于多线程面试题，面试官问的往往不是"要不要加锁"，而是"为什么加了锁的程序还是慢"以及"哪些操作其实不需要加锁"。
保护共享数据的基本工具有互斥锁（pthread_mutex_t）、读写锁（pthread_rwlock_t）、自旋锁（pthread_spinlock_t）、原子操作（__atomic_*或C11的stdatomic.h）。实际选型经验是：
- 临界区代码很短、冲突概率极高、等待时间极短，考虑自旋锁或原子操作
- 读远多于写，用读写锁
- 临界区可能阻塞（比如里面做了IO），必须用互斥锁
- 能不用锁就尽量不用锁，比如利用线程局部存储（
__thread）把每个线程的统计计数分开，最后汇总时再加锁
2.3 别忘了一件事：线程异常退出和资源回收
在"一连接一线程"模式下，每个线程处理完客户端连接后自行退出。正常路径上，close(client_fd)会释放文件描述符，线程函数返回后pthread_detach会回收线程资源。但实际运行中经常出现几个隐患：
- 客户端连接被异常中断时，
read()返回0或-1，代码正确处理了还好，没处理就会导致线程卡在read()上很久，甚至永久挂起 - 如果线程里还分配了堆内存、打开文件、申请锁，任何一个环节发生提前返回，都可能造成资源泄漏
- 线程数量失控。一连接一线程在连接数几十时还扛得住，一旦客户端频繁重连，服务器可能会同时开出数百个线程，线程切换开销和内存占用会直接拖垮系统
正因为这些隐患，业界才不会把"一连接一线程"当作高并发服务的终极方案。它更像是一个过渡方案，让你跑通多线程的基本流程。真正能支撑高并发的，是后面要讲的线程池模型。
3. 线程池：解决"来一个请求起一个线程"的隐患
线程池的思想再朴素不过：预先创建一批线程放在池子里，来任务了，从池子里取一个线程去执行；任务执行完，线程不销毁，而是回到池子里等待下一个任务。它避免了两类开销——线程创建/销毁的系统调用开销，以及线程数量失控导致的调度开销。
3.1 线程池的两个核心组件：任务队列和条件变量
在Linux下实现一个最简线程池，核心需要一个任务队列和一个条件变量。条件变量用于通知休眠中的工作线程"有新任务来了"。
任务队列的每个节点通常包含一个函数指针和一个void*参数。定义大概是这样的：
c复制typedef struct task {
void (*function)(void*);
void* arg;
struct task* next;
} task_t;
typedef struct threadpool {
pthread_mutex_t lock;
pthread_cond_t notify;
pthread_t* threads;
task_t* queue_head;
task_t* queue_tail;
int thread_count;
int queue_size;
int shutdown;
} threadpool_t;
工作线程的主循环是每个线程池最核心的部分，它做的事情只有三件：加锁、检查任务队列、等待条件变量。大致逻辑：
c复制void* worker(void* arg) {
threadpool_t* pool = (threadpool_t*)arg;
while (1) {
pthread_mutex_lock(&pool->lock);
// 当任务队列为空且未收到关闭信号时，等待条件变量
while (pool->queue_head == NULL && !pool->shutdown) {
pthread_cond_wait(&pool->notify, &pool->lock);
}
if (pool->shutdown && pool->queue_head == NULL) {
pthread_mutex_unlock(&pool->lock);
pthread_exit(NULL);
}
task_t* task = pool->queue_head;
pool->queue_head = task->next;
if (pool->queue_tail == task) {
pool->queue_tail = NULL;
}
pool->queue_size--;
pthread_mutex_unlock(&pool->lock);
task->function(task->arg);
free(task);
}
return NULL;
}
这里有一个许多初学者容易写错的点：为什么pthread_cond_wait要用while循环而不是if？如果只用if，那么线程被唤醒后不会再次检查任务队列是否真的非空，可能会拿到一个空指针或者重复处理同一个任务。原因在于条件变量存在虚假唤醒（spurious wakeup），而且可能存在多个线程同时被唤醒的情况。while循环保证了唤醒后重新检查条件是否满足，这是规范写法，也是多线程面试题里常问的一个细节。
3.2 提交任务时的生产者-消费者逻辑
主线程往线程池里提交任务时，要做的就是加锁、把任务挂到队列尾部、发信号通知一个等待的工作线程。大概长这样：
c复制int threadpool_add(threadpool_t* pool, void (*function)(void*), void* arg) {
if (pool == NULL || function == NULL) return -1;
task_t* task = (task_t*)malloc(sizeof(task_t));
if (task == NULL) return -1;
task->function = function;
task->arg = arg;
task->next = NULL;
pthread_mutex_lock(&pool->lock);
if (pool->shutdown) {
pthread_mutex_unlock(&pool->lock);
free(task);
return -1;
}
if (pool->queue_tail == NULL) {
pool->queue_head = task;
pool->queue_tail = task;
} else {
pool->queue_tail->next = task;
pool->queue_tail = task;
}
pool->queue_size++;
// 只唤醒一个线程，避免惊群
pthread_cond_signal(&pool->notify);
pthread_mutex_unlock(&pool->lock);
return 0;
}
注意这里用的是pthread_cond_signal而不是pthread_cond_broadcast。signal只唤醒一个线程，如果任务队列里只有一个任务，唤醒一个线程就够了。用broadcast会把所有线程都叫醒，然后让它们抢锁，但最终只会有一个线程拿到任务，其他线程发现队列空了就重新休眠，这个"叫醒一堆人但只有一个人有活干"的现象就是惊群效应。虽然Linux 2.6以后的核心里，accept上的惊群问题已经在大部分场景下被解决，但在条件变量这里，signal和broadcast的选择还是要动脑子的，不是无脑用一个就完事。
3.3 线程池销毁：优雅关闭比暴力关闭难得多
线程池的销毁看起来简单：放一个shutdown标志，唤醒所有线程，pthread_join等待它们退出。但实际项目中，怎么保证"当前正在执行的任务能跑完"和"排队中的任务不再被处理"这两个语义，是需要根据业务选择的。
我见过最粗暴的做法：直接exit(0)退出整个进程。如果任务都在内存里，没写进磁盘，这么干会丢数据。还有的做法是销毁时把队列里还没执行的任务直接丢弃，这在某些场景下可以接受（比如这些任务超时重发即可），但在另一些场景下会出大问题（比如这些任务是扣款指令）。
稳妥的做法是在线程池里加一个"销毁模式"参数，支持两种模式：
- 立即模式：置
shutdown标志，唤醒所有线程，队列中剩余任务直接丢弃 - 排空模式：置
shutdown标志后，等队列中所有任务执行完再让线程退出
排空模式的代码比立即模式复杂不少，核心在于工作线程在退出前要检查shutdown与队列状态的组合。不过这块逻辑一旦写对了，后面处理服务器关闭时的连接排空、日志落盘、指标上报都非常方便。
4. 高并发下的I/O模型选择：多线程与epoll的搭配关系
这里要澄清一个常见的误区：很多人在网上看到"epoll比多线程快"的说法，于是认为用了epoll就不需要多线程，或者写了多线程就不需要epoll。实际上，在高性能网络服务器的实践中，epoll和多线程是互补关系，不是替代关系。epoll解决的是"如何高效监听大量文件描述符上的IO事件"，多线程解决的是"如何并行处理这些事件对应的业务逻辑"。
4.1 单线程epoll的局限：事件处理不能被阻塞
用epoll写一个事件驱动的服务器，单线程确实能扛非常大数量的并发连接。但这有一个前提：事件处理函数必须非常快，不能有任何阻塞操作。一旦事件处理里有耗时操作——比如写日志、访问数据库、调用远程接口——整个事件循环就会卡住，所有连接都会感知到延迟。
举个例子：你用epoll同时监听10000个连接，假设其中有一个连接发来的请求需要执行一个耗时1秒的数据库查询。如果直接在事件处理函数里同步执行这个查询，那么这1秒内，其他9999个连接的数据包都会堆积在内核缓冲区里得不到处理，延迟直接拉满。这不是epoll的问题，是"单线程事件循环"模型的固有限制。
解决这个问题的主流做法是在epoll监听之上叠加工作线程池：epoll主线程只负责监听和分发，一旦监听到某个socket可读，就把这个socket上的任务扔给线程池去处理，epoll线程继续回到监听循环。这样即使某个任务耗时较长，也不会阻塞整个事件循环。
4.2 主从reactor结构与多线程的分工
在网络服务器领域，这种"一个主epoll循环 + 一池工作线程"的架构，本质上就是reactor模式的一种变体。更复杂的系统会做多级reactor：一个主reactor只负责accept新连接，然后把连接分发给多个子reactor，每个子reactor有自己的epoll实例和事件循环，子reactor再将具体业务任务交给线程池。
我们自己从零写服务器时，不需要一上来就上主从reactor这种大杀器。根据我的经验，项目起步阶段用"单epoll + 线程池"的架构最合适，理由有三个：
- 代码量可控，核心部分几百行能搞定
- 单reactor足够支撑数万级别的连接，大多数中小项目的并发量到不了这个量级
- 后面如果发现单reactor成为瓶颈，可以按连接hash到多个reactor，改造是增量式的，不需要推倒重来
用epoll配合线程池时，有几个细节非常影响最终效果：
- 事件分发时要把socket交给线程池处理，但不要让多个线程同时处理同一个socket的同一个事件。最简单的办法是监听EAGAIN与否，保证一个socket在某个时刻只有一个线程在读
- 写完数据后如果对方不读，
send()可能阻塞，所以要么把socket设为非阻塞，要么把"写"也丢给线程池 epoll的EPOLLET边缘触发模式配合非阻塞socket效率更高，但逻辑更复杂，如果刚接触，建议先用水平触发跑通再改边缘触发，否则会碰到读不干净导致的事件丢失问题
4.3 关于惊群的一个现实建议
epoll在多线程环境下有一个经典问题：多个线程同时epoll_wait同一个epoll实例，当一个事件发生时，多个线程会同时被唤醒，然后只有一个线程能成功处理，其他线程白忙一场。这就是惊群。Linux内核在较新版本里对accept的惊群做了处理，但epoll事件上的惊群仍需程序员自己规避。
通常的做法是：不要让多线程同时监听同一个epoll实例，而是把事件分发集中在一个线程，或者给每个线程单独的epoll实例并按连接hash分配到不同线程。后一种方式也就是前面说的多reactor结构，它天然规避了惊群问题。在面试场景下，如果你能把惊群效应的原理、内核层面的部分优化、以及应用层的规避方案都讲清楚，这个题目基本就稳了。
5. 实测阶段容易被放过的细节：从脏数据到连接风暴
理论讲再多，最后还是要落到"跑起来、压一压、看表现"这一步。我把自己在测试多线程网络服务器时踩过的几个典型问题整理成了一份清单，这些问题不是写得对不对的问题，而是"看起来对、跑起来抽风"的经典疑难杂症。
5.1 粘包和断包：TCP流式协议的第一课
TCP是流式协议，没有消息边界。多线程服务器处理并发请求时，粘包和断包几乎是必然发生的。如果协议设计里没有明确消息长度，就会出现：一次read()读到多个请求拼在一起；或者一个请求分多次read()才读完。
我在内部测试时常用一个很土但有效的协议设计：每个消息前固定4字节（uint32_t网络字节序）表示消息体长度，收数据时先收满4字节，再按长度收消息体。虽然比直接用\n分隔的文本协议多几行代码，但在高并发场景下稳定得多。文本协议在调试时方便，可在生产环境里容易踩"数据里有换行符"的坑。这个坑不是多线程特有的，但在多线程并发时排查起来会更痛苦，因为错误呈现是随机的，不固定触发。
5.2 连接断开后的read()返回值究竟是多少
处理长连接时，一个客户端主动断开、崩溃、或者网络异常，服务器端的read()返回值有讲究：
- 返回0：客户端正常关闭连接，应
close()该fd并清理线程内资源 - 返回-1且
errno等于EINTR：被信号中断，可以重试 - 返回-1且
errno等于EAGAIN或EWOULDBLOCK：非阻塞模式下暂时没有数据，不应该当错误处理 - 返回-1且
errno为其他值：真实错误，按协议决定是重试还是关闭
这里最容易被放过的是EINTR。如果你在测试时用gdb调试，或者系统里有些信号（比如SIGWINCH窗口变化）到达，read()可能返回EINTR。如果代码直接把它当错处理关闭连接，你会在压测时看到莫名其妙的连接被重置。正确处理是：碰到EINTR就重试，继续等数据，绝不能直接断连。
5.3 高并发压测时CPU100%但吞吐上不去：排查锁竞争和上下文切换
我遇到过一种现象：并发从100升到500时，CPU占用率已经接近满载，但吞吐量几乎没有增长，一味增加并发反而下降。用perf top看热点，往往能看到相当高比例的时间花在pthread_mutex_lock和pthread_cond_wait上。这就是锁竞争过于激烈导致的。
锁竞争治理的思路依次是：
- 缩小临界区：把能移出锁的读操作、计算操作全部移出去，只对真正需要原子改动的几行加锁
- 降低锁粒度：一个全局大锁换成多个细分锁，比如按连接ID取模分桶，每个桶一把锁
- 无锁化：使用原子操作、无锁队列、线程局部存储替代锁
- 减少同步频率：比如统计指标，不让每个线程实时写全局计数器，而是各自存在线程局部，定期合并
另外一个经常被忽视的方向是线程数量设置。线程数不是越多越好。对CPU密集型任务，线程数接近核心数最合适；对IO密集型任务，线程数可以多一些，但不能无限制。我的经验公式是：先设为CPU核心数的一到两倍做基准压测，观察吞吐量和延迟随线程数的变化曲线，找到拐点再定死。不要一上来就设置64个线程，大概率一半以上在空转睡大觉。
5.4 压测工具选择与验证方法
多线程网络服务器没有一个统一的"跑通即合格"标准，压测数据要结合业务定义来看。我自己常用的压测手段有三类：
ab（Apache Bench）适合HTTP协议的简单并发压测，优点是快速、结果直观wrk适合对长时间连接的HTTP服务做更精细的并发模拟，支持Lua脚本构造复杂请求- 自写的多线程压测客户端，可以用
pthread开N个线程模拟客户端，长时间连接并随机发送请求，用来暴露连接泄漏、句柄泄漏、内存增长等问题
如果是排查文件描述符泄漏，可以用watch -n 1 "ls /proc/你的服务pid/fd | wc -l"观察fd数量是否随连接数增长而持续上升。如果只增不降，基本可以断定有某个路径close()没执行到。这一招在排查嵌入式Linux项目、常驻进程的资源泄漏时同样有效。
还有一个很实用的验证思路：用strace -f -p 服务pid跟踪多线程服务器各线程的系统调用。它能直接看出当前各线程在做什么——是阻塞在read上，还是反复在epoll_wait上醒来无事可做，还是从accept返回后又立刻分发。这个工具对理解服务器在真实负载下的行为非常有帮助，建议多线程网络服务器的开发者在调优阶段养成用strace和perf的习惯。
5.5 连接风暴与Time_Wait状态
压测时短连接模式下，服务器端会大量出现TIME_WAIT状态。这个状态是主动关闭连接的一方在发出最后一个ACK后需要等待2MSL（Maximum Segment Lifetime）才会彻底释放连接。如果压测程序用短连接反复连服务器，服务端被动关闭接close()不主动发FIN，则不会有这个问题；但如果服务端主动关闭连接，就能看到大量TIME_WAIT占用fd和端口。
在测试环境下，可以通过设置SO_LINGER的linger结构来快速释放连接，缩短测试时间。生产环境一般不建议修改，因为TIME_WAIT是TCP协议正确性的重要保证，能防止旧连接的数据串到新连接上。但要注意，如果TIME_WAIT连接太多，ss -s能看到大量连接堆积，需要关注服务端是否有连接未能正常关闭或资源回收延迟过大。
6. 从"能跑"到"能扛"：一个最小可落地的优化顺序
前面章节讲了很多原理和陷阱，这里我整理一个在实战中验证过的落地顺序，适合已经跑通基础多线程服务器、但希望提升并发能力的开发者参考。这个顺序不是拍脑袋定的，而是基于"先消除明显的浪费，再做结构性优化"的原则。
第一步：把服务端所有socket都设为非阻塞。这一步成本最低，收益立竿见影。非阻塞模式下，accept、read、write不会卡住线程，配合EAGAIN处理逻辑，能极大降低单线程事件的阻塞风险。如果你的线程池已经就位，非阻塞socket能避免你的工作线程被一个慢客户端拖住。
第二步：引入epoll作为事件监听核心，使用水平触发+单线程reactor，把accept和IO事件分发统一管理。此时业务处理仍然用线程池，epoll线程只管监听和分发。这一步能让并发连接数直接从几百跳到几万，大多数业务场景已经够用。
第三步：如果压测发现epoll线程本身成为瓶颈（监听fd太多、事件分发频率太高），再考虑多reactor结构。按客户端fd取模，把连接分散到多个epoll实例上，每个epoll实例由一个线程负责。这一步的代码改动大多是结构性的，核心逻辑不变。
第四步：深度调优。围绕锁竞争、上下文切换、内存分配等做针对性优化。此时再用perf top、strace、ltrace、valgrind做分析，改一处验证一处。
每次压测必须有记录，不能凭感觉判断"快了还是慢了"。我会把连接数、线程数、CPU占用率、吞吐量、P99延迟这几个指标放在同一个表格里，每次调整后更新一行，方便对照。推荐你也建一个这样的压测日志，排查回归问题时特别有用。
我个人在实际写多线程网络服务器时的一个体会是：不要急着把所有技巧一股脑堆上去。先把最基础的一连接一线程跑通，看清瓶颈在哪，再换线程池；线程池跑通后，再引入epoll。每次只改一个维度，出了问题也知道往哪个方向排查。如果一上来就上主从reactor+无锁队列+内存池，代码出问题时，你根本不知道是哪里出的错，排查成本远远超过收益。
如果你眼下正好在做嵌入式Linux项目、或者正准备应对多线程面试题里的网络服务器部分，我最后再分享一条排查链路：出问题时，先看有没有 EAGAIN 和 EINTR，再看锁竞争，再看线程数和fd数量，最后才是业务逻辑。网络服务的问题，九成都在这个顺序里能找到答案。