减少线程切换：无锁编程与线程池优化

线程池并非越大越好，盲目增加线程数反而因频繁的上下文切换（每次耗时1–5微秒）导致CPU资源被大量吞噬、吞吐量不升反降；关键在于依据任务类型精准调优：CPU密集型任务线程数应接近CPU核心数+1，I/O密集型则需结合平均等待与工作时间估算，但须设合理上限；同时，无锁编程（如CAS）仅适用于极简状态变更，滥用会引发ABA问题或重试风暴，且无法替代对共享对象内部字段的线程安全保护——真正决定性能的，不是套用公式，而是深入理解代码究竟在等待什么：磁盘、网络、锁，还是真正在燃烧CPU。

为什么线程池设太大反而更慢

线程数超过 CPU 核心数太多时，上下文切换开销会吃掉大量 CPU 时间，实际吞吐不升反降。这不是理论，是 perf stat -e context-switches 能直接观测到的现象。

• Java 默认的 Executors.newCachedThreadPool() 无限扩容，高并发下可能瞬间创建数百线程，切换成本爆炸
• Go 的 goroutine 虽轻量，但调度器在系统线程（M）不足时仍会阻塞，GOMAXPROCS 设太小或太大都影响调度效率
• Python 的 concurrent.futures.ThreadPoolExecutor 若 max_workers 设为 os.cpu_count() * 5，I/O 密集场景尚可，CPU 密集型任务基本是在给调度器添堵

CAS 不是万能锁替代品，用错地方照样卡死

无锁编程靠 compareAndSet（Java）、__atomic_compare_exchange（C/C++）或 atomic.CompareAndSwapInt64（Go）实现，但只适合极简状态变更——比如计数器、标志位、单链表头插。一旦涉及多字段协同更新，ABA 问题或重试风暴立刻浮现。

• Java 中对 AtomicReference 存对象引用，若对象内部字段被多线程修改，CAS 本身不保证该对象的线程安全
• Go 的 atomic.Value 只支持整体替换，不能做 value.field++ 这类操作；强行用 unsafe.Pointer + CAS 操作结构体字段，极易因内存对齐或编译器重排出错
• Redis 的 INCR 是原子的，但用 GET + INCR + SET 模拟 CAS 就是典型错误——中间状态完全暴露，必须改用 INCR 或 EVAL 脚本

线程池容量怎么算：分清楚是 CPU 密集还是 I/O 密集

没有银弹公式，但有两个锚点：CPU 核心数和平均阻塞时间。关键不是“最大并发数”，而是“让 CPU 尽量不空转也不过载”。

• CPU 密集型（如图像处理、加密计算）：threadCount ≈ CPU核心数 + 1，+1 是为了弥补偶尔的页缺失或缓存未命中导致的短暂停顿
• I/O 密集型（如 HTTP 请求、数据库查询）：用 threadCount ≈ CPU核心数 × (1 + 平均等待时间 / 平均工作时间)，例如等待 90ms、工作 10ms，就是 ×10；但上限建议不超过 200，避免调度失衡
• Java ForkJoinPool 默认并行度是 Runtime.getRuntime().availableProcessors()，它专为拆分-合并任务设计，别拿它跑 DB 查询

上下文切换开销到底有多大

一次完整上下文切换（保存寄存器 + 切换栈 + TLB 刷新 + 恢复）在现代 x86 上通常耗时 1–5 μs。看起来不多？但每秒切 100 万次，就占掉 1–5 个核的全部时间。

• vmstat 1 看 cs（context switch）列，持续 > 50k/s 就得警惕；结合 pidstat -w 找具体进程
• Java 应用里频繁调用 Thread.sleep(1) 或 Object.wait() 且唤醒密集，会触发内核态休眠/唤醒路径，比纯用户态自旋更重
• Linux 的 /proc/sys/kernel/sched_latency_ns 控制调度周期，默认 6ms；如果线程数远超该周期内能调度的线程量，就会强制压缩每个线程的时间片，加剧切换频率

事情说清了就结束。真正难的不是套公式，是搞清你那段代码——它到底在等磁盘、等网卡、等锁，还是真正在烧 CPU。

到这里，我们也就讲完了《减少线程切换：无锁编程与线程池优化》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！