Reactor Java应用中可创建的Publisher与Subscriber数量是否存在上限？

结论：无法通过无限制创建Publisher实现应用扩容 #

Publisher是Reactor中数据流的声明式模板，本身创建成本极低，未订阅的Publisher几乎不占用系统资源。但应用扩容的核心是支撑更多可运行的业务逻辑，所有Publisher最终都需要订阅才会产生实际算力消耗，无限制创建并订阅Publisher只会快速耗尽系统资源，完全达不到扩容目的。

创建Publisher的核心约束条件 #

• 调度器资源约束：异步执行的Publisher都会绑定对应Scheduler调度器，Reactor默认提供的调度器都有明确的资源上限：比如常用的Schedulers.boundedElastic()默认最大线程数为CPU核心数*10，任务队列上限为10万，超出限制后新提交的订阅任务会被直接拒绝，甚至触发线程资源耗尽的异常。自定义调度器的线程数也不能无限制上调，线程上下文切换、线程栈内存的开销会随线程数增长指数级上升。
• 外部依赖资源约束：如果Publisher封装了数据库访问、远程接口调用、中间件操作等IO逻辑，会受限于对应外部依赖的资源上限：比如数据库连接池的连接数上限、HTTP客户端的最大连接数、下游服务的QPS限流阈值等。即使创建上万次请求类Publisher，最终也会被这些外部资源卡住，反而会堆积大量等待任务，增加内存开销甚至触发OOM。
• 内存与GC约束：已订阅的Publisher在运行过程中会产生信号对象、回调上下文、背压缓存队列等内存开销，无限制创建并订阅会导致堆内存占用快速上涨，触发频繁的Full GC，严重时会直接导致进程崩溃。
• 背压规范约束：如果是自定义实现Publisher接口，必须严格遵守Reactive Streams背压规范，需要响应下游的request(n)信号控制发射速率，否则会抛出MissingBackpressureException，导致整个数据流中断。

如果需要做应用扩容，优先通过调整调度器参数、扩容外部依赖资源、增加服务节点水平扩容的方式实现，单纯增加Publisher数量没有任何作用。

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