多线程奇幻漂流：从单核到多核并发的质变之路

字数: (7927)

阅读: (7909)

2026-04-11 21:54:57

内容摘要：多线程奇幻漂流：从单核到多核并发的质变之路,

在多核 CPU 普及之前，我们的世界几乎是单线程的。那时候的“并发”更像是一种障眼法，操作系统通过时间片轮转调度算法，让多个任务在极短的时间内交替执行，营造出同时运行的假象。想象一下，Nginx 接收到多个请求，看似同时处理，实际上它只能一个一个地来，只是速度足够快，让我们感觉不到延迟。但这种方式在面对大量并发连接时，性能瓶颈会非常明显。那时候，为了提升 Nginx 的性能，我们只能不断优化代码、调整配置，比如增加 worker 进程的数量，但本质上还是在单核上玩“花活”。

多线程奇幻漂流，说的就是从这种单核瓶颈突破，走向多核并发的历程。这不仅仅是硬件上的升级，更是编程思维和架构设计的深刻变革。

多核时代：真正的并行

多核 CPU 的出现，带来了真正的并行处理能力。每个核心都可以独立执行线程，不再需要时间片轮转。Nginx 可以利用多核 CPU，将请求分配到不同的 worker 进程/线程上，真正实现并发处理，大大提升了吞吐量。这种转变就像从单车道变成了多车道高速公路，效率提升是质的飞跃。

线程 vs 进程：选哪个？

在多核环境下，我们面临着线程和进程的选择。简单来说，进程拥有独立的地址空间，而线程共享进程的地址空间。进程间通信需要通过 IPC (Inter-Process Communication) 机制，例如管道、消息队列、共享内存等，开销较大。线程间通信则可以直接访问共享内存，效率更高。但同时，线程也面临着共享资源竞争和同步问题，需要使用锁、信号量等机制来保证线程安全。

例如，Java 的 Tomcat 服务器，默认采用多线程处理请求。因为 Web 应用通常需要在多个 Servlet 之间共享数据，使用线程更加方便。而 Nginx 则更倾向于使用多进程模型，因为进程间的隔离性可以提高系统的稳定性，避免一个 worker 进程崩溃影响整个服务。

锁的艺术：避免资源竞争

多线程编程中，最常见的坑就是资源竞争。多个线程同时访问和修改共享资源，可能导致数据不一致，甚至程序崩溃。为了避免这种情况，我们需要使用锁来保护共享资源。常见的锁包括互斥锁 (Mutex)、读写锁 (Read-Write Lock)、自旋锁 (Spin Lock) 等。

#include <iostream>
#include <thread>
#include <mutex>

std::mutex mtx; // 互斥锁
int counter = 0;

void increment()
{
    for (int i = 0; i < 100000; ++i)
    {
        mtx.lock(); // 加锁
        counter++;
        mtx.unlock(); // 解锁
    }
}

int main()
{
    std::thread t1(increment);
    std::thread t2(increment);

    t1.join();
    t2.join();

    std::cout << "Counter: " << counter << std::endl; // 输出结果应为 200000
    return 0;
}

这段 C++ 代码演示了如何使用互斥锁来保护共享变量 counter，避免多个线程同时修改它，从而保证结果的正确性。