@Async不能直接用于文件IO方法，因其要求方法非private/static/final且须通过Spring代理调用；阻塞式IO会占用线程池，降低吞吐量，正确做法是Controller仅接收并存临时路径，异步任务再读取解析，需配置ThreadPoolTaskExecutor并避免DOM解析大文件。
为什么 @Async 不能直接用在文件 IO 方法上
因为 @Async 要求目标方法必须是 Spring 管理的 Bean 中的**非 private、非 static、非 final** 方法，且调用必须通过 Spring 代理（即不能本类内直接 this.uploadXml(file)）。如果上传逻辑里包含 FileInputStream、Files.readAllBytes() 或 DocumentBuilder.parse() 等阻塞式 IO，虽然能异步启动，但线程池会被长期占用，拖垮吞吐量。
@Async + XML 上传的正确分层姿势
核心是把「接收请求」和「解析处理」彻底拆开：Controller 只做轻量接收并存临时路径，真正耗时的 XML 解析、校验、入库交给异步任务。否则容易触发 java.lang.IllegalStateException: No thread-bound request found（因异步线程无 Web 上下文）或 FileNotFoundException（临时文件被清理）。
- 上传接口返回后，立刻把
MultipartFile写入临时目录（如/tmp/uploads/），生成唯一uploadId - 异步方法签名必须接收「可序列化的参数」——传
String uploadId或Long fileId，而不是MultipartFile或InputStream - 异步方法内部再用
Files.readAllBytes(Paths.get(tempPath))读取，用DocumentBuilderFactory解析，全程不依赖 HTTP 请求上下文
配置线程池避免默认 SimpleAsyncTaskExecutor 拖垮服务
Spring 默认用 SimpleAsyncTaskExecutor（不复用线程），高并发上传时会创建大量线程，OOM 风险极高。必须显式配置 ThreadPoolTaskExecutor：
@Configuration
@EnableAsync
public class AsyncConfig {
<pre class='brush:php;toolbar:false;'>@Bean(name = "xmlUploadExecutor")
public Executor xmlUploadExecutor() {
ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
executor.setCorePoolSize(4);
executor.setMaxPoolSize(10);
executor.setQueueCapacity(50);
executor.setThreadNamePrefix("xml-upload-");
executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
executor.initialize();
return executor;
}}
立即学习“Java免费学习笔记（深入）”；
然后在异步方法上指定执行器：@Async("xmlUploadExecutor")。注意 queueCapacity 要结合 XML 平均大小预估内存占用，避免堆积大量未解析的字节数组。
XML 解析阶段仍需防阻塞：别用 DOM 大文件
如果上传的 XML 可能超 10MB，用 DocumentBuilder.parse()（DOM）会把整个文档加载进内存，异步也救不了——线程卡在 GC 或 OOM。此时必须改用流式解析：
- 小文件（DocumentBuilderFactory +
setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)防 XXE - 大文件（≥5MB）：改用
SAXParser或XMLStreamReader（StAX），边读边处理，内存占用恒定 - 千万别在
@Async方法里写Thread.sleep(5000)模拟处理——这是反模式，会白占线程
临时文件记得加清理逻辑（比如解析成功后 Files.deleteIfExists(path)），否则磁盘迟早写满。异步任务失败时，临时文件就成了孤儿。
