Spring RestController接收大字节数组内存不足，求优化方案

你的问题核心是一次性把整个请求体加载到byte[]数组里，导致内存占用过高——当请求体很大时，这种方式会直接把所有数据都堆到内存里，很容易引发OOM或者内存紧张的问题。接下来我会一步步分析问题，然后给出更优的实现方案。

当前实现的问题分析 #

先看你现在的代码：

// Controller
@RequestMapping(value = "person", method = RequestMethod.POST)
public void postPerson(@RequestBody() byte[] data) { PersonService.postPerson(data); }

// Splitter
public void splitFile(byte[] data, Consumer<byte[]> segmentConsumer){
 try {
 XMLInputFactory xmlif = XMLInputFactory.newInstance();
 final XMLEventReader reader = xmlif.createXMLEventReader(new ByteArrayInputStream(data), StandardCharsets.ISO_8859_1.name());
 // ... 后续XML解析逻辑
 } catch (Exception e) {
 throw new RuntimeException(e);
 }
}

这里的关键问题有两个：

• @RequestBody byte[] data会让Spring把整个请求体一次性读取到内存中，生成一个完整的byte数组，大文件场景下内存直接爆炸。
• 后续把byte[]转成ByteArrayInputStream再做XML解析，本质还是在内存里处理全量数据，没有真正做到流式处理。

优化方案：流式读取请求体 + 流式XML解析 #

我们的目标是不把整个请求体加载到内存，而是边读边解析，分块处理，具体可以从Controller到Service层全链路改成流式处理：

1. 修改Controller：直接读取请求流 #

Spring允许我们直接获取HttpServletRequest的输入流，这样就能避免一次性加载全量请求体到内存：

@RequestMapping(value = "person", method = RequestMethod.POST)
public void postPerson(HttpServletRequest request) throws IOException {
    // 用try-with-resources自动关闭流，避免资源泄漏
    try (InputStream inputStream = request.getInputStream()) {
        PersonService.postPerson(inputStream);
    }
}

2. 修改Service和Splitter：基于输入流做流式XML解析 #

不再接收byte[]，而是接收InputStream，直接用XMLEventReader读取流数据，边读边处理，不需要把整个XML加载到内存：

// Service
public void postPerson(InputStream dataStream) {
    Splitter sp = new Splitter();
    sp.splitFile(dataStream, (bytes) -> {
        // 这里处理每个分块的逻辑，比如写入文件或者发送到其他服务
    });
}

// Interface
public interface Splitter {
    void splitFile(InputStream dataStream, Consumer<byte[]> segmentConsumer);
}

// Splitter实现类
public void splitFile(InputStream dataStream, Consumer<byte[]> segmentConsumer){
    try {
        XMLInputFactory xmlif = XMLInputFactory.newInstance();
        // 直接从输入流创建XMLEventReader，流式解析XML
        final XMLEventReader reader = xmlif.createXMLEventReader(dataStream, StandardCharsets.ISO_8859_1.name());
        
        String fileHeader = "";
        StringBuilder aggregatedSegments = new StringBuilder();
        int segmentCount = 0;
        
        while (reader.hasNext()) {
            final XMLEvent event = reader.nextEvent();
            
            if (isStartElement(event, "status")) {
                fileHeader = buildHeader(event, reader);
            }
            
            if (isStartElement(event, "person")) {
                segmentCount++;
                aggregatedSegments.append(buildSegment(event, reader));
                
                if (maxNrOfElementsInSegment == segmentCount) {
                    // 把当前聚合的片段转成byte数组，交给consumer处理
                    segmentConsumer.accept(buildFile(fileHeader, aggregatedSegments).getBytes(StandardCharsets.ISO_8859_1));
                    aggregatedSegments.setLength(0); // 清空StringBuilder，避免频繁创建新对象
                    segmentCount = 0;
                }
            }
        }
        
        // 处理最后剩余的片段
        if (segmentCount != 0) {
            segmentConsumer.accept(buildFile(fileHeader, aggregatedSegments).getBytes(StandardCharsets.ISO_8859_1));
        }
        
    } catch (Exception e) {
        throw new RuntimeException(e);
    }
}

这里的关键改进点：

• 直接使用请求的输入流创建XMLEventReader，XML解析器会按需从流里读取数据，不会一次性加载整个XML到内存。
• 把aggregatedSegments = new StringBuilder()改成aggregatedSegments.setLength(0)，减少对象创建的开销。
• 全程没有把整个请求体转换成byte[]，内存占用会大幅降低，只保留当前解析和聚合的部分数据。

3. 额外优化建议 #

• 如果你的XML结构比较复杂，或者需要更高效的流式解析，可以深入挖掘StAX API的特性（你现在已经在用的XMLEventReader就属于StAX），或者使用成熟的XML流式解析工具，减少自己处理事件的繁琐。
• 如果分块处理后的byte[]仍然较大，可以考虑直接把聚合的字符串写入输出流（比如文件流），而不是转成byte[]交给consumer，进一步减少内存占用。
• 不要依赖调整Spring的请求体最大限制来解决问题，这只是治标，流式处理才是治本的方案。

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