线程池默认不保证任务执行顺序；严格FIFO需单线程池+无界/足够容量阻塞队列；newSingleThreadExecutor最简单；手动构造时避免ArrayBlockingQueue容量过小和拒绝策略误用；分组有序可用ConcurrentHashMap+单线程池。
线程池默认不保证任务执行顺序
Java 的 ThreadPoolExecutor 本身不维护任务提交顺序与执行顺序的一致性——哪怕你用 newFixedThreadPool(1)，只要任务在运行中被中断、拒绝或线程被复用，就可能出现看似“乱序”的现象。真正能约束顺序的，是任务提交方式 + 队列类型 + 线程数三者共同作用的结果。
关键判断点：如果你需要严格 FIFO（先提交先执行），必须满足两个条件：单线程池 + 无界/有界但不触发拒绝策略的阻塞队列；否则，多线程下天然存在竞争和调度不确定性。
用 newSingleThreadExecutor() 最简单实现顺序执行
这是最直接、副作用最少的方式。它内部封装了一个 FinalizableDelegatedExecutorService 包裹的单线程池，底层队列是 LinkedBlockingQueue（无界），天然 FIFO。
- 适合场景：日志写入、状态机流转、串行化外部 API 调用等对时序敏感且吞吐压力不大的任务
- 注意点：
shutdownNow()可能中断正在执行的任务，若需优雅终止，应配合awaitTermination()和任务自身可中断逻辑 - 不能用于 CPU 密集型长任务，否则会阻塞后续所有任务
自定义单线程池时别踩 ArrayBlockingQueue 容量陷阱
如果不用 newSingleThreadExecutor()，而是手动构造 ThreadPoolExecutor，常见错误是用小容量 ArrayBlockingQueue 却忽略拒绝策略：
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
new ThreadPoolExecutor(
1, 1, 0L, TimeUnit.MILLISECONDS,
new ArrayBlockingQueue<Runnable>(1), // ⚠️ 容量为 1，第 2 个任务就会触发拒绝
new ThreadPoolExecutor.AbortPolicy()
);
此时第 2 个任务提交会直接抛出 RejectedExecutionException，而不是排队等待。正确做法是：
- 用
LinkedBlockingQueue（无界）或设足够大容量的ArrayBlockingQueue - 避免使用
AbortPolicy或DiscardPolicy，改用CallerRunsPolicy（让提交线程自己执行）或自定义策略 - 确认核心线程数和最大线程数都为 1，否则多线程会破坏顺序
想部分有序？用 PriorityBlockingQueue 或分组+单线程池
纯 FIFO 不够用时（比如按优先级、按 key 分组串行），PriorityBlockingQueue 是一个选择，但它不保证同优先级任务的插入顺序，且需实现 Comparable 或传入 Comparator。更稳妥的做法是逻辑分组：
- 对任务打标（如
userId），用ConcurrentHashMap<String, ExecutorService>维护每个 key 对应的单线程池 - 提交时路由到对应池：
executors.get(userId).submit(task) - 注意清理空闲池，避免内存泄漏（可用
ScheduledExecutorService定期扫描 +isTerminated()判断）
这种模式在消息消费、用户行为聚合等场景很常见，但要注意线程池数量膨胀问题——几十万用户不能起几十万个单线程池。
