Executors.newSingleThreadExecutor() 内存风险源于其默认的无界 LinkedBlockingQueue，任务积压会持续占用堆内存直至 OOM；应显式构造 ThreadPoolExecutor 限定队列容量、选用 CallerRunsPolicy 拒绝策略，并添加队列水位监控。
直接用 Executors.newSingleThreadExecutor() 很方便，但它的内存风险很实在——任务积压会悄无声息吃光堆内存。核心问题不在“单线程”，而在于它背后那个无界队列：LinkedBlockingQueue（默认容量为 Integer.MAX_VALUE）。只要提交速度 > 执行速度，任务就持续堆积，不报错、不拒绝、只等OOM。
为什么无界队列在单线程池里特别危险
单线程池只有一个工作线程，意味着所有任务必须串行执行。一旦某个任务执行慢（比如网络超时、IO阻塞、计算耗时），后续所有任务都会排队等待。而队列不限制长度，JVM只能不断分配对象存任务（尤其是带大对象引用的 Runnable 或 FutureTask），最终触发 OutOfMemoryError: GC overhead limit exceeded。
- 典型场景：日志异步刷盘时某次磁盘写满 → 后续百万条日志任务全卡在队列里
- 隐蔽表现：服务CPU不高、线程数稳定，但堆内存缓慢上涨，Full GC 频次飙升
- 和
newFixedThreadPool(1)表面一样，但前者被FinalizableDelegatedExecutorService封装，无法直接调用setCorePoolSize等方法调整，更难干预
三步实战改造：从“默认创建”到“可控积压”
不用弃用 newSingleThreadExecutor，关键是替换掉那个危险的无界队列。
-
第一步：显式构造 ThreadPoolExecutor，绕过 Executors 工厂限制
用new ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<runnable>(1000))</runnable>替代。把队列容量从“无限”收窄为合理上限（如 1000），超出即触发拒绝策略 -
第二步：选对拒绝策略，避免静默失败
不要依赖默认的AbortPolicy（抛异常可能被吞）；推荐CallerRunsPolicy：当队列满时，由提交任务的线程自己执行该任务。这能自然反压，降低提交速率，给系统喘息机会 -
第三步：加轻量监控，早于OOM发现积压
定期调用getQueue().size()和getActiveCount()，当队列长度持续 > 容量 80% 且活跃线程为 1 时，记录告警日志或触发降级（如丢弃低优先级任务）
替代方案：什么情况下不该用单线程池
如果业务本质要求强顺序，但又不能容忍任何积压风险，可考虑更健壮的解耦设计：
- 用带持久化的消息队列（如 Kafka、RocketMQ）替代内存队列，天然支持背压、重试、监控和积压告警
- 若只是避免并发修改共享状态，改用
ReentrantLock+ 普通线程，或CompletableFuture链式编排，去掉线程池这一层 - 对日志、埋点等非关键路径，直接同步执行（牺牲一点吞吐，换稳定性），比扛着OOM风险更划算
本质上，newSingleThreadExecutor 不是错，错在把它当成“自动兜底”的黑盒。看清它用的是无界队列、单线程执行、默认拒绝策略这三点，再针对性加固，就能在保序前提下守住内存底线。
