SingleThreadExecutor 的资源泄漏风险源于任务中未显式关闭 OS 句柄且无界队列导致积压；须用 try-with-resources 或 finally 显式释放、限制队列长度、避免隐式持有外部资源。
SingleThreadExecutor 本身不直接打开本地 OS 句柄，但任务中若隐式持有文件、Socket、数据库连接、图形资源等未显式关闭的对象，又因单线程串行执行 + 无界队列特性导致任务长期积压或阻塞，就会让这些句柄在堆内存中持续存活，无法被 GC 回收，最终触发系统级资源耗尽（如“Too many open files”或“unable to create new native thread”）。
明确任务中所有可能打开 OS 句柄的操作
常见高风险操作包括：
- FileInputStream / FileOutputStream / Files.newInputStream() —— 文件句柄
- Socket / ServerSocket / HttpURLConnection —— 网络套接字
- Connection / PreparedStatement / ResultSet（JDBC）—— 数据库连接与游标
- ImageIO.read() / Graphics2D / PrinterJob —— 图形与打印资源
- ProcessBuilder.start() —— 子进程句柄
只要这些对象未在任务结束前显式 close() 或 try-with-resources 自动释放，就可能随 Runnable 实例一起驻留在 LinkedBlockingQueue 中，而队列不执行、不销毁、不 GC —— 句柄就一直开着。
强制使用 try-with-resources 或 finally 显式释放
禁止在 Runnable 或 Callable 中仅靠 finalize() 或依赖线程退出来清理。必须主动控制生命周期：
- 所有可关闭资源优先用 try-with-resources 包裹，确保异常下也能释放
- 若需跨多步操作（如先 connect 再 query 再 close），把 close() 放在 finally 块，且判空再调用
- 避免在任务中缓存 Connection/Socket 等长生命周期对象；如需复用，应交由连接池管理，而非 ThreadLocal 或实例字段
替换默认的无界队列并启用拒绝策略
Executors.newSingleThreadExecutor() 的真正风险不在“单线程”，而在其背后那个容量为 Integer.MAX_VALUE 的 LinkedBlockingQueue。一旦某个任务卡住（如 socket read timeout 未设、文件锁未释放），后续所有任务排队，连带它们各自打开的句柄全被钉在内存里。
改用显式构造：
- 用 new ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue(100)) 限定队列长度
- 搭配 CallerRunsPolicy：当队列满时，由提交线程自己执行任务，天然形成反压，防止上游无节制提交
- 配合监控：定期检查 getQueue().size() 和 getActiveCount() == 1，持续高位即说明有任务阻塞，需告警介入
避免在任务中引用外部长生命周期对象
尤其警惕通过 this::method、lambda 捕获外部对象（如 Service 实例、配置容器、静态缓存）间接持有句柄资源。例如：
- 错误写法：executor.submit(() -> fileService.process(file)) —— 若 fileService 内部缓存了未关闭的 FileInputStream，就可能泄漏
- 正确做法：将所需数据抽成 final 局部变量，或确保 process() 方法内部完成全部 open–close，不依赖外部状态
- 对必须复用的资源（如格式化器），用 ThreadLocal 封装，但每次用完必须 remove()，否则线程复用时残留句柄
