多线程性能下降主因是上下文切换开销过大，线程数应依CPU核心数合理设置：CPU密集型≤核心数，IO密集型可×2～×4；需防线程泄漏、阻塞线程池及ThreadLocal内存泄漏。
线程数超过CPU核心数后性能反而下降
多线程不是越多越快，当 Thread 数量远超可用 CPU 核心数（比如 16 核机器启了 200 个线程），操作系统频繁做上下文切换，实际花在「调度」上的时间可能超过「干活」的时间。这时候吞吐不升反降，延迟还飙升。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用
Runtime.getRuntime().availableProcessors()获取真实可用核心数，作为线程池初始上限参考 - IO 密集型任务可适当放宽（比如 ×2～×4），但别无脑设成
Integer.MAX_VALUE - CPU 密集型任务线程数建议 ≤ 核心数，甚至用
ForkJoinPool.commonPool()这类工作窃取池更稳妥 - 压测时观察
vmstat 1的cs（context switch）列，持续高于 10k/s 就该怀疑调度开销过大
ExecutorService 用完没 shutdown 导致线程泄漏
每次 new 一个 ThreadPoolExecutor 却忘记调 shutdown() 或 shutdownNow()，线程不会自动回收，JVM 退出前这些线程一直占着资源，轻则内存缓慢上涨，重则触发 OOM 或阻塞应用关闭。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 把
ExecutorService声明为final成员变量，配合@PreDestroy（Spring）或try-with-resources（需实现AutoCloseable）确保释放 - 避免在工具类里写
Executors.newFixedThreadPool(10)这种静态工厂方法——它返回的池无法被外部控制生命周期 - 上线前用
jstack <pid></pid>检查线程 dump，确认没有大量WAITING状态的pool-*.thread-*
Runnable 中混用同步块和 CompletableFuture 导致阻塞线程池
在 CompletableFuture.supplyAsync(..., executor) 里传入的 executor 如果是固定大小的 ThreadPoolExecutor，而任务内部又调用了 synchronized 方法、Object.wait() 或阻塞 IO（如 SocketInputStream.read()），就会卡住整个线程，让后续任务排队等待，池子很快耗尽。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 对已知会阻塞的操作（数据库查询、HTTP 调用），显式使用独立的 IO 专用线程池，例如
Executors.newCachedThreadPool()或带队列的ThreadPoolExecutor - 用
CompletableFuture.thenApplyAsync(..., ioExecutor)显式指定非默认池，别依赖ForkJoinPool.commonPool() - 检查日志中是否频繁出现
java.lang.Thread.State: WAITING (on object monitor)，这是同步块阻塞的典型痕迹
ThreadLocal 没清理引发内存泄漏
ThreadLocal 变量如果存了大对象（比如 Map、Connection），在线程复用场景下（如 Tomcat 线程池、ThreadPoolExecutor），不手动调 remove()，会导致对象一直被线程强引用，GC 清不掉，久而久之堆内存膨胀。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 所有
ThreadLocal.set()后，必须配对写ThreadLocal.remove()，尤其在finally块里 - 不要在
ThreadLocal里存可变大对象；优先考虑方法参数传递或局部变量 - 排查时用
jmap -histo:live <pid></pid>看java.lang.ThreadLocal$ThreadLocalMap$Entry实例数是否异常高
线程问题最难调试的，往往不是崩溃，而是「看起来还在跑，但就是慢得不合理」——这时候得盯住线程状态、上下文切换频次、池子是否枯竭、以及 ThreadLocal 是否悄悄吃掉了内存。别只看代码写了几个 new Thread()，要看它们活多久、干啥活、谁在等谁。
