为什么线程数设成 CPU 核心数反而更慢
因为 ExecutorService 的线程数 ≠ CPU 密集型任务的理想并发数。当任务含 I/O、锁等待或远程调用时，线程会阻塞，此时需要更多线程来维持吞吐。盲目设为 Runtime.getRuntime().availableProcessors()，会导致大量线程空转、频繁抢占 CPU，上下文切换激增。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 区分任务类型：纯计算型（如图像编码）可按核心数设；混合型（如 Web 请求处理）需压测后调整
- 用
jstack或jcmd <pid> VM.native_memory summary观察线程状态，若WAITING或BLOCKED占比高，说明线程闲置多，可适当增加 - 避免硬编码核心数，改用配置项 + 启动参数控制，例如
-Dpool.core.size=8
ThreadPoolExecutor 的 keepAliveTime 怎么设才不拖慢切换
keepAliveTime 控制空闲线程存活时长。设得太短（如 10ms），线程频繁销毁重建，触发 JVM 线程栈分配/回收和 OS 级调度开销；设得太长（如 5min），空闲线程长期占着资源，挤占其他任务调度机会。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 对短时突发流量场景，设
keepAliveTime = 60L秒，配合allowCoreThreadTimeOut(true)，让所有线程都可超时退出 - 对稳定长连接服务（如 gRPC server），保持
keepAliveTime为 0（即核心线程永驻），但必须限制最大线程数，防 OOM - 注意单位：
TimeUnit.SECONDS和TimeUnit.MILLISECONDS混用是常见错误，new ThreadPoolExecutor(4, 8, 60, TimeUnit.SECONDS, ...)才是常规写法
使用 ForkJoinPool 代替 ExecutorService 会减少上下文切换吗
不一定。ForkJoinPool 基于工作窃取（work-stealing），单个线程能动态处理多个子任务，理论上降低线程总数需求。但它只对可分解的 CPU 密集型任务（如归并排序、树遍历）有效；对带锁、I/O 或外部依赖的任务，反而因任务拆分+合并引入额外开销，且窃取逻辑本身也消耗 CPU。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 仅在满足以下条件时用
ForkJoinPool：任务无共享状态、可递归切分、执行时间 > 10ms - 避免在
compute()中调用Thread.sleep()或Object.wait()，这会让整个 worker 线程挂起，影响全局窃取效率 - 默认构造的
ForkJoinPool()使用availableProcessors()作为并行度，但实际应设为Math.min(32, availableProcessors() + 1)，防小核设备过度并发
线程局部变量 ThreadLocal 能规避上下文切换吗
不能。ThreadLocal 是内存隔离机制，不是调度优化手段。它解决的是数据共享冲突问题，和上下文切换无关。滥用 ThreadLocal 反而加重 GC 压力（尤其在线程池中未 remove()），间接拉高 STW 时间，恶化整体响应。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 只在真正需要“每线程一份副本”的场景用，比如事务 ID、用户上下文透传，别用来缓存大对象
- 在线程池环境下，务必在任务结束前调用
threadLocal.remove()，否则可能引发内存泄漏——这是最常被忽略的一点 - 不要用
ThreadLocal<SimpleDateFormat>这类非线程安全对象做缓存，SimpleDateFormat本身已过时，应改用DateTimeFormatter
上下文切换开销从来不是靠“配一个数字”就能解决的。它藏在任务结构里、锁粒度里、I/O 阻塞点里，也藏在你忘了 remove() 的那行 ThreadLocal 后面。
