Java多线程不一定提升性能，需满足CPU密集型任务可并行拆分或I/O密集型存在等待重叠执行；否则因上下文切换、锁竞争等反而拖慢速度。
Java多线程真能提升性能？先看这三点
不能一概而论。多线程只在「CPU密集型任务可并行拆分」或「存在I/O等待需重叠执行」时才有效；否则反而因上下文切换和锁竞争拖慢整体速度。
-
CPU密集型：比如矩阵乘法、图像渲染，核心数够且任务可分片时，
ForkJoinPool或parallelStream()才可能加速 -
I/O密集型：如HTTP请求、数据库查询，用
CompletableFuture配合线程池隐藏等待时间，但线程数不宜超过2 * CPU核心数 - 伪并行：单核机器上跑10个线程处理纯计算任务，大概率比单线程还慢——因为频繁切换消耗远超收益
上下文切换开销到底有多大？别靠猜
一次完整上下文切换（保存寄存器+调度+恢复）在现代JVM上通常耗时 1~5μs，看似微小，但高频竞争下会雪球式放大。
- 现象：
top显示%sy（系统态CPU）持续高于20%，jstack里大量线程卡在java.lang.Thread.State: RUNNABLE却没真正干活，基本是切换风暴 - 原因：同步块太宽（比如整个方法加
synchronized）、ReentrantLock争抢激烈、或线程池过载导致任务排队+唤醒频繁 - 验证：用
async-profiler抓取context-switch事件，或看/proc/<pid>/status</pid>中的voluntary_ctxt_switches和nonvoluntary_ctxt_switches
用 ThreadLocal 避免共享变量？小心内存泄漏
ThreadLocal 确实能隔离线程状态，但在线程池场景下极易引发 OutOfMemoryError，尤其当值是大对象或持有外部引用时。
- 根本问题：线程池复用线程，
ThreadLocal的Entry不会被自动清理，若忘记调用remove()，value 引用的对象就一直留在Thread的threadLocalsmap 里 - 典型场景：Web应用中用
ThreadLocal<Connection>存数据库连接，每次请求后没tl.remove()，连接对象随线程存活数小时 - 安全写法：务必在
try-finally块末尾调用tl.remove()；JDK 9+ 可考虑ThreadLocal<var>+clean()模式，但本质仍是手动清理
并发工具类选错，性能可能倒退十倍
ConcurrentHashMap、CopyOnWriteArrayList、BlockingQueue 各有适用边界，硬套会付出巨大代价。
立即学习“Java免费学习笔记（深入）”；
-
ConcurrentHashMap：读多写少且key分布均匀时极高效；但写操作占比超15%时，synchronized+HashMap可能更快（因避免了分段锁/扩容传播等开销） -
CopyOnWriteArrayList：仅适合「读极度频繁、写极少且集合小」，每次写都复制全量数组，10万元素写一次就是百MB内存抖动 -
LinkedBlockingQueuevsArrayBlockingQueue：前者动态扩容但锁粒度粗（put/take共用一把锁），后者固定容量但吞吐更稳；高并发生产者场景优先选ArrayBlockingQueue
最常被忽略的是线程生命周期与业务逻辑的耦合程度——比如把一个本该串行执行的事务流程强行拆到多个线程里，再花大力气同步状态，结果既没提速又引入死锁风险。并发不是银弹，是权衡后的选择。
