当前位置：首页 > news >正文

C++多线程TCP服务器实战：从线程池到高并发网络编程

news 2026/7/15 23:36:06

1. 项目概述与核心思路

上次我们聊了聊怎么用C++和基础的socket API搭一个能跑起来的TCP服务器，算是把地基给打好了。但那个版本，说实在的，就是个“玩具”。它一次只能伺候一个客户端，来第二个就得排队等着，这在真实世界里是完全行不通的。想象一下，你的聊天软件只能一个人在线，或者一个网页游戏只能一个人玩，那得多尴尬。

所以，这篇“续篇”的核心任务，就是让我们的服务器“长大成人”，具备同时服务多个客户端的能力，也就是实现高并发。在C++的世界里，实现高并发有几条主流路径：多进程、多线程、I/O多路复用（如select、poll、epoll），以及基于这些的异步模型。对于从“玩具”服务器升级到“实用”服务器这个阶段，多线程模型是一个承上启下、理解起来最直观的选择。它不像多进程那样资源开销大，也不像纯I/O多路复用那样对编程思维要求跳跃，它能让我们清晰地看到“一个连接一个线程”的处理流程，为后续理解更复杂的Reactor、Proactor等模型打下坚实的基础。

我们这次的目标很明确：改造之前的单线程服务器，引入线程池来管理客户端连接。当一个新客户端连接进来时，服务器不是自己埋头处理，而是从线程池里找一个“空闲工人”（线程）来专门负责和这个客户端通信。主线程（老板）只负责接待新客户（accept），然后把客户交给工人，自己立刻回去准备接待下一位。这样，多个客户端就能被同时服务了。

整个项目的核心将围绕几个关键点展开：如何安全地创建和管理一堆线程（线程池）、如何在线程间传递新连接（任务队列）、如何设计高效且线程安全的网络数据读写，以及最后，如何优雅地让整个服务器停下来。这些都是从理论走向实战必须趟过的坑。

2. 核心组件设计与原理拆解

2.1 线程池：服务器的“工人班组”

线程池是我们服务器的发动机。它的核心思想是空间换时间和资源复用。与其来一个请求就创建一个线程（创建和销毁线程开销很大），不如在服务器启动时就创建好一批线程，让它们处于等待状态。当有任务（新的客户端连接）到来时，唤醒一个线程去处理，处理完后线程不销毁，继续等待下一个任务。

一个最基础的线程池通常包含以下几个部分：

任务队列：一个线程安全的队列，用于存放待处理的任务。在我们的场景里，任务就是一个新接受的客户端套接字。
工作线程组：一组预先创建好的线程，它们不断地从任务队列中取出任务并执行。
同步机制：主要是互斥锁和条件变量，用于保护任务队列的并发访问，以及在工作线程无任务时让其休眠，有任务时将其唤醒。

为什么一定要用条件变量？想象一下，如果工作线程只是通过循环不断加锁、检查队列、解锁，这被称为“忙等待”，会白白消耗大量CPU资源。条件变量允许线程在条件不满足（队列为空）时主动休眠，让出CPU；当条件可能满足时（有新任务入队），再由其他线程通知它醒来。这是高效线程协作的关键。

2.2 连接管理与资源生命周期

在多线程环境下，每一个客户端连接都应该有独立的上下文，并且其生命周期要与处理它的线程绑定。通常，我们会在accept到一个新连接后，将其封装成一个ClientSession类的对象，这个对象里包含客户端的套接字、地址信息以及处理该连接所需的各种状态和数据缓冲区。然后，将这个ClientSession对象（或者其智能指针）作为任务投递到线程池的任务队列中。

这里有一个至关重要的细节：谁来负责关闭套接字和释放ClientSession对象？必须坚持“谁创建，谁负责”或“谁最后使用，谁负责”的原则。最清晰的模式是，处理这个会话的工作线程，在完成通信（例如，客户端断开连接）后，负责关闭套接字并清理对应的ClientSession对象。这避免了在主线程和工作线程之间复杂的资源所有权传递问题。

2.3 数据收发与协议设计

当服务器可以同时处理多个连接时，数据收发的复杂性就增加了。每个工作线程需要独立管理其对应客户端的输入输出缓冲区。这里常见的模型是“收到-解析-处理-回复”循环。

对于TCP这种字节流协议，消息边界是需要我们自己在应用层处理的。客户端发送的多个数据包可能在TCP层被粘在一起（粘包），也可能一个数据包被拆成多次收到（拆包）。常见的解决方案有：

定长协议：每个消息长度固定。简单但不够灵活。
分隔符协议：用特殊字符（如换行符\n）标记消息结束。适用于文本协议。
长度前缀协议：在每个消息头部固定几个字节（如4字节的int），用来表示后面消息体的长度。这是最通用、最可靠的方式，也是我们推荐在实战中采用的。

在我们的实现中，每个ClientSession需要维护一个接收缓冲区。工作线程循环调用recv，将数据追加到缓冲区，然后尝试从缓冲区头部解析出一个完整的、带长度前缀的消息。只有解析出一个完整消息后，才交给业务逻辑处理函数。处理完成后，将响应数据（同样以长度前缀格式组织）通过send发回。这样，每个连接的处理逻辑就清晰且独立了。

3. 关键代码实现与解析

下面，我们分模块来看关键代码。为了清晰，我会先给出类定义，再解释核心实现。

3.1 线程池实现

首先，我们实现一个通用的ThreadPool类。它不关心任务具体是什么，只负责执行std::function<void()>类型的可调用对象。

// ThreadPool.h #include <vector> #include <queue> #include <thread> #include <mutex> #include <condition_variable> #include <functional> #include <atomic> class ThreadPool { public: explicit ThreadPool(size_t numThreads); ~ThreadPool(); // 提交一个任务到线程池 template<class F> void enqueue(F&& task); // 等待所有任务完成并停止线程池（可选） void waitAndStop(); private: // 工作线程函数 void worker(); std::vector<std::thread> workers_; // 工作线程容器 std::queue<std::function<void()>> tasks_; // 任务队列 std::mutex queueMutex_; // 保护任务队列的互斥锁 std::condition_variable condition_; // 用于线程等待/通知的条件变量 std::atomic<bool> stop_{false}; // 停止标志，原子操作保证线程安全 };

// ThreadPool.cpp #include "ThreadPool.h" ThreadPool::ThreadPool(size_t numThreads) { for (size_t i = 0; i < numThreads; ++i) { workers_.emplace_back([this] { this->worker(); }); } } ThreadPool::~ThreadPool() { if (!stop_) { waitAndStop(); } } template<class F> void ThreadPool::enqueue(F&& task) { { std::unique_lock<std::mutex> lock(queueMutex_); if (stop_) { throw std::runtime_error("enqueue on stopped ThreadPool"); } tasks_.emplace(std::forward<F>(task)); } condition_.notify_one(); // 通知一个等待中的工作线程 } void ThreadPool::worker() { while (true) { std::function<void()> task; { std::unique_lock<std::mutex> lock(queueMutex_); // 等待条件：任务队列非空 或 线程池被要求停止 condition_.wait(lock, [this] { return stop_ || !tasks_.empty(); }); if (stop_ && tasks_.empty()) { return; // 线程池已停止且无任务，工作线程退出 } task = std::move(tasks_.front()); tasks_.pop(); } task(); // 执行任务 } } void ThreadPool::waitAndStop() { { std::unique_lock<std::mutex> lock(queueMutex_); stop_ = true; } condition_.notify_all(); // 通知所有工作线程检查停止标志 for (std::thread& worker : workers_) { if (worker.joinable()) { worker.join(); } } }

关键点解析：

condition_variable::wait与谓词：wait的第二个参数是一个lambda谓词。它避免了“虚假唤醒”（spurious wakeup）带来的问题。线程被唤醒后，会再次检查谓词条件（!tasks_.empty() || stop_），只有条件真正满足才会继续，否则继续等待。
notify_onevsnotify_all：enqueue后我们调用notify_one()，因为只增加了一个任务，唤醒一个线程就够了，效率更高。而在waitAndStop中，我们调用notify_all()，因为要通知所有线程“停止信号来了”。
资源管理：析构函数中调用waitAndStop()，确保所有任务完成后线程正确join，防止资源泄漏。这是一种RAII（资源获取即初始化）思想的体现。

3.2 客户端会话类

接下来，定义代表一个客户端连接的ClientSession类。它封装了与一个客户端通信的全部状态。

// ClientSession.h #include <sys/socket.h> #include <netinet/in.h> #include <unistd.h> #include <string> #include <vector> class ClientSession { public: explicit ClientSession(int clientSocket, const struct sockaddr_in& clientAddr); ~ClientSession(); // 禁止拷贝 ClientSession(const ClientSession&) = delete; ClientSession& operator=(const ClientSession&) = delete; // 处理该会话的主函数，将由线程池调用 void run(); private: // 接收数据到缓冲区 bool receiveData(); // 从缓冲区解析出一个完整消息 bool parseMessage(std::string& message); // 处理业务逻辑 std::string processRequest(const std::string& request); // 发送数据 bool sendData(const std::string& data); int clientSocket_; // 客户端套接字 struct sockaddr_in clientAddr_; // 客户端地址 std::vector<char> recvBuffer_; // 接收缓冲区 static const size_t BUFFER_SIZE = 4096; // 缓冲区初始大小 static const size_t HEADER_SIZE = 4; // 长度头大小，4字节 };

// ClientSession.cpp #include "ClientSession.h" #include <iostream> #include <arpa/inet.h> #include <cstring> ClientSession::ClientSession(int clientSocket, const struct sockaddr_in& clientAddr) : clientSocket_(clientSocket), clientAddr_(clientAddr) { recvBuffer_.reserve(BUFFER_SIZE); char ipStr[INET_ADDRSTRLEN]; std::cout << "[+] New connection from " << inet_ntop(AF_INET, &clientAddr_.sin_addr, ipStr, sizeof(ipStr)) << ":" << ntohs(clientAddr_.sin_port) << std::endl; } ClientSession::~ClientSession() { if (clientSocket_ >= 0) { close(clientSocket_); std::cout << "[-] Connection closed." << std::endl; } } void ClientSession::run() { while (true) { // 1. 接收数据 if (!receiveData()) { break; // 接收失败或连接关闭，退出循环 } // 2. 循环解析并处理缓冲区中的完整消息 std::string message; while (parseMessage(message)) { // 3. 处理业务逻辑 std::string response = processRequest(message); // 4. 发送响应 if (!sendData(response)) { return; // 发送失败，结束会话 } } // 缓冲区数据不足一个完整消息，继续接收 } } bool ClientSession::receiveData() { char tempBuffer[BUFFER_SIZE]; ssize_t bytesRead = recv(clientSocket_, tempBuffer, sizeof(tempBuffer), 0); if (bytesRead > 0) { // 将新数据追加到接收缓冲区 recvBuffer_.insert(recvBuffer_.end(), tempBuffer, tempBuffer + bytesRead); return true; } else if (bytesRead == 0) { // 客户端优雅关闭连接 std::cout << "[*] Client disconnected gracefully." << std::endl; return false; } else { // recv 出错 perror("recv failed"); return false; } } bool ClientSession::parseMessage(std::string& message) { // 检查缓冲区长度是否足够读取头部（4字节长度） if (recvBuffer_.size() < HEADER_SIZE) { return false; } // 从缓冲区前4字节解析出消息体长度（网络字节序 -> 主机字节序） uint32_t msgLength = 0; std::memcpy(&msgLength, recvBuffer_.data(), HEADER_SIZE); msgLength = ntohl(msgLength); // 转换字节序 // 检查缓冲区是否包含完整的消息体 if (recvBuffer_.size() < HEADER_SIZE + msgLength) { return false; } // 提取完整消息 message.assign(recvBuffer_.begin() + HEADER_SIZE, recvBuffer_.begin() + HEADER_SIZE + msgLength); // 从缓冲区中移除已处理的数据 recvBuffer_.erase(recvBuffer_.begin(), recvBuffer_.begin() + HEADER_SIZE + msgLength); return true; } std::string ClientSession::processRequest(const std::string& request) { // 这里是业务逻辑处理的地方 // 示例：简单回显，并附加服务器标识 std::string response = "[Echo from Server] " + request; // 在实际应用中，这里可能是数据库查询、计算等 return response; } bool ClientSession::sendData(const std::string& data) { // 构造带长度前缀的数据包 uint32_t msgLength = htonl(static_cast<uint32_t>(data.size())); // 主机字节序 -> 网络字节序 std::vector<char> packet(HEADER_SIZE + data.size()); std::memcpy(packet.data(), &msgLength, HEADER_SIZE); std::memcpy(packet.data() + HEADER_SIZE, data.data(), data.size()); ssize_t totalSent = 0; while (totalSent < packet.size()) { ssize_t bytesSent = send(clientSocket_, packet.data() + totalSent, packet.size() - totalSent, 0); if (bytesSent <= 0) { perror("send failed"); return false; } totalSent += bytesSent; } return true; }

关键点解析：

粘包拆包处理：parseMessage函数是核心。它先判断缓冲区是否有4字节的头部，解析出长度msgLength，再判断缓冲区是否有完整的msgLength字节的消息体。只有两者都满足，才提取出一个完整消息。这种“长度前缀法”是处理TCP流式数据的标准做法。
缓冲区管理：使用std::vector<char>作为接收缓冲区，利用其动态扩容的特性。处理完一个完整消息后，使用erase将已消费的数据从缓冲区头部移除。这里没有用循环队列，对于学习示例，vector的erase操作虽然可能引起数据移动，但代码更清晰。生产环境可以考虑更高效的结构，如环形缓冲区。
send循环：sendData函数中的while循环很重要。send系统调用不保证一次性发送完所有数据，它只返回本次实际发送的字节数。因此，我们需要循环发送，直到所有数据发送完毕。这是编写可靠网络程序的一个基本要点。
字节序转换：htonl和ntohl用于在主机字节序和网络字节序（大端序）之间转换。这是跨平台网络通信的必备操作，确保不同架构的机器能正确理解长度字段。

3.3 主服务器逻辑整合

最后，我们修改主函数，将监听套接字、线程池和ClientSession整合起来。

// main.cpp #include "ThreadPool.h" #include "ClientSession.h" #include <iostream> #include <sys/socket.h> #include <netinet/in.h> #include <unistd.h> #include <memory> #include <csignal> #include <atomic> std::atomic<bool> g_running{true}; void signalHandler(int signum) { std::cout << "\n[*] Interrupt signal received. Shutting down..." << std::endl; g_running = false; } int main() { // 设置信号处理，优雅退出 std::signal(SIGINT, signalHandler); // Ctrl+C std::signal(SIGTERM, signalHandler); // kill命令 // 1. 创建监听套接字 (和上篇相同) int serverFd = socket(AF_INET, SOCK_STREAM, 0); if (serverFd == -1) { perror("socket creation failed"); return 1; } // 设置SO_REUSEADDR选项，避免“Address already in use”错误 int opt = 1; if (setsockopt(serverFd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)) < 0) { perror("setsockopt failed"); close(serverFd); return 1; } struct sockaddr_in serverAddr; serverAddr.sin_family = AF_INET; serverAddr.sin_addr.s_addr = INADDR_ANY; // 监听所有网卡 serverAddr.sin_port = htons(8080); // 监听8080端口 if (bind(serverFd, (struct sockaddr*)&serverAddr, sizeof(serverAddr)) < 0) { perror("bind failed"); close(serverFd); return 1; } if (listen(serverFd, 128) < 0) { // 设置连接请求队列长度为128 perror("listen failed"); close(serverFd); return 1; } std::cout << "[*] TCP Server listening on port 8080..." << std::endl; // 2. 创建线程池，例如8个线程 const size_t numThreads = 8; ThreadPool pool(numThreads); std::cout << "[*] ThreadPool started with " << numThreads << " threads." << std::endl; // 3. 主循环：接受连接并提交任务 while (g_running) { struct sockaddr_in clientAddr; socklen_t clientLen = sizeof(clientAddr); int clientSocket = accept(serverFd, (struct sockaddr*)&clientAddr, &clientLen); if (clientSocket < 0) { if (g_running) { // 如果不是因为退出信号导致的错误，则打印 perror("accept failed"); } continue; // 继续接受下一个连接 } // 将新连接封装成任务，提交到线程池 // 使用lambda捕获clientSocket和clientAddr，创建ClientSession对象 pool.enqueue([clientSocket, clientAddr]() { // 使用智能指针管理ClientSession生命周期，确保run结束后自动析构关闭socket auto session = std::make_unique<ClientSession>(clientSocket, clientAddr); session->run(); // session 离开作用域，unique_ptr自动释放，~ClientSession()会关闭socket }); } // 4. 清理 std::cout << "[*] Server shutting down..." << std::endl; close(serverFd); // ThreadPool析构函数会调用waitAndStop，等待所有任务完成 std::cout << "[*] Server stopped." << std::endl; return 0; }

关键点解析：

信号处理：我们设置了SIGINT和SIGTERM的信号处理函数，将全局标志g_running设为false。这允许我们通过Ctrl+C或kill命令来优雅地停止服务器，而不是强制终止。主循环会检查这个标志。
SO_REUSEADDR选项：这个选项非常重要。它允许服务器在关闭后立即重启，而不用等待之前的连接完全释放（处于TIME_WAIT状态）。没有这个选项，在快速重启服务器时经常会遇到“Address already in use”的错误。
任务提交：accept成功后，我们创建一个lambda表达式作为任务。这个lambda捕获了clientSocket和clientAddr（这里是值捕获，复制了结构体），并在其中创建ClientSession对象并调用其run方法。使用std::make_unique可以确保即使run方法中抛出异常，ClientSession的析构函数也会被调用，从而关闭套接字，避免资源泄漏。
优雅关闭：当g_running变为false，主循环退出。我们关闭监听套接字serverFd，这样accept调用会立即失败，加速循环退出。ThreadPool对象pool在main函数结束时析构，其析构函数会调用waitAndStop()，等待所有已提交的任务（正在处理的客户端会话）完成，然后才结束所有工作线程。这确保了服务器不会突然切断现有连接。

4. 编译、运行与测试

4.1 编译命令

假设你的项目文件结构如下：

your_project/ ├── ThreadPool.h ├── ThreadPool.cpp ├── ClientSession.h ├── ClientSession.cpp └── main.cpp

使用g++编译（需要支持C++11）：

g++ -std=c++11 -pthread -o tcp_server main.cpp ThreadPool.cpp ClientSession.cpp

-std=c++11：启用C++11标准，我们需要其中的线程库、智能指针等特性。
-pthread：链接POSIX线程库，这是Linux下多线程编程所必需的。
-o tcp_server：指定输出可执行文件名为tcp_server。

4.2 运行服务器

在终端运行编译好的程序：

./tcp_server

如果看到输出[*] TCP Server listening on port 8080...和[*] ThreadPool started with 8 threads.，说明服务器启动成功。

4.3 使用Telnet进行简单测试

打开另一个终端，使用telnet命令连接服务器（如果你的系统没有telnet，可以使用netcatnc）：

telnet 127.0.0.1 8080

连接成功后，尝试输入一些文字，比如Hello Server，然后回车。你应该会看到服务器返回的消息，类似[Echo from Server] Hello Server。你可以同时打开多个终端运行telnet，模拟多个客户端，观察服务器是否能同时响应。

4.4 使用简单的Python脚本进行压力测试

Telnet测试的是功能，我们还需要测试并发能力。写一个简单的Python脚本，模拟多个客户端同时连接并发送消息。

# stress_test.py import socket import threading import time def client_thread(client_id, host='127.0.0.1', port=8080): try: sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(5) # 设置超时 sock.connect((host, port)) message = f"Message from client {client_id}" # 构造带4字节长度前缀的消息 (网络字节序，大端) msg_length = len(message) header = msg_length.to_bytes(4, byteorder='big') # 对应C++的htonl data = header + message.encode() sock.sendall(data) # 接收响应 header = sock.recv(4) if len(header) < 4: print(f"Client {client_id}: Failed to receive header") return resp_length = int.from_bytes(header, byteorder='big') response = sock.recv(resp_length) print(f"Client {client_id} received: {response.decode()}") sock.close() except Exception as e: print(f"Client {client_id} error: {e}") if __name__ == "__main__": threads = [] num_clients = 50 # 模拟50个并发客户端 print(f"Starting {num_clients} concurrent clients...") start_time = time.time() for i in range(num_clients): t = threading.Thread(target=client_thread, args=(i,)) threads.append(t) t.start() for t in threads: t.join() end_time = time.time() print(f"All clients finished in {end_time - start_time:.2f} seconds.")

运行这个脚本：

python3 stress_test.py

观察服务器终端的输出，应该会快速打印出许多来自不同客户端的连接和断开信息。同时，Python脚本会打印出每个客户端收到的回显。这个测试可以验证线程池是否能有效处理并发连接。

5. 深入探讨、优化与常见问题

5.1 “惊群”问题与Accept策略

在我们当前的实现中，只有一个主线程在调用accept。这是一种简单有效的模式。但在一些高性能场景下，人们可能会尝试让多个线程同时调用accept（例如，每个工作线程都去accept），以期获得更高的连接接入性能。这在Linux上会导致著名的“惊群”（Thundering Herd）问题：当一个新的连接到来时，所有阻塞在accept上的线程都会被唤醒，但只有一个能成功接受连接，其他线程唤醒后发现没有连接，又得回去睡眠，造成了不必要的上下文切换开销。

解决方案：

使用SO_REUSEPORT选项（Linux 3.9+）：允许多个套接字绑定到相同的IP和端口，内核会使用哈希算法将新连接分配给其中一个监听套接字，从而在多个accept线程间实现负载均衡。这需要为每个工作线程创建独立的监听套接字。
保持单线程Accept，多线程处理：也就是我们目前采用的方式。这是最经典、最稳定的模式。连接接入的性能瓶颈通常不在accept本身，而在于后续的业务处理。单线程Accept完全能满足大多数场景。
使用I/O多路复用+线程池：这是更高级的模式，主线程使用epoll等机制监听监听套接字和所有客户端套接字的事件，然后将就绪的连接或读写事件分发给工作线程池处理。这超出了本文“一个连接一个线程”的范畴，是迈向更高性能架构（如Reactor）的一步。

建议：除非你确信连接建立速率（每秒成千上万）是瓶颈，否则坚持使用单线程Accept模式。它的简单性和稳定性是最大的优点。

5.2 线程池大小的设定

线程池里应该有多少个线程？这不是一个固定值。

CPU密集型任务：如果ClientSession::run()中的processRequest是纯计算（例如图像处理、复杂数学运算），那么线程数最好等于或略多于CPU核心数，以避免过多的线程切换开销。
I/O密集型任务：网络服务器大部分时间都在等待I/O（recv,send, 甚至数据库查询）。这时，线程可以比CPU核心数多很多，因为当一个线程在等待I/O时，CPU可以切换到其他线程去执行。线程数可以设定为核心数 * (1 + 等待时间/计算时间)。这个公式很难精确，一个常见的经验值是2 * CPU核心数 + 1，或者根据压测结果动态调整。

在我们的示例中，简单的回显服务是I/O密集型的。你可以通过修改main.cpp中的numThreads常量来实验。观察在不同并发客户端数量下，服务器的响应时间和CPU使用率。一个动态调整线程池大小的实现会更复杂，但生产级的线程池库（如C++17后的std::jthread配合自定义调度器，或第三方库）通常会提供此类功能。

5.3 错误处理与资源泄漏防御

网络编程中，处处都可能出错。健壮的程序必须处理各种错误。

accept,recv,send错误：这些系统调用都可能失败。我们示例中使用了perror打印错误，在实际项目中，可能需要更精细的错误码处理和日志记录。特别是recv返回0表示对端关闭连接，这是一个正常情况，不是错误。
内存与资源泄漏：这是我们使用智能指针（std::unique_ptr<ClientSession>）的主要原因。它保证了即使在run()函数中发生异常，ClientSession的析构函数也会被调用，从而关闭套接字。同样，ThreadPool的析构函数确保了所有工作线程都能正确join。
线程安全：我们的ThreadPool使用互斥锁保护任务队列，使用条件变量进行同步，这是正确的。确保共享数据（如日志文件、全局统计计数器）的访问也是线程安全的，可能需要额外的锁。

5.4 性能瓶颈分析与下一步优化方向

当你的多线程服务器跑起来后，可能会发现性能并没有达到预期，或者在压力测试下出现响应变慢甚至崩溃。可以从以下方面排查：

锁竞争：线程池的任务队列是共享资源，频繁的入队和出队操作会带来锁竞争。如果业务处理非常快（比如我们的回显），那么锁竞争可能成为瓶颈。可以考虑使用无锁队列（如moodycamel::ConcurrentQueue）来替换std::queue+std::mutex。
上下文切换开销：如果线程数远大于CPU核心数，操作系统调度线程的上下文切换开销会变得显著。监控系统负载（top命令看%sy系统时间）可以辅助判断。
recv/send系统调用开销：每个消息都调用一次系统调用是有成本的。对于小消息频繁的场景，可以考虑使用readv/writev进行向量化I/O，或者更激进地，使用I/O多路复用（如epoll）结合非阻塞I/O，让少数线程就能管理成千上万的连接。这就是从“一个连接一个线程”的Thread-Per-Connection模型，演进到Reactor/Proactor事件驱动模型。这是构建真正高并发服务器（如Nginx、Redis）的基石。
业务逻辑瓶颈：如果processRequest函数本身很慢（比如涉及慢速的磁盘I/O或远程API调用），那么增加线程数也解决不了问题。需要考虑异步操作或将慢速任务卸载到专门的任务队列中。