Java线程优化核心是匹配任务场景：避免裸建线程，优先使用显式配置的ThreadPoolExecutor；按CPU/IO密集型差异设参；通过异步编排、无锁设计等源头减负。
Java 中线程创建方式与性能优化之间不是“选哪种更高级”，而是“哪种更适合当前任务场景”。直接 new Thread 简单直接，但代价是每次创建/销毁开销大、资源不可控；线程池看似复杂，实则把不确定性收束为可配置、可监控、可复用的确定性行为。真正的权衡，落在任务特征、系统资源与长期维护成本三者的交汇点上。
避免裸建线程：为什么 new Thread 应该是例外而非默认
每次调用 new Thread().start() 都会触发 JVM 创建 OS 级线程、分配栈内存（默认 1MB）、注册调度信息——这些操作在高并发下迅速成为瓶颈。尤其当任务生命周期短、提交频率高（如每秒数百次 HTTP 请求处理），裸线程会导致：
- 频繁 GC 压力（Thread 对象本身需回收）
- 操作系统线程调度争抢加剧，上下文切换耗时飙升
- 无法统一控制最大并发数，容易拖垮系统
除非是极短期、一次性、且明确知道不会高频触发的后台辅助任务（如日志异步刷盘、心跳探测），否则不建议绕过线程池直接建线程。
线程池不是万能胶：选对类型比用上线程池更重要
Executors 提供的快捷工厂方法（如 newFixedThreadPool、newCachedThreadPool）方便入门，但隐藏了关键参数细节，容易误用：
立即学习“Java免费学习笔记（深入）”；
- newFixedThreadPool(n) 使用无界 LinkedBlockingQueue —— 任务积压时内存持续增长，最终 OOM
- newCachedThreadPool() 允许无限创建线程（maximumPoolSize = Integer.MAX_VALUE）—— 突发流量可能瞬间耗尽 CPU 和内存
- newSingleThreadExecutor() 适合串行化任务（如事件顺序写入），但吞吐量天然受限
生产环境推荐显式构造 ThreadPoolExecutor，明确指定 corePoolSize、maximumPoolSize、workQueue（优先选有界队列如 ArrayBlockingQueue）、拒绝策略（如 AbortPolicy 或自定义日志+降级逻辑）。
按任务性质配参：CPU 密集型与 IO 密集型不能混用一套配置
线程池大小不是拍脑袋决定的数字，它必须匹配任务的执行特征：
- CPU 密集型任务（如图像压缩、数值计算）：线程数 ≈ CPU 核心数 + 1。过多线程只会增加切换开销，无法提升吞吐
- IO 密集型任务（如数据库查询、HTTP 调用）：线程数可设为 CPU 核心数 × (1 + 平均等待时间 / 平均 CPU 时间)，实践中常取 2–4 倍核心数，并配合较长时间的 keepAliveTime（如 60 秒）让空闲线程缓存复用
同一应用中若存在两类任务，应隔离使用不同线程池（例如：dbPool、httpPool、computePool），避免慢 IO 任务阻塞快计算任务。
从源头减负：减少线程依赖比优化线程本身更有效
性能优化的最高境界，是让线程少干活、少通信、少等待：
- 用 CompletableFuture 替代显式线程管理异步流程，链式编排 + 默认 ForkJoinPool 复用，代码更简洁、资源更可控
- 用 ThreadLocal 隔离状态，避免 synchronized 或锁竞争（注意及时 remove() 防止内存泄漏）
- 用 ConcurrentHashMap、LongAdder、StampedLock 等 JDK 并发工具替代粗粒度同步
- 优先设计无状态服务，或用不可变对象传递数据，从根源上消除共享变量同步需求
线程只是载体，任务才是本质。把精力放在任务拆分合理性、数据结构选择、锁粒度控制上，往往比调优线程池参数带来更显著的收益。
