java高性能数据泵核心是consumer主动拉取+背压控制：publisher按request(n)响应，subscriber动态调节请求量；用submissionpublisher配线程池与缓冲限流；processor实现多阶段背压传导。
Java中构建高性能数据泵，关键不是把数据“推”出去，而是让Consumer主动“拉”数据，并通过背压机制控制节奏。Reactive Streams本身不提供开箱即用的“泵”，但它的设计思想——异步、非阻塞、有界缓冲、按需请求——正是数据泵的核心逻辑。
明确Publisher与Subscriber的角色边界
数据泵本质是一个协调者：上游是数据源（Publisher），下游是处理单元（Subscriber）。不能让Publisher盲目发射，也不能让Subscriber被动接收。
- Publisher只负责响应request(n)，每次最多发n个元素，发完等待下一次request
- Subscriber在onSubscribe中立即调用request(1)或request(16)，启动首次拉取；后续在onNext里根据自身负载决定下次request多少
- 避免在Subscriber中调用request(Long.MAX_VALUE)，这等于放弃背压，退化为无界推送
用SubmissionPublisher实现可控发布端
SubmissionPublisher是JDK 9内置的轻量级Publisher实现，但默认配置不适合生产级数据泵，必须显式约束：
- 传入专用线程池，避免挤占ForkJoinPool.commonPool()，例如：Executors.newFixedThreadPool(4, r -> { Thread t = new Thread(r); t.setDaemon(true); return t; })
- 设置maxBufferCapacity为合理值（如256或1024），它代表每个Subscriber私有缓冲区上限，不是全局队列大小
- 若下游处理偶发延迟，可配合onBufferOverflow策略丢弃旧数据或记录告警，防止内存堆积
Subscriber端实现弹性消费逻辑
真正的“泵感”来自Subscriber对request节奏的动态调节。例如一个日志转发Consumer：
- 初始化时request(32)，建立基础吞吐
- 每次onNext后检查本地队列长度、网络写入延迟、上一周期处理耗时
- 若连续两次处理超100ms，下次request减半；若连续三次低于20ms，可逐步增加request量
- 遇到异常（如网络断开）时调用subscription.cancel()，停止拉取，避免无效积压
用Processor桥接多个阶段形成链式泵
单级泵能力有限，真实场景常需“解析→过滤→转换→投递”多阶段流水线。此时用Processor最自然：
- Processor同时实现Publisher和Subscriber接口，天然适合作为中间节点
- 上游Subscriber调用它的request(n)，它作为下游Publisher再向更下游request(n)，形成背压传导
- 推荐使用Project Reactor的FluxProcessor或自定义Processor，避免手动管理Subscription状态出错
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
