首先得明确一个核心点：Spring Boot 1.5.x版本并不原生支持Spring WebFlux——WebFlux是从Spring Boot 2.x才正式成为一等公民的，你在1.5.1里强行引入WebFlux Starter，本身就存在很多兼容性隐患，这很可能是OOM问题的根源之一。结合你的场景（处理大对象POST请求），我给你分步骤梳理解决方案：

一、先解决版本兼容性问题（优先级最高） #

• 强烈建议升级到Spring Boot 2.x + 匹配的Spring Cloud版本：比如Spring Boot 2.1.x对应Spring Cloud Greenwich，2.2.x对应Hoxton。WebFlux在2.x版本中经过了充分测试，响应式流式处理的特性才能正常发挥，而且1.5.x版本早已停止官方维护，后续遇到问题很难获得支持。
• 如果暂时无法升级，要确保WebFlux Starter的版本和Spring Boot 1.5.x严格匹配（比如用spring-boot-starter-webflux的1.5.x预览版），但即使这样，也不建议在生产环境使用，因为很多响应式特性会出现异常。

二、优化大对象的处理逻辑（治标又治本） #

不管升不升级版本，直接把大对象一次性加载到内存处理都是OOM的高危操作，WebFlux的优势就是流式处理，你得利用这个特性：

1. 流式读取请求体，避免一次性加载 #

不要直接用@RequestBody Mono<YourLargeObject>绑定整个对象，而是直接处理请求的数据流，分块读取：

@PostMapping("/save-or-update")
public Mono<Void> handleLargeObject(ServerHttpRequest request) {
    // 分块读取请求体数据
    return request.getBody()
            .flatMap(dataBuffer -> {
                // 把每块数据写入数据库（用流式API）
                return writeChunkToDatabase(dataBuffer.asInputStream());
            })
            .then(); // 所有块处理完成后返回空响应
}

对应的数据库操作也要用流式API，比如JDBC的PreparedStatement.setBinaryStream()，或者如果升级到2.x，用Spring Data R2DBC这类响应式数据库驱动，确保数据不会在内存中堆积。

2. 调整JVM内存参数（临时缓解） #

如果需要临时应急，可以增大JVM堆内存，比如启动参数设置：

-Xmx4g -Xms2g -XX:+UseG1GC

同时开启GC日志来分析内存占用情况：

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:./gc.log

通过GC日志可以判断是对象无法回收（内存泄漏）还是单纯内存不足，方便后续定位。

3. 优化JSON序列化/反序列化 #

如果你的大对象是JSON格式，默认的Jackson会一次性把整个JSON解析成对象存到内存里，你可以改用流式解析：

@PostMapping("/save-or-update")
public Mono<Void> handleLargeJson(ServerHttpRequest request) {
    return request.getBody()
            .map(DataBuffer::asInputStream)
            .flatMap(inputStream -> {
                try (JsonParser parser = new ObjectMapper().createParser(inputStream)) {
                    // 逐个解析JSON节点，避免加载整个对象
                    while (parser.nextToken() != JsonToken.END_OBJECT) {
                        String fieldName = parser.getCurrentName();
                        parser.nextToken();
                        // 按需处理每个字段
                        processField(fieldName, parser);
                    }
                } catch (IOException e) {
                    return Mono.error(new RuntimeException("解析大JSON失败", e));
                }
                return Mono.empty();
            })
            .then();
}

三、排查Eureka Client的潜在影响 #

虽然OOM出现在WebFlux处理请求时，但也要检查Eureka Client的配置是否有内存泄漏：

• 用JProfiler、VisualVM这类工具生成堆内存快照，查看哪些对象占用了大量内存，比如Eureka的实例缓存、心跳相关的对象是否异常堆积。
• 调整Eureka Client的缓存刷新频率（eureka.client.cache-refresh-interval-ms），如果服务实例过多，适当增大间隔减少内存占用。

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