Spring Integration异步SFTP上传能否用InputStreamResource替代临时文件

为什么企业场景普遍不推荐直接用MultipartFile封装的InputStreamResource做SFTP上传？ #

很多人对这个问题的认知有偏差：InputStream本身确实不会把全量数据加载到内存，但这不是InputStreamResource可以直接用在SFTP异步链路的理由，它的两个核心适配缺陷才是不被推荐的根本原因：

• 第一是生命周期错配：Spring MVC的单次HTTP请求处理完成后，会直接回收请求上下文关联的MultipartFile底层资源，强制关闭对应的输入流。如果把这个流封装成Resource丢给@Async的异步线程处理，往往HTTP线程刚返回响应，异步处理才刚启动，一读流就直接抛Stream closed的IO异常。
• 第二是SFTP组件的适配缺陷：Spring Integration的SFTP出站组件在传输文件前，需要拿到资源的准确文件大小来构造SFTP协议的传输帧。而InputStreamResource本身没有固定的文件长度属性，没法通过常规方法快速取值，只能把全量流读到内存/本地缓存才能算出长度——这才是大家提到的"大文件全量缓冲到内存"风险的来源，和InputStream本身的特性没有关系。

封装后的InputStreamResource会在文件上传完成后自动关闭吗？ #

分两种实际场景判断，没有绝对的"是"或"否"：

• 如果是在同一个请求线程内同步执行上传逻辑，Spring Integration的资源处理组件会在读完流后主动调用close()方法释放输入流，这部分的兜底逻辑是可靠的。
• 如果是跨线程把流封装成Resource丢给异步任务，没有额外加资源管控逻辑，根本走不到自动关闭的流程：流可能会在请求回收阶段就被框架强制关闭，异步任务半路就直接中断了。

技术语境中的"大文件"到底指多大尺寸？ #

这个"大"从来没有固定的GB级阈值，是完全相对应用的资源配额来定义的：

• 当单文件大小达到应用单请求允许的内存占用阈值时，就算是"大文件"。比如你给Spring Boot配置的Multipart上传阈值是1MB，超过1MB框架就会自动把文件写本地临时文件，这时候哪怕后续传10MB的文件，也不会占用额外堆内存。
• 大家普遍提到的高风险大文件场景，是指单文件大小超过JVM堆内存1%的场景：比如JVM总堆内存1G，单文件200MB，一旦触发全量流读内存算长度的逻辑，几个并发请求就会直接触发OOM。反过来如果单文件只有2-5MB，哪怕全量读到内存，对JVM来说几乎没有资源压力。

当前业务仅上传2-5MB文件的情况下，有必要改成临时文件模式吗？ #

完全可以根据实际情况决策，不用盲目跟风抄企业场景的实现：

• 如果你当前的实现已经稳定运行，从来没出现过偶发的流中断、上传失败问题，且后续3-6个月内业务没有把单文件上传上限提升到50MB以上的规划，完全不需要改动现有逻辑。
• 如果你碰到过偶发的上传异常，或者后续业务大概率要提升文件大小上限，改成基于File#createTempFile的模式是最稳妥的选择：
  • 具体操作是在HTTP接口收到MultipartFile后，第一时间把文件内容写入独立的临时文件，将临时文件对应的FileSystemResource丢给异步SFTP上传方法
  • 上传流程结束后，无论成功还是失败，都在finally块中完成临时文件的清理
  • 这种模式完全和HTTP请求上下文解耦，SFTP组件可以直接拿到准确的文件大小，不需要全量读流计算长度，就算后续传1G以上的大文件也不会产生过高的内存占用。

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