上一章我们通过最简单的HTTP服务获得了三语言的基准性能数据。但你很快会发现：当系统从“每个请求独占一个线程”演变为“成千上万个长连接、异步数据库调用、微秒级调度”时，并发模型的底层抽象成为决定性能天花板的关键变量。本章将拆解pthread、JVM线程、Python asyncio、C++20协程的本质，并通过百万级计数器的实战，让你亲眼看到上下文切换的代价。

2.1 并发模型的三次范式转移

在操作系统的视角下，执行流从重到轻可分为三层：

层次	代表	创建/切换成本	内存占用	适用场景
内核线程	pthread, JVM 1:1线程	切换≈1-10μs，需陷入内核	栈1-8MB	CPU密集型、阻塞系统调用多
用户态线程（协程）	asyncio, goroutine, VirtualThread	切换≈50-200ns，纯用户态	栈2-4KB	IO密集型、高并发连接
有栈协程 vs 无栈协程	C++20 coroutine (无栈) vs Boost.Fiber (有栈)	无栈更轻，但有状态限制	—	编译器级变换

核心认知：你无法通过增加更多内核线程来解决高并发——因为每个线程消耗MB级内存和昂贵的调度开销。当连接数达到10k时，1:1线程模型的内存占用可达10GB，且上下文切换会让CPU缓存频繁失效。

2.2 C++：三种并发模型的实战对比

C++是唯一给你“完整选择权”的语言：你可以使用原生线程、基于epoll的事件循环、或者C++20无栈协程。

2.2.1 实现一个“并发计数器”任务

任务描述：

• 启动N个工作执行体（线程/协程）

• 每个执行体执行10万次 counter++（原子操作）

• 测量总耗时、上下文切换次数、CPU利用率

版本1：std::thread（内核线程）

// cpp_thread_counter.cpp
#include <iostream>
#include <thread>
#include <vector>
#include <atomic>
#include <chrono>
#include <sched.h>

std::atomic<long long> counter{0};
const long long ITER_PER_WORKER = 100000;
const int WORKERS = 100;  // 100个内核线程

void worker() {
    for (long long i = 0; i < ITER_PER_WORKER; ++i) {
        counter.fetch_add(1, std::memory_order_relaxed);
    }
}

int main() {
    auto start = std::chrono::steady_clock::now();
    std::vector<std::thread> threads;
    for (int i = 0; i < WORKERS; ++i) {
        threads.emplace_back(worker);
    }
    for (auto& t : threads) t.join();
    auto end = std::chrono::steady_clock::now();
    auto dur = std::chrono::duration_cast<std::chrono::milliseconds>(end - start);
    std::cout << "Final counter: " << counter.load() 
              << " Time: " << dur.count() << " ms\n";
    return 0;
}
// 编译: g++ -O3 -pthread cpp_thread_counter.cpp -o cpp_thread_counter

观察结果（100个线程，每个10万次add）：

• 耗时约 1800ms（随调度器争用波动）

• perf stat 显示上下文切换次数 > 50万次

• CPU占用：分散在多个核心，但 cache bouncing 明显

版本2：单线程epoll + 异步任务队列（手工事件循环）

这种模型避免线程切换，但需要把“任务”切成小块。

// cpp_epoll_loop.cpp
#include <iostream>
#include <vector>
#include <atomic>
#include <functional>
#include <queue>
#include <thread>
#include <chrono>

std::atomic<long long> counter{0};
std::queue<std::function<void()>> tasks;
std::mutex mtx;

void worker_async(int remaining_tasks, int iter_per_task) {
    for (int i = 0; i < iter_per_task; ++i) {
        counter.fetch_add(1, std::memory_order_relaxed);
    }
    // 注意：实际生产环境会用epoll eventfd来唤醒loop
}

int main() {
    const int WORKERS = 100;
    const long long ITER_PER_WORKER = 100000;
    const int TASKS = WORKERS;
    const int ITER_PER_TASK = ITER_PER_WORKER;
    
    auto start = std::chrono::steady_clock::now();
    // 模拟单线程事件循环：直接执行所有任务（无切换）
    for (int i = 0; i < TASKS; ++i) {
        worker_async(0, ITER_PER_TASK);
    }
    auto end = std::chrono::steady_clock::now();
    auto dur = std::chrono::duration_cast<std::chrono::milliseconds>(end - start);
    std::cout << "Single-thread async counter: " << counter.load() 
              << " Time: " << dur.count() << " ms\n";
    return 0;
}

结果：耗时仅 45ms！因为没有线程切换、没有锁竞争（原子操作虽然内存屏障有开销，但远小于调度延迟）。这告诉我们：纯粹的CPU密集型任务，用单线程+事件循环是最快的。但缺点是无法利用多核。

版本3：C++20 无栈协程（配合io_context）

C++20协程是无栈的：编译器将协程函数变换为状态机，挂起时只保存局部变量到堆上分配的小对象。配合 asio::awaitable 可以写出异步代码但保持同步风格。

// cpp20_coroutine_counter.cpp (需要C++20及asio)
#include <asio/awaitable.hpp>
#include <asio/co_spawn.hpp>
#include <asio/detached.hpp>
#include <asio/io_context.hpp>
#include <asio/use_awaitable.hpp>
#include <iostream>
#include <atomic>
#include <vector>

std::atomic<long long> counter{0};
const long long ITER_PER_WORKER = 100000;
const int WORKERS = 100;

asio::awaitable<void> worker() {
    for (long long i = 0; i < ITER_PER_WORKER; ++i) {
        counter.fetch_add(1, std::memory_order_relaxed);
        asio::steady_timer co_await timer.async_wait(asio::use_awaitable); // 模拟挂起点
    }
    co_return;
}

int main() {
    asio::io_context ctx(1); // 单线程事件循环
    for (int i = 0; i < WORKERS; ++i) {
        asio::co_spawn(ctx, worker(), asio::detached);
    }
    auto start = std::chrono::steady_clock::now();
    ctx.run();
    auto end = std::chrono::steady_clock::now();
    auto dur = std::chrono::duration_cast<std::chrono::milliseconds>(end - start);
    std::cout << "Coroutine counter: " << counter.load() 
              << " Time: " << dur.count() << " ms\n";
    return 0;
}

结果：如果协程中没有真正的挂起（如上面的定时器），开销比纯函数略高（因为协程帧分配），但仍然远低于线程。实际生产中用协程处理大量IO请求时，每个请求占用内存极少（通常<512字节）。

2.2.2 C++并发模型决策指南

模型	优势	劣势	适合场景
std::thread	简单，直接使用多核	内存大，切换慢，上限低	少量并行任务（<200个）
epoll + 任务队列	极低调度开销	不能自动利用多核，编程模型割裂	单核高性能网关
C++20协程+asio	异步代码同步化，内存效率高	学习曲线陡，编译器支持不完全	万级连接微服务
线程池 + work stealing	兼顾多核与复用	任务粒度设计复杂	通用并行计算

2.3 Java：从传统线程池到虚拟线程（Project Loom）

Java的传统线程模型是 1:1 内核线程，每个 java.lang.Thread 对应一个操作系统线程。这导致高并发场景下必须使用线程池（如 Executors.newCachedThreadPool()），否则创建大量线程会迅速耗尽内存。

2.3.1 传统线程池压测

// JavaThreadPoolCounter.java
import java.util.concurrent.*;
import java.util.concurrent.atomic.AtomicLong;

public class JavaThreadPoolCounter {
    static final AtomicLong counter = new AtomicLong(0);
    static final long ITER_PER_WORKER = 100_000;
    static final int WORKERS = 100;
    
    static class Task implements Runnable {
        public void run() {
            for (long i = 0; i < ITER_PER_WORKER; i++) {
                counter.incrementAndGet(); // 使用CAS，非阻塞
            }
        }
    }
    
    public static void main(String[] args) throws Exception {
        ExecutorService pool = Executors.newFixedThreadPool(100);
        long start = System.nanoTime();
        for (int i = 0; i < WORKERS; i++) {
            pool.submit(new Task());
        }
        pool.shutdown();
        pool.awaitTermination(1, TimeUnit.MINUTES);
        long end = System.nanoTime();
        System.out.println("Counter: " + counter.get() + 
                           " Time: " + (end - start)/1_000_000 + " ms");
    }
}

结果：耗时约 120-150ms（比C++单线程版本慢，但比C++线程版快得多）。原因是线程池复用线程，减少了创建和销毁开销，但仍有内核调度。

2.3.2 虚拟线程（Java 21+）

虚拟线程是用户态协程的JVM实现：每个虚拟线程仅占用约200字节堆外内存，挂载在载体线程（Carrier Thread）上执行。当虚拟线程阻塞（如等待锁、IO）时，它会从载体线程上卸载，载体线程去执行另一个虚拟线程。

// JavaVirtualThreadCounter.java
import java.util.concurrent.atomic.AtomicLong;
import java.util.stream.IntStream;

public class JavaVirtualThreadCounter {
    static final AtomicLong counter = new AtomicLong(0);
    static final long ITER_PER_WORKER = 100_000;
    static final int WORKERS = 100_000; // 10万个虚拟线程！
    
    public static void main(String[] args) throws Exception {
        long start = System.nanoTime();
        var threads = IntStream.range(0, WORKERS)
            .mapToObj(i -> Thread.startVirtualThread(() -> {
                for (long j = 0; j < ITER_PER_WORKER; j++) {
                    counter.incrementAndGet();
                }
            }))
            .toList();
        for (var t : threads) t.join();
        long end = System.nanoTime();
        System.out.println("Counter: " + counter.get() + 
                           " Time: " + (end - start)/1_000_000 + " ms");
    }
}

惊人结果：即使创建10万个虚拟线程，也能在 2-3秒 内完成（传统线程池会在创建数千个线程时OutOfMemoryError）。而且虚拟线程之间的切换成本极低，因为它完全由JVM调度，不经过内核。

关键洞察：虚拟线程并非为“计算密集型”而生，上面例子由于没有真正的阻塞点，虚拟线程始终绑定在载体线程上，实际上与普通线程池效率相近。但若任务包含网络调用或锁等待，虚拟线程可以极大提升吞吐量，因为它允许载体线程复用。

2.3.3 Java 并发模型总结

机制	最大并发量（典型）	切换开销	编程复杂度
传统线程池	几千	高（内核）	低
ForkJoinPool	几万	中	中
虚拟线程	百万级	极低（用户态）	极低（同步代码自动挂起）

建议：如果你的应用运行在Java 21+，且存在大量阻塞（数据库、REST调用），请优先使用虚拟线程。它将让你的代码像同步一样简单，却获得协程的伸缩性。

2.4 Python：GIL下的并发假象与asyncio真相

Python最为人诟病的就是 全局解释器锁（GIL）——同一时刻只有一个线程执行Python字节码。这意味着 threading 模块对于CPU密集型任务完全无效，甚至因为锁竞争导致更慢。但对于IO密集型任务，线程会在系统调用时释放GIL，因此仍有价值。

2.4.1 多线程计数器（伪并发）

# py_thread_counter.py
import threading
import time

counter = 0
LOCK = threading.Lock()
ITER_PER_WORKER = 100000
WORKERS = 100

def worker():
    global counter
    for _ in range(ITER_PER_WORKER):
        with LOCK:
            counter += 1

start = time.time()
threads = [threading.Thread(target=worker) for _ in range(WORKERS)]
for t in threads: t.start()
for t in threads: t.join()
print(f"Counter: {counter}, Time: {(time.time()-start)*1000:.0f}ms")

结果：极其缓慢，耗时 > 10秒。因为GIL加上显式锁，导致大量串行化。

2.4.2 asyncio协同程序（单线程事件循环）

# py_asyncio_counter.py
import asyncio
import time

counter = 0
ITER_PER_WORKER = 100000
WORKERS = 100

async def worker():
    global counter
    for _ in range(ITER_PER_WORKER):
        counter += 1  # 注意：这里没有await，协程不会被挂起，相当于同步循环
        # 如果加上 await asyncio.sleep(0) 会极大降低性能

async def main():
    await asyncio.gather(*[worker() for _ in range(WORKERS)])

start = time.time()
asyncio.run(main())
print(f"Counter: {counter}, Time: {(time.time()-start)*1000:.0f}ms")

结果：耗时约 2-3秒（比多线程快，但仍远慢于Java/C++）。原因在于Python层面的整数加法比C语言慢得多，且存在大量字节码解释开销。

核心教训：asyncio 无法加速CPU密集型计算！它只是通过事件循环避免线程切换，适合 网络爬虫、Web服务器 这类高IO等待的场景。

2.4.3 结合multiprocessing绕过GIL

对于真正的CPU密集型，Python必须使用 multiprocessing，利用多进程绕过GIL。

# py_multiprocessing_counter.py
from multiprocessing import Pool, Value
import ctypes
import time

ITER_PER_WORKER = 100000
WORKERS = 100

def worker(counter):
    for _ in range(ITER_PER_WORKER):
        with counter.get_lock():
            counter.value += 1
    return counter.value

if __name__ == '__main__':
    counter = Value(ctypes.c_longlong, 0)
    start = time.time()
    with Pool(WORKERS) as pool:
        results = pool.map(worker, [counter]*WORKERS)
    end = time.time()
    print(f"Counter: {counter.value}, Time: {(end-start)*1000:.0f}ms")

结果：约 5000ms（5秒），比asyncio慢但至少利用了多核。但进程间同步开销巨大，序列化也是负担。

Python并发总结：

方案	适用场景	性能水平	复杂度
threading	IO密集型（但受GIL影响）	低	中
asyncio	高并发IO，万级连接	中（纯Python循环仍是瓶颈）	高
multiprocessing	CPU密集型	较高（但通信成本大）	中
混合（asyncio+run_in_executor）	混合负载	较好	高

2.5 实战：上下文切换成本的可视化测量

为了让你直观感受线程切换开销，我们设计一个实验：两个线程通过管道传递令牌（一个原子变量），每次传递增加1。测量完成10万次传递的时间。

C++版本

// cpp_pingpong.cpp
#include <atomic>
#include <thread>
#include <chrono>
#include <iostream>

std::atomic<int> flag{0}; // 0: thread A turn, 1: thread B turn
std::atomic<long> counter{0};
const long MAX_COUNT = 100000;

void thread_a() {
    while (counter < MAX_COUNT) {
        while (flag.load(std::memory_order_acquire) != 0) {
            // busy wait
        }
        counter++;
        flag.store(1, std::memory_order_release);
    }
}

void thread_b() {
    while (counter < MAX_COUNT) {
        while (flag.load(std::memory_order_acquire) != 1) {
        }
        counter++;
        flag.store(0, std::memory_order_release);
    }
}

int main() {
    auto start = std::chrono::steady_clock::now();
    std::thread t1(thread_a), t2(thread_b);
    t1.join(); t2.join();
    auto end = std::chrono::steady_clock::now();
    auto dur = std::chrono::duration_cast<std::chrono::microseconds>(end - start);
    std::cout << "Total switches: " << counter.load() << " time: " << dur.count() << " us\n";
}

结果：每次切换（两次线程上下文）大约花费 2-3微秒。如果每秒有一百万次切换，光调度就占2-3秒CPU。

Java版本

Java使用 Thread.yield() 或 LockSupport.parkNanos 可以实现类似效果，但因为有synchronized和操作系统调度器，结果类似。

关键结论：

• 内核线程上下文切换：2-10μs，且会污染TLB/缓存。

• 协程切换：50-200ns（纯用户态，只需保存寄存器+栈指针）。

• 因此，高并发系统应追求 用少量内核线程驱动大量用户态任务，这正是Java虚拟线程、Go goroutine、C++协程的模式。

2.6 本章小结与决策映射

通过本章的代码实验和数据对比，我们可以提炼出以下映射表：

你的业务特征	推荐并发模型	理由
CPU密集型，且可并行	C++线程池 / Java并行流 / Python multiprocessing	充分利用多核，但避免过度创建线程
IO密集型，超长连接（WebSocket, gRPC流）	Java虚拟线程 / C++协程 / Python asyncio	内存占用极低，支持十万级连接
突发高吞吐，但延迟不敏感	Java线程池 + 队列背压	成熟生态，易于调优
超低延迟（<100μs）	C++单线程轮询 + 无锁数据结构	消除所有调度和锁开销
快速原型，混合负载	Python asyncio + 协程	开发效率高，但需接受上限

下一章预告：并发模型只是第一层，内存管理才是高并发系统的暗流。我们将深入GC停顿、引用计数开销、手动内存管理，并通过一个“突发流量下内存碎片导致延迟毛刺”的真实案例，揭开三语言内存模型的全部秘密。你将会看到：为什么C++拥有极致性能却容易踩坑，为什么Java的GC在10万QPS下反而成为优势，以及Python的内存管理在哪些场景突然崩溃。敬请期待第3章《内存模型与GC修罗场》。