为何多线程未提升执行效率？6核CPU下的实验异常分析

为什么多线程并行反而比串行更慢？ #

你的实验核心问题出在WorkLoader的循环逻辑上：

var s = ""
for (i in 1 .. 10_000_000) {
    val c : Char = (i % 95 + 32).toChar()
    s += c
    if (s.length > 200) {
        s = s.substring(1)
    }
}

Kotlin的String是不可变对象，每次+=都会创建新的String实例，substring(1)也会生成新字符串。1000万次循环会产生海量临时对象，触发频繁的垃圾回收（GC）。

当6个线程并行执行时：

• 多个线程同时抢占内存分配资源（比如JVM的TLAB本地线程分配缓冲区），导致分配延迟。
• GC触发频率急剧上升，即使是并发GC也存在停顿阶段，大量CPU时间消耗在GC的标记、清理、内存整理上，而非实际计算。
• 线程切换开销：线程因GC或内存竞争频繁被调度，额外消耗CPU资源。

这就是为什么并行时CPU占满100%但总耗时更长——大部分CPU时间都浪费在内存管理和线程调度上，真正的计算占比极低。

为什么单个线程执行时CPU没到100%？ #

单个线程执行时，垃圾对象产生频率远低于多线程并行场景，GC触发次数少。同时：

• 字符串拼接和截取涉及内存拷贝操作，属于内存带宽受限任务，线程会在内存拷贝时出现短暂等待，CPU不会持续满负载。
• 单个线程的GC停顿时间短、间隔长，CPU存在空闲窗口，所以整体负载只有47%左右。

多线程的意义到底是什么？ #

你的实验是典型的反例场景，刚好命中多线程的劣势场景：有大量内存分配/GC、无真正并行计算收益的任务。多线程的价值体现在以下核心场景：

• 纯CPU密集型任务：比如矩阵乘法、加密解密、视频编码这类无共享资源、无频繁内存操作的计算任务，多线程能充分利用多核CPU，总耗时接近单线程耗时除以核心数。
• IO密集型任务：比如网络请求、文件读写，线程在等待IO响应时会让出CPU，多线程可同时处理多个IO任务，大幅提升整体吞吐量。
• 响应式场景：比如桌面应用用后台线程处理任务，避免UI阻塞；Web服务器用多线程处理并发请求，防止单个请求拖垮整个服务。

如果把实验里的字符串操作换成纯计算（比如累加大数、质数判断），再跑6个线程，就能看到多线程的优势——总耗时会接近单线程的1/6左右。

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