Spring Boot更新Java依赖后上传CSV文件触发Java堆OOM错误

从堆栈栈帧可以直接排除「业务代码处理上传文件占内存」的可能性：
错误触发在Http11OutputBuffer初始化阶段，属于Tomcat为新进入的HTTP连接创建处理对象的前置流程，此时你的CSV上传接口的业务代码还完全没开始执行。也就是说，堆内存从服务启动开始就已经处于濒临耗尽的状态，连最基础的Tomcat连接处理器都分配不出来，和上传的文件大小没有直接关系。
结合你描述的「仅更新依赖就从「第二个文件才OOM」变成「第一个请求就OOM」」的特征，诱因基本集中在两类：

1. 依赖版本升级引发的常驻内存占比抬升 #

更新依赖过程中，如果没有锁定Spring Boot、Spring Cloud的兼容版本，很容易出现依赖树冲突、传递依赖版本错配，常见的抬升内存占用的场景包括：

• 新版Spring Cloud Sleuth/Zipkin、OpenFeign、Hystrix组件默认开启更多采样、缓存机制，常驻内存的元数据占比大幅提升
• 升级过程中内嵌Tomcat的版本被传递依赖替换，新版Tomcat调整了默认的连接缓冲大小、最大连接数配置，单连接占用的内存比旧版本高
• 依赖树中引入了不必要的传递包，启动时加载了大量无用类，挤占堆空间

2. 堆内存配置和当前组件负载不匹配 #

Tomcat创建每个HTTP连接处理器时，默认会分配responseBufferSize + requestBufferSize大小的堆内ByteBuffer，默认值约24KB/连接。如果服务启动时配置的最大堆内存本身就偏小，叠加各组件的启动常驻内存，很容易在接第一个请求时就把剩余内存占满。 #

• 先核对服务启动时的实际堆参数和实时内存占用
  查看启动日志里的-Xmx配置值，通过Actuator端点查看堆内存已用、空闲空间，确认服务刚启动、未接任何业务请求时的剩余堆空间。如果剩余值低于100MB，基本可以确定是启动阶段的常驻内存就已经占满，根本轮不到业务代码执行。
• 梳理升级后的依赖树，排查版本错配
  执行Maven命令输出完整依赖树，对比升级前后的版本差异：
  mvn dependency:tree -Dverbose > deps.txt
  重点核对三类问题：
  • Spring Boot和Spring Cloud的版本是否匹配官方兼容规则，杜绝跨大版本混装
  • 内嵌Tomcat的实际版本是否和升级前一致
  • 是否引入了非必要的传递依赖，造成不必要的类加载
• 调整Tomcat默认配置，降低单连接内存占用
  在application.yml中配置：

  server:
    tomcat:
      max-threads: 200 # 按实际业务QPS调整，不盲目设大
      max-connections: 1000 # 适当降低最大连接数，减少待分配的处理器对象
      accept-count: 100
      max-swallow-size: 2MB # 限制上传内容的堆内缓存大小，避免大文件全量读到堆里
      connection-timeout: 5000
  

• 修正文件上传的临时存储配置
  即使解决了Tomcat层面的内存问题，10~15MB的CSV如果被Spring Boot默认的Multipart解析器全量读到堆里，仍可能触发OOM。需要开启文件的磁盘临时缓存，避免内容存放在内存中：

  spring:
    servlet:
      multipart:
        max-file-size: 20MB
        max-request-size: 20MB
        location: /tmp/tomcat-upload # 指定临时文件落盘目录
        file-size-threshold: 0 # 无论文件大小，都直接写磁盘，不占用堆内存
  

• 校验JVM堆参数
  完成上述配置调整后，如果启动状态下的空闲堆内存仍低于业务安全阈值，适当调大-Xmx配置，保证启动阶段的常驻内存占用不超过最大堆内存的70%，给业务请求和临时对象留出足够空间。

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