应使用显式配置的 ThreadPoolExecutor 替代 new Thread() 和 Executors 快捷方法，按任务类型（CPU/I/O/突发）差异化设置参数，采用有界队列与合理拒绝策略，并加强监控、命名与生命周期管理。
直接 new Thread() 启动线程看似简单，但会绕过资源管控，导致线程无序膨胀、内存不可控、CPU 调度失衡。优化资源分配逻辑的关键，不是“怎么创建线程”，而是“让线程的生命周期受控、复用、可度量”——这正是线程池设计的核心目标。
避免裸创建，统一走线程池入口
所有业务任务应通过 ExecutorService 提交，而非 new Thread().start()。这样系统才能对线程数量、任务排队、拒绝行为进行集中干预。
- 禁止使用 Executors.newFixedThreadPool() 等快捷方法：它们底层采用无界队列（如 LinkedBlockingQueue）或无限制线程数（如 CachedThreadPool），在流量突增时极易触发 OOM；
- 强制使用 ThreadPoolExecutor 构造器：显式传入 corePoolSize、maximumPoolSize、workQueue、handler 等参数，把资源边界写死在代码里；
- 为不同业务域隔离线程池：例如 IO 密集型接口用独立池（偏大核心数 + 有界队列），定时任务用 ScheduledThreadPoolExecutor，避免相互抢占资源。
按任务类型动态匹配线程池参数
资源分配不能“一刀切”，需结合任务特征反推合理配置：
- CPU 密集型任务（如加解密、图像处理）：核心线程数 ≈ CPU 核心数（Runtime.getRuntime().availableProcessors()），keepAliveTime 可设为 0，避免空闲线程占用资源；
- I/O 密集型任务（如远程调用、文件读写）：核心线程数可设为 CPU 核心数 × (1 + 平均等待时间 / 平均计算时间)，通常取 2–4 倍，配合较长的 keepAliveTime 以复用线程；
- 突发性短任务（如日志异步刷盘）：选用 SynchronousQueue + 较高 maximumPoolSize，允许快速扩容，但必须配 RejectHandler（如 DiscardPolicy 或 CallerRunsPolicy）防止雪崩。
引入队列与拒绝策略的资源守门机制
任务队列不是缓冲区，而是资源调节阀；拒绝策略不是兜底逻辑，而是主动降级信号：
立即学习“Java免费学习笔记（深入）”；
- 优先选用有界队列（如 ArrayBlockingQueue）：明确最大积压任务数，防止内存无限增长；
- 拒绝策略按业务敏感度选择：关键任务用 CallerRunsPolicy（由提交线程自己执行，自然限流）；非关键任务用 DiscardOldestPolicy（丢最老任务）或自定义日志告警策略；
- 监控队列长度与活跃线程数：当 queue.size() 持续 > 队列容量 70% 或 activeCount == maximumPoolSize 时，说明资源已饱和，需触发告警或自动扩缩容。
生命周期与可观测性闭环
资源分配有效性的验证，依赖于可关闭、可统计、可追踪：
- 线程池必须显式 shutdown() 或 shutdownNow()，避免 JVM 退出前线程残留；
- 通过 ThreadPoolExecutor 的 getActiveCount()、getCompletedTaskCount()、getQueue().size() 等方法暴露指标，接入 Prometheus 或日志埋点；
- 为线程命名（通过 ThreadFactory）：例如 “order-processor-pool-%d”，便于在堆栈、JFR、Arthas 中快速定位归属；
- 关键业务线程池建议包装为 Spring Bean，利用 @PreDestroy 注解确保优雅关闭。
