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 用

常见误区是把它当成功能完整的响应式库：

Gradle 9.8.0

下载

• 它没有 map、filter、flatMap 等操作符链，需自己封装或借助第三方
• 它不管理线程，默认无异步调度能力；SubmissionPublisher 虽带线程池，但仅用于提交，不保证 onNext() 执行线程
• 它不处理异常传播、取消传播、资源清理等细节，这些都得由使用者显式编码保障

实际写法：从 SubmissionPublisher + 自定义 Subscriber 入手

这是最常用起步组合：

• 用 SubmissionPublisher 作为 Publisher 实现（它已内置线程安全队列和基础背压支持）
• Subscriber 中严格遵循三步：收 subscription → 立即 request → 处理 onNext 后再 request
• 注意 try-with-resources 关闭 publisher，避免资源泄漏；同时确保 subscriber 的生命周期可控

Flow API 的意义不在便利性，而在标准化——它让不同响应式库之间有了互通基础，也让 JVM 生态拥有了原生的背压契约。用好它，关键不是写得多，而是每一步都守规矩。

大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！