为何基于pthreads的累加程序线程数增加反而耗时变长？

兄弟，你的问题其实是多线程编程里很典型的「看似并行，实则内耗」的情况，咱们一步步拆解：

一、为什么sum结果有偏差？ #

这是**数据竞争（Data Race）**导致的。全局变量sum的累加操作（sum += 1）看起来是一行代码，但在CPU层面会被拆成三个独立指令：

1. 从内存/缓存加载sum的值到寄存器
2. 寄存器里的值加1
3. 把新值写回内存/缓存

当多个线程同时执行这三步时，很可能出现：线程A刚加载了sum的旧值，线程B已经完成累加并写回了新值，这时线程A再把自己计算的「旧值+1」写回去，直接覆盖了线程B的结果，最终sum就会比正确值偏小。

二、为什么线程数越多，耗时反而越长？ #

这个是核心痛点，主要有三个关键原因：

• 线程创建/销毁的开销：每创建一个pthread，操作系统都要为它分配栈空间、维护调度结构；销毁时还要回收这些资源。当线程数从1涨到11，这个额外开销会越来越明显——尤其是你的任务是纯计算型，单线程执行时间本身不算特别长，线程管理的开销占比就会被放大。
• 缓存一致性风暴：全局sum会被多个CPU核心的缓存加载。每次有线程修改sum，CPU的缓存一致性协议（比如MESI）会强制其他核心的缓存失效，这些核心必须重新从内存加载最新的sum值。线程越多，这种缓存失效和同步的频率就越高，大量时间都耗在了缓存同步上，反而比单线程（无需同步缓存）更慢。
• 上下文切换开销：如果你的CPU逻辑核心数小于11（比如常见的8核16线程，老CPU可能核心更少），操作系统会频繁在多个线程间切换上下文——保存当前线程的寄存器、栈状态，加载下一个线程的状态。这种切换本身要消耗CPU周期，线程数越多，切换越频繁，内耗就越大。

三、优化建议 #

针对你的累加场景，给你几个实用的优化方向：

1. 用「线程本地累加」替代全局直接操作 #

这是最高效的解决方案：

• 给每个线程分配独立的累加范围（比如线程0累加0_{99999999，线程1累加100000000}199999999，以此类推），让线程先把结果累加到本地变量里
• 所有线程完成后，再把每个线程的本地结果汇总到全局sum
  这样完全避免了多线程对同一变量的竞争，缓存同步开销几乎为0，性能提升会非常明显。

示例伪代码：

// 线程函数参数，包含每个线程的累加范围
typedef struct {
    long start;
    long end;
    long local_sum;
} ThreadArg;

void* thread_func(void* arg) {
    ThreadArg* t_arg = (ThreadArg*)arg;
    t_arg->local_sum = 0;
    for (long i = t_arg->start; i <= t_arg->end; i++) {
        t_arg->local_sum += i;
    }
    return NULL;
}

// 主函数汇总结果
int main() {
    const int THREAD_NUM = 8; // 建议等于CPU逻辑核心数
    ThreadArg args[THREAD_NUM];
    pthread_t threads[THREAD_NUM];

    // 分配每个线程的累加范围
    long total = 1000000000;
    long per_thread = total / THREAD_NUM;
    for (int i = 0; i < THREAD_NUM; i++) {
        args[i].start = i * per_thread + 1;
        args[i].end = (i == THREAD_NUM - 1) ? total : (i + 1) * per_thread;
        pthread_create(&threads[i], NULL, thread_func, &args[i]);
    }

    // 等待所有线程完成
    for (int i = 0; i < THREAD_NUM; i++) {
        pthread_join(threads[i], NULL);
    }

    // 汇总本地结果
    long final_sum = 0;
    for (int i = 0; i < THREAD_NUM; i++) {
        final_sum += args[i].local_sum;
    }
}

2. 控制线程数不超过CPU逻辑核心数 #

你可以用sysconf(_SC_NPROCESSORS_ONLN)获取当前系统的逻辑核心数，线程数设置为这个值或者+1就足够了——超过的话只会增加上下文切换开销，不会提升计算效率。

3. 避免伪共享（可选） #

如果后续还有类似共享变量的场景，可以通过填充字节让变量独占一个缓存行（通常64字节），避免和其他变量共享缓存行导致频繁缓存失效：

typedef struct {
    long local_sum;
    char padding[64 - sizeof(long)]; // 填充到64字节，独占缓存行
} ThreadArg;

4. 原子操作或互斥锁（备选方案） #

如果必须要共享变量累加，可以用原子操作替代互斥锁，开销更小：

#include <stdatomic.h>
atomic_long sum = 0;

// 线程内的累加操作
atomic_fetch_add(&sum, 1);

或者用pthread互斥锁保护sum的读写，但要注意锁的粒度——不要把整个循环放在锁里（那样会退化成单线程），只在sum += 1前后加锁解锁。不过这种方法的性能远不如线程本地累加，只适合无法拆分任务的场景。

5. 线程池减少线程创建开销（如果多次运行） #

如果你的程序需要多次执行累加任务，可以提前创建一个线程池，复用线程，避免每次都创建销毁线程的开销。

内容的提问来源于stack exchange，提问作者user4709059