线程池过大导致性能下降的主因是上下文切换开销激增。当线程数远超cpu核心数，频繁切换（1–5μs/次）吞噬大量cpu时间，吞吐不升反降；需据任务类型（cpu/i/o密集）合理设定线程数，避免盲目扩容。
为什么线程池设太大反而更慢
线程数超过 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。
