newFixedThreadPool在多数可控场景下更安全，因其线程数固定可防暴增；newCachedThreadPool用无界SynchronousQueue，任务突发易致线程无限创建并引发OOM。
ExecutorService 创建线程池时，newFixedThreadPool 和 newCachedThreadPool 哪个更安全？
直接说结论：newFixedThreadPool 在多数可控场景下更安全，newCachedThreadPool 容易因任务突发导致线程数暴增甚至 OutOfMemoryError。
原因在于：newCachedThreadPool 使用无界 SynchronousQueue，一旦提交任务速度 > 执行速度，就会不断创建新线程（理论上无上限），而 JVM 线程栈会持续消耗内存；newFixedThreadPool 虽用 LinkedBlockingQueue（默认无界），但线程数固定，至少不会无限扩线程。
- 生产环境建议用
new ThreadPoolExecutor(...)显式构造，避免隐藏风险 -
newFixedThreadPool(5)实际等价于new ThreadPoolExecutor(5, 5, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue，但队列无界，仍可能 OOM —— 这点常被忽略()) - 若需缓冲任务，应显式传入有界队列，比如
new ArrayBlockingQueue(100)
submit() 和 execute() 的区别不只是返回值
表面看 submit() 返回 Future，execute() 没有返回值，但关键差异在异常处理路径：
-
execute()中抛出的未捕获异常会直接交给Thread.UncaughtExceptionHandler，如果没设置，就打印到 stderr 并静默消失 -
submit()把任务包装成FutureTask，异常会被捕获并“存”进Future，直到你调用get()才抛出ExecutionException（原始异常包在getCause()里） - 所以，用
submit()却从不调用get()，等于把异常藏起来了，线上很难发现
shutdown() 后还能提交任务吗？如何判断线程池真正结束？
shutdown() 只是把线程池状态设为 SHUTDOWN，拒绝新任务，但会继续执行已入队任务；此时再调用 submit() 或 execute() 会立即抛 RejectedExecutionException。
立即学习“Java免费学习笔记（深入）”；
要确认所有任务完成，不能只靠 isTerminated() —— 它只在 shutdown() 后且所有任务结束才返回 true，但你得主动等待：
- 推荐组合：先
shutdown()，再用awaitTermination(long, TimeUnit)等待指定时间 - 若超时返回
false，说明还有活跃任务，可考虑调用shutdownNow()尝试中断（注意：仅对阻塞中的任务有效，比如Thread.sleep()或BlockingQueue.take()） -
shutdownNow()不保证立即停止，它只是发中断信号，具体是否响应由任务自己决定
线程池里的线程名字默认是 pool-1-thread-1，怎么改？
默认名称确实不利于排查问题，尤其多线程池共存时。改名必须在构造时注入自定义 ThreadFactory：
ThreadFactory namedFactory = r -> {
Thread t = new Thread(r);
t.setName("my-app-worker-" + counter.getAndIncrement());
return t;
};
ExecutorService es = new ThreadPoolExecutor(2, 4, 60L, TimeUnit.SECONDS,
new LinkedBlockingQueue<>(100), namedFactory);
注意：ThreadFactory 是线程池唯一能定制线程属性（如 name、daemon、priority）的入口；别试图在任务里用 Thread.currentThread().setName()，那只会改错线程。
线程池复用线程，同一个线程可能执行多个任务，所以名字最好体现线程池用途而非当前任务，否则日志里会看到名字频繁跳变，反而干扰分析。
