已通过AWS SNS/SQS异步触发的导出方法为何需单线程池解决OOM？

我有一个内存密集型导出函数，需要从MongoDB中获取超过100万条数据并写入Excel文件。该导出方法已通过AWS SNS/SQS实现异步触发，但不使用SingleThreadPool时总会出现OOM（内存溢出）问题。

代码如下：

@Transactional
@SqsListener("${sqs-example}")
public void exportData(String json) throws IOException {
    LOGGER.info("Export: {}", json);
    ExportPayload exportPayload = objectMapper.readValue(json, ExportPayload.class);
    try {
        TenantContext.setTenant(exportPayload.getTenant());
        exportService.export(exportPayload.getExportId(), exportPayload.getTenant());
    } finally {
        TenantContext.clear();
    }
}

其中exportFunc函数负责将从MongoDB获取的数据写入Excel文件。不使用SingleThreadPool时，大约处理13万行数据后就会出现OOM问题；但采用如下方式实现后，可轻松处理超过100万行数据：

public void export(String exportId, Long tenantId) {
        ExecutorService es = Executors.newSingleThreadExecutor();
        if (oExport.isPresent()) {
            try {
                es.submit(() -> {
                    try {
                        TenantContext.setTenant(tenantId);
                        exportFunc();
                    } finally {
                        TenantContext.clear();
                    }
                });
            } finally {
                es.shutdown();
            }

        } else {
            LOGGER.error("No export found by id: {}", exportId);
        }
    }

我认为导出任务在程序接收消息时就已触发，且已运行在独立线程中，为何singleThreadExecutor能解决此场景下的OOM问题？

分析与解答 #

核心原因和线程所属的线程池内存特性、事务上下文的内存占用这两点有关：

• SQS监听器线程池的长期存活特性导致内存残留
  默认Spring Cloud AWS的SQS监听器使用自带线程池，其中的核心线程会长期存活。直接在监听器线程执行exportFunc时，导出产生的大对象（如Excel缓存、MongoDB结果集）会附着在这个长期线程上，即使任务完成，这些对象也可能因线程未销毁无法被GC及时回收，积累到一定量就触发OOM。而newSingleThreadExecutor创建的是临时线程，任务结束后线程立即销毁，关联的大对象失去引用，能被GC快速清理，无内存残留。

• @Transactional注解的上下文内存泄漏风险
  exportData方法带有@Transactional，会在当前线程创建事务上下文（如数据库连接、事务状态）。如果直接在监听器线程执行导出，事务上下文与线程绑定，即使导出完成，事务资源可能未及时释放，叠加大对象内存占用加速OOM。用单线程池异步执行后，事务上下文绑定在临时线程上，线程销毁时事务资源被彻底释放，避免内存泄漏。

• 单任务执行避免内存叠加
  监听器线程池默认支持并发消费，多个导出任务同时运行会导致内存占用叠加，快速突破内存上限。单线程池保证同一时间仅一个导出任务执行，内存占用始终控制在单个任务的峰值内，不会出现多任务内存叠加的情况。

内容的提问来源于stack exchange，提问作者Coding_Rabbit