直接 new thread() 错在资源开销大且无法复用；应使用 threadpoolexecutor 手动构造线程池，按场景选合适队列与拒绝策略；任务需结果或异常处理时用 submit()，否则可用 execute()；关闭时须 shutdown() 后 awaittermination()，超时再 shutdownnow()。
为什么直接 new Thread() 是错的起点
每次 new Thread() 启动任务，都会创建新线程、分配栈内存、触发上下文切换——资源开销大，且无法复用或统一控制。Executor 框架的核心价值不是“多线程”，而是“可控的并发资源调度”。它把“执行任务”和“管理线程生命周期”解耦，让开发者只关注 Runnable 或 Callable 逻辑。
如何选对 ExecutorService 实现类
Java 提供的静态工厂方法看似方便，但不同场景下行为差异极大：
-
Executors.newFixedThreadPool(n)：适合负载稳定、任务耗时相近的场景；但其内部LinkedBlockingQueue默认无界，任务积压会 OOM -
Executors.newCachedThreadPool()：适合大量短生命周期任务；但空闲线程 60 秒后才回收，突发流量可能创建过多线程，压垮系统 -
Executors.newSingleThreadExecutor()：保证顺序执行，但单点故障风险高，且无法扩展 - 生产环境强烈建议用
new ThreadPoolExecutor(...)手动构造：能精确控制核心线程数、最大线程数、队列类型（如ArrayBlockingQueue限容）、拒绝策略（如AbortPolicy或自定义）
submit() 和 execute() 到底该用哪个
关键区别不在“能不能扔任务”，而在“要不要结果”和“异常处理方式”：
-
execute(Runnable)：只接受Runnable，无返回值，若任务抛出未捕获异常，该异常会直接打印到stderr，且线程可能静默终止 -
submit(Runnable)或submit(Callable)：返回Future，可调用get()获取结果或捕获异常；即使任务抛异常，也封装在ExecutionException中，不会丢失 - 如果任务有业务级失败需要重试/告警，必须用
submit()+ 显式future.get()或future.isDone()检查
关闭线程池时 shutdown() 和 shutdownNow() 的陷阱
不正确关闭会导致任务丢失、线程泄漏或 JVM 无法退出：
立即学习“Java免费学习笔记（深入）”；
-
shutdown()：平滑关闭，不再接收新任务，但会等已提交任务（包括队列中等待的）执行完；需配合awaitTermination()等待完成，否则可能提前退出 -
shutdownNow()：尝试中断所有正在运行的线程，并清空队列返回未执行任务列表；但中断只是“建议”，任务本身必须响应Thread.interrupted()或检查isInterrupted()才会真正停止 - 常见错误：只调
shutdown()就不管了；或在 finally 块里没加awaitTermination(30, TimeUnit.SECONDS)导致主线程结束而子线程还在跑
真正安全的关闭流程往往要三步：调 shutdown() → awaitTermination() 等待 → 超时后调 shutdownNow() 强制清理。
