背压缺失导致oom的本质是上游生产速度远超下游处理能力且无流量限制，数据在内存中无限堆积直至耗尽堆空间；其根源在于下游未显式调用request(n)、使用不支持背压的操作符或配置无界缓冲，使响应式流退化为“尽力而为”模式。
背压缺失导致的 OOM，本质是上游数据生产速度远超下游处理能力，而系统又没设限，数据在内存中无限堆积，直到耗尽堆空间。这不是偶然故障，而是响应式流设计中一个明确、可预见、必须主动应对的环节。
背压不是自动开启的安全阀
Reactive Streams 规范要求下游通过 request(n) 显式告知上游“我能处理几个元素”，上游只能按此数量发射。Project Reactor 默认遵循该协议，但不等于默认就安全——如果下游没调用 request，或用了不支持背压的操作符，整个链路就退化为“尽力而为”模式，等同于无限制缓冲。
- Flux.create() 中未传入 FluxSink.OverflowStrategy.BACKPRESSURE，而是用了 IGNORE 或 DROP，会绕过背压控制
- publishOn(Schedulers.parallel()) 默认使用无界队列（如 SynchronousQueue 在某些场景下行为异常），若下游慢，消息就在内部缓冲区堆积
- onBackpressureBuffer() 不指定容量，或容量设为 Integer.MAX_VALUE，等于开了个内存黑洞
快速定位是否真由背压缺失引发
别急着改代码，先确认问题根源：
- 加 .log("key-step") 到 Flux 链路关键位置，观察日志里是否出现 onRequest(1)、onRequest(128) 等信号；若全程没有 onRequest，说明下游根本没发起请求
- 检查订阅者：自定义 Subscriber 或 BaseSubscriber 是否在 hookOnSubscribe 中调用了 sink.request(1) 或 sink.request(Long.MAX_VALUE)
- 排查第三方封装：比如某些 Kafka 或 Redis 响应式客户端的 Flux 封装，若内部用 create + sink.next() 但未校验 requestedFromDownstream()，就会无视背压
立即生效的防御性写法
上线服务不能停机重构，优先加一层兜底：
- onBackpressureDrop()：适合埋点、日志、统计类流，数据可丢失，避免阻塞和堆积
- onBackpressureLatest()：适合状态快照类流（如设备在线状态、配置变更通知），只留最新值
- onBackpressureBuffer(1024, BufferOverflowStrategy.DROP_OLDEST)：强制设上限，并指定溢出策略，防止 buffer 满时抛异常
- limitRate(64)：长期更优方案，将上游速率硬限为每批最多 64 个，配合下游处理节奏平滑吞吐
配套必须做的基础配置
单靠操作符不够，还需系统级配合：
- JVM 启动参数加上 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./heap.hprof，OOM 时自动抓现场
- 监控项增加 reactor.buffer.size 和 reactor.pending.requests（需启用 Micrometer + reactor-netty 的指标导出）
- 避免在虚拟线程（Virtual Thread）中滥用 ThreadLocal 存储大对象，否则每个 VT 都持有一份副本，加剧堆压力
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
