submit()返回Future支持结果获取与异常捕获，execute()无返回值且异常易被静默吞掉；应显式构建ThreadPoolExecutor并合理配置参数与拒绝策略。
ExecutorService submit() 和 execute() 有什么区别
核心区别在于是否需要返回结果和异常处理方式：submit() 返回 Future，支持获取执行结果、判断完成状态、主动取消任务；execute() 无返回值，不暴露异常（异常会由线程池的未捕获异常处理器处理，容易静默失败）。
- 需要异步获取计算结果（比如调用远程接口后解析 JSON），必须用
submit() - 纯“发个通知”类任务（如日志异步刷盘、埋点上报），
execute()更轻量 -
submit(Runnable)也会返回Future，但get()只返回null，别误以为能拿到业务值 - 若任务抛出未检查异常，
submit()的Future.get()会包装成ExecutionException抛出；execute()的异常默认被吞掉，除非你显式设置了ThreadFactory或UncaughtExceptionHandler
如何正确创建并管理 ThreadPoolExecutor 实例
别直接 new ThreadPoolExecutor，优先用 Executors 工厂方法，但要清楚它们的陷阱。真正可控、可维护的线程池，应该自己构造，并显式传入拒绝策略、队列容量和线程工厂。
-
Executors.newFixedThreadPool(n)底层用的是无界LinkedBlockingQueue，高并发下可能 OOM —— 改用有界队列 + 拒绝策略 -
Executors.newCachedThreadPool()允许创建无限线程，突发流量时可能耗尽系统资源 —— 生产环境禁用 - 推荐写法：
ThreadPoolExecutor executor = new ThreadPoolExecutor( 2, 8, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue<>(100), new ThreadFactoryBuilder().setNameFormat("biz-task-%d").build(), new ThreadPoolExecutor.CallerRunsPolicy() ); - 务必调用
shutdown()（不再接受新任务）或shutdownNow()（尝试中断正在执行的任务），并在 JVM 关闭前等待终止完成，否则可能导致进程无法退出
线程池拒绝策略怎么选
拒绝策略只在队列满 + 核心/最大线程数已用尽时触发，不是“异常兜底”，而是流控决策点。
-
AbortPolicy（默认）：直接抛RejectedExecutionException，适合能快速失败并告警的场景 -
CallerRunsPolicy：让提交任务的线程自己执行该任务 —— 会降低提交速率，天然实现反压，适合后台批处理 -
DiscardPolicy：静默丢弃，慎用；除非你知道丢的是非关键任务（比如低优先级统计） -
DiscardOldestPolicy：丢弃队列头任务，再尝试提交当前任务 —— 适用于任务有时效性（如最新行情覆盖旧行情） - 自定义策略常见做法：记录日志 + 上报监控指标（如 Prometheus counter），而不是只打印堆栈
ForkJoinPool 和普通 ThreadPoolExecutor 什么时候用哪个
ForkJoinPool 是为**分治型递归任务**（如归并排序、树遍历、并行流）优化的，不是通用线程池替代品。
立即学习“Java免费学习笔记（深入）”；
- 任务粒度小、大量嵌套 fork/join、存在 work-stealing 需求 → 用
ForkJoinPool - 任务独立、IO 耗时长、需控制并发数或定制拒绝逻辑 → 用
ThreadPoolExecutor -
CompletableFuture.supplyAsync()默认用的是ForkJoinPool.commonPool()，但 commonPool 不可配置、共享全局，高负载下易互相干扰 —— 建议显式传入自定义Executor - 不要把数据库查询、HTTP 调用这类阻塞操作扔进
ForkJoinPool，会导致工作线程饥饿，拖慢整个 commonPool
