Java 9的Flow API是Reactive Streams规范的1:1接口映射，仅定义Publisher、Subscriber、Subscription、Processor四个无行为契约接口，不提供默认实现、操作符链、线程调度或背压自动处理，需手动调用onSubscribe()和request()启动流并控制数据节奏。
Java 9 的 Flow API 不是开箱即用的响应式框架，而是一套轻量、标准、无行为的接口契约——它把“谁该做什么”定义清楚，但不替你做任何事。核心价值在于统一背压语义，让发布者和订阅者能安全协商数据节奏。
Flow 四个接口各司其职，但都不带实现
它们全在 java.util.concurrent.Flow 中，是 Reactive Streams 规范的 1:1 映射：
-
Publisher
：只承诺“我能发数据”，不负责调度、不处理背压、不提供操作符；必须等 Subscriber.onSubscribe()被调用后，才可开始交互 -
Subscriber
：必须立刻在 onSubscribe()中保存Subscription并调用request(1)，否则流永远不会启动 -
Subscription：唯一控制背压的手柄，只有
request(long n)和cancel()两个方法；所有数据拉取都必须经此入口，不能提前发、不能漏调 -
Processor
：理论上可做转换或缓冲，但 JDK 没提供默认实现，也无并发保护，自行实现成本高、易出错，实践中极少直接使用
背压不是自动发生的，而是靠 request() 主动驱动
所谓“变量背压”，本质是订阅者动态决定每次要多少数据：
- 调用
subscription.request(1)表示“我现在能处理 1 个”，发布者据此发出最多 1 个元素 - 如果下游处理变慢，可以改调
request(0)暂停，或request(2)加速，甚至cancel()终止 - 若
onNext()后忘记再request()，后续数据就会卡住——这不是 Bug，是规范强制要求的流控纪律
别拿 Flow 当 RxJava 或 Reactor 用
常见误区是把它当成功能完整的响应式库：
立即学习“Java免费学习笔记（深入）”；
- 它没有
map、filter、flatMap等操作符链，需自己封装或借助第三方 - 它不管理线程，默认无异步调度能力；
SubmissionPublisher虽带线程池，但仅用于提交，不保证onNext()执行线程 - 它不处理异常传播、取消传播、资源清理等细节，这些都得由使用者显式编码保障
实际写法：从 SubmissionPublisher + 自定义 Subscriber 入手
这是最常用起步组合：
- 用
SubmissionPublisher作为 Publisher 实现（它已内置线程安全队列和基础背压支持） - Subscriber 中严格遵循三步：收 subscription → 立即 request → 处理 onNext 后再 request
- 注意 try-with-resources 关闭 publisher，避免资源泄漏；同时确保 subscriber 的生命周期可控
Flow API 的意义不在便利性，而在标准化——它让不同响应式库之间有了互通基础，也让 JVM 生态拥有了原生的背压契约。用好它，关键不是写得多，而是每一步都守规矩。
