线上生产大文件下载导致 OOM，顺藤摸瓜拿下

青旅半醒 2024-05-01 16:29 69阅读 0赞

上周遇到了生产环境 OOM 的问题，找了一番之后基本定位了是大文件下载导致的问题，于是在网上搜罗了一番文章，下面分享一篇优质的解决方案，整个排查思路非常清晰，小白可以直接对照着来排查。

## 1.事故发生 ##

上周五下午运营人员反馈，笔者所负责的后台系统从 14 点以后就卡卡的，虽然页面能够正常加载，但是一直处于数据加载中，数据也提交不了，怀疑笔者的系统有BUG，当听到运营人员的反馈我的第一反应是这不可能啊，这么简单的一个后台系统，还能出事故？

## 2.处理流程 ##

1.  摘除其中一台服务器用于保留现场，其他服务器先重启，保证系统可用。
2.  下载GC日志，系统dump文件用于分析

## 3.GC log分析 ##

系统启动参数，JVM内存分配：-Xmx4096m -Xms4096m -Xmn2560m

观察日志可知系统每隔 40S 发生一次 Full GC，耗时 200 毫秒，**回收以后系统老年代占用也不大，才 15M，但是新生代回收完还有 2 个 G。**

有点不可思议，竟然不是老年代塞满了数据，而是新生代塞满了数据。

**初步推测是新生代数据要晋升到老年代，结果放不进去而引起的 Full GC。**

![图片][e68a30a41b697e60dac456bc3f065e55.png]

## 4.使用 MAT 对 Dump 文件进行分析 ##

通过总图可以看出来目前系统内存占用超过 2 个 G:

![图片][04fa79c01feeeec078c22589bd016277.png]

点击 Histogram 进行进一步分析，看出系统中占用最多的是byte\[\]

![图片][8ebc91bcede6acdba4755f1c54737228.png]

点击List Objects进入income引用统计界面

![图片][8ebc91bcede6acdba4755f1c54737228.png]

层层点开，发现byte\[\]被 ResponseEntity 对象所引用，且数量不小

![图片][6e422780ccb54f2752fe025cb3bfb5a6.png]

## 5.翻阅代码 ##

1）在系统中找到唯一ResponseEntity有关的代码

![图片][b534be5cd3cf96bc5577f4fee91a24e1.png]

2）这代码看似没什么问题啊，这不是很正常的文件下载么？？？我去看看用户下载了啥，跑到目录文件查看一下下。

![图片][abb0c39493430fe850c8967ce945923f.png]

我的天，用户下载的是一份2.4G的大文件，代码中FileUtils.readFileToByteArray(file) 的方式是把整个文件读取到内存再输出流里写入，此时内存不够分配，又塞不进老年代，只能是 Full GC 了。

3）成功破案了，用户下载了一份大文件，文件先加载到内存才往外写，抹泪。。。。

## 6.解决方案 ##

*  **使用FileSystemResource**

@GetMapping("/down")
    public ResponseEntity download(@RequestParam("uri") String uri) throws IOException {
      File file = new File(uri);
      if (!file.isFile()) {
       throw new ServiceException("文件不存在");
      }
    
      String filename = FilenameUtils.getName(uri);
      HttpHeaders headers = new HttpHeaders();
      headers.add("Content-Disposition", "attachment;filename=" + URLEncoder.encode(filename, "UTF-8"));
      HttpStatus status = HttpStatus.OK;
      return new ResponseEntity<>(new FileSystemResource(file), headers, status);
    }

*  **使用缓存流，边读边写**

@GetMapping("/down")
    public void download(@RequestParam("uri") String uri, HttpServletResponse response) throws IOException {
     File file = new File(uri);
      if (!file.isFile()) {
       throw new ServiceException("文件不存在");
      }
    
      String filename = FilenameUtils.getName(uri);
      response.setHeader("Content-Disposition", "attachment;filename=" + URLEncoder.encode(filename, "UTF-8"));
    
      try (FileInputStream fileInputStream = new FileInputStream(file);
        BufferedInputStream bufferedInputStream = new BufferedInputStream(fileInputStream);
        BufferedOutputStream bufferedOutputStream = new BufferedOutputStream(response.getOutputStream())) {
        FileCopyUtils.copy(bufferedInputStream, bufferedOutputStream);
      } finally {
       // 使用的是try-with-resources
    
      }
    }

*  **文件存储到 oss 或者是七牛云**

将文件存储到 oss 或者是七牛云，绕过服务器下载

[e68a30a41b697e60dac456bc3f065e55.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/13f7182cdbe645799dd0d3bcdb987e37.png
[04fa79c01feeeec078c22589bd016277.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/2fbdd55f55754ff5b2a492d5e685e2bd.png
[8ebc91bcede6acdba4755f1c54737228.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/0026ee6792484ec1bcb623deae15c40d.png
[6e422780ccb54f2752fe025cb3bfb5a6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/cfef4589baef42b9b7be1ddf2008eafc.png
[b534be5cd3cf96bc5577f4fee91a24e1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/e4f464e6cf584ef4a86f840deabc49ba.png
[abb0c39493430fe850c8967ce945923f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/a2385dec66b043ae88e3e26f02ccd35e.png