executors.newsinglethreadexecutor()能保证任务按提交顺序执行，因其采用单线程+无界fifo队列，异常终止后自动重建线程续执，而newfixedthreadpool(1)则不会重建。
Java 线程池**不默认保障任务提交顺序等于执行顺序**，只有在特定配置下才能实现。关键不在“是不是线程池”，而在于“用的是哪种线程池、怎么配参数、怎么提交任务”。
用 newSingleThreadExecutor() 是最直接的保序方式
它内部封装了一个 corePoolSize = 1、maximumPoolSize = 1、workQueue = new LinkedBlockingQueue()（无界）的 ThreadPoolExecutor。
- 所有任务必须排队，唯一工作线程从队首逐个取任务 → 天然 FIFO
- 队列是 LinkedBlockingQueue，插入和取出严格按入队顺序，无重排序风险
- 若当前线程因未捕获异常终止，它会自动重建新线程继续消费队列 → 顺序不中断（这点比 newFixedThreadPool(1) 更可靠）
手动构造 ThreadPoolExecutor 也能保序，但容易踩坑
想自己控制参数时，必须同时满足三个条件：
- corePoolSize 和 maximumPoolSize 都设为 1：杜绝多线程并发执行可能
- workQueue 必须是无界队列（如 LinkedBlockingQueue）或容量足够大：避免任务因队列满被拒绝，导致顺序断裂
- 拒绝策略不能是 AbortPolicy 或 DiscardPolicy：否则第 N+1 个任务直接丢弃或抛异常，后续任务虽按序排队，但逻辑上已断链
例如：new ThreadPoolExecutor(1, 1, 0, TimeUnit.MILLISECONDS, new LinkedBlockingQueue()) 是安全的；而用 ArrayBlockingQueue(1) 就极大概率触发拒绝，破坏顺序。
其他线程池类型基本不保序
除非人为加同步或依赖控制，否则以下情况无法保证提交即执行顺序：
- newFixedThreadPool(n)，n > 1：多个线程并行取任务，谁先抢到谁执行，完全不可预测
- newCachedThreadPool()：动态创建线程，任务可能立刻执行，也可能稍后执行，顺序无保障
- ScheduledThreadPoolExecutor：按延迟/周期调度，执行时间由 schedule 时间决定，不是提交顺序
即使只提交一个任务，也不能反推“它会第一个执行”——因为线程池可能还在初始化、或前序任务尚未结束。
真正影响顺序的，往往是任务自身行为
即便用了单线程池，以下操作也会让“逻辑顺序”失效：
- 任务中启动新线程（
new Thread().start()），并在其中修改共享变量 → 主线程任务看似串行，实际副作用乱序 - 任务调用
Future.cancel(true)强制中断另一个正在运行的任务 → 打断执行流，状态可能不一致 - 任务内调用
System.exit()或触发 JVM 崩溃 → 整个线程池终止，队列清空，顺序彻底丢失
保序是线程池提供的执行模型保障，不是魔法。它只管“谁来取、按什么顺序取”，不管“取到之后你怎么干”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
