posts
这里是全站文章的归档入口，下面是按时间倒序排列的全部文章。若想按主题浏览，请从首页的专题分类进入。
讲清 subscribeOn（决定订阅与 request 在哪个调度器上发生）与 publishOn（用队列 + WIP 把下游信号搬到另一个调度器）的语义差异，手写两个操作符并用三个线程归属实验验证。重点纠正「多次 subscribeOn 只有第一个生效」「publishOn 让计算并行」「subscribeOn 放末尾无效」三个常见误解。
从零手写三个核心操作符——MapOperator、FilterOperator、TakeOperator——说明「操作符返回新 Publisher」的装饰器模式、request 信号的累减与转发、cancel 向上游的传播链，以及 take(N) 在达到数量后主动 cancel 上游的实现细节。每段代码都配以运行输出与边界测试。
实现 MapProcessor<T,R>：同时扮演上游 Subscriber 与下游 Publisher。重点解决下游先订阅时 request 丢失的 pending demand 问题、cancel 双向上传播、终止信号只发一次，以及 mapper 抛异常时先取消上游再通知下游的顺序。附两个订阅顺序的实测与三条 Processor 专项规则。
实现三个有代表性的 Subscriber：LoggingSubscriber、逐元素请求的 CountingSubscriber 和批量消费的 BatchingSubscriber。按 §2.1（用 request 表达需求）、§2.7（request/cancel 串行）、§2.8（cancel 后可能有迟到元素）、§2.3（终止回调不得操作 Subscription）逐条落实，并指出「synchronized 不等于信号串行」和「onComplete 里再 request」两个真实 bug。
实现带背压的异步 Publisher——AsyncRangePublisher：用饱和加法累加 request、用 CAS 扣减额度、用 done 标志保证终止信号只发一次，并解释为什么必须用单线程 Executor 保证信号串行。给出完整实现、取消与空范围测试，以及三个容易写错的并发细节。
从零实现符合 Reactive Streams 规范的最小同步 Publisher：SyncSinglePublisher。逐行剖析 subscribe 的 onSubscribe 时序（§1.9）、request 的额度与非法值处理（§1.1、§3.9）、终止后的信号禁令（§1.7）与 cancel 语义（§3.12），并给出编译运行、边界测试和常见错误写法。
按 Reactive Streams 1.0.4 官方编号逐条梳理 43 条规则：§1 Publisher（1.1–1.11）、§2 Subscriber（2.1–2.13）、§3 Subscription（3.1–3.17）、§4 Processor（4.1–4.2），给出完整速查表，并深入拆解 1.1 的 happens-before、1.9/2.12/2.5 的订阅语义、2.3 的终止回调禁令、2.8 的 cancel 延迟、3.2/3.3 的同步递归上限与 3.9/3.17 的请求边界，最后对应到 TCK 的真实测试方法名。
拆解 Reactive Streams 的四个核心接口 Publisher、Subscriber、Subscription、Processor 的定义、职责与交互时序；说明 org.reactivestreams 与 JDK 9 Flow 的语义等价但类型不兼容，给出双向适配器；澄清 onSubscribe 时序、重复订阅、null 元素与 request/cancel 串行化四个高频误解。
从同步阻塞到回调函数，从 Future/Promise 到 CompletableFuture 链式编排，再到 Stream 的惰性求值，逐层分析每种异步模型的能力与边界，引出「推模型没有刹车」这一根本矛盾，说明为什么需要 Reactive Streams 的 request-pull 混合模型来解决速率不匹配问题。
本书前言：说明读者画像与前置知识，给出环境清单（JDK 25 + Reactor BOM 2025.0.8 + RxJava 3.1.12 + RS TCK 1.0.4），搭建 eventd-v1 多模块 Maven 骨架，约定代码风格、编译命令与验证方式，并列出全部依赖版本与真实输出供读者核对。
本序从回调地狱的三宗罪出发，说明为什么 Promise 和 CompletableFuture 都无法解决根本问题，引出 Reactive Streams 规范作为信号契约的诞生背景；同时声明三卷分工与本书边界——不写 Netty 源码、不写 Spring WebFlux 配置、不写 Kafka Streams 拓扑。
《Java 响应式编程·Reactive Streams 与背压原理》全书 50 篇目录页：14 章 42 节覆盖 RS 规范、从零实现 Publisher、Project Reactor 核心（Mono/Flux/操作符/调度器）、背压四大策略、Hot 与 Cold 多播、RxJava 3 对照、RS TCK 合规测试，最后以 eventd v1 背压演示系统验收。另含序、前言与五份附录。
榜单是读多写少的典型：整榜、分页和“我的排名”会被反复刷新。本节比较整榜缓存、分页缓存和个人名次缓存的收益与失效成本，讨论缓存版本落后时玩家看到的名次偏差，给出热点榜的降级、有界缓存与惊群处理策略，并实现一个带版本失效、过期兜底和统计计数的读模型。
泄漏之所以长期存在，是因为它通常不崩溃、重启就好、也难以复现。本节用 LRU 容量、引用计数快照与场景前后差值，把「这一局比上一局多了什么」变成可断言、可定位到具体 key 的结构化报告，并给出能在 CI 里重复执行、失败时能指出 key 的往返测试。
从大促前两周错误预算只剩 8% 却仍要发版的争议切入，说明错误预算的算术、燃尽速率与多窗口判据，给出 allow、canary-only、freeze 三档发布门禁的可运行的 Go 实现、固定时钟的测试与本机真实输出，并讨论冻结的退出条件。
结算高峰的写入不能一条条落到榜单。本节把写缓冲、赛季截止和奖励结算放在同一条时间线上：哪些写入可以合并，在途写入如何进入封榜快照，重复结算如何靠回执摘要识别，旧榜只读与新榜初始化怎样切换，并给出一个带截止校验、不可变快照、冲突检测和幂等结算的可运行实现。
从 arch-lab 订单看板显示 99.97% 而用户仍在投诉的场景切入，说明 SLI 的观察点应靠近用户、分母只放用户发起的有效事件、窗口长度要匹配决策周期，并给出滚动与日历窗口差异、无数据判据、可运行的 Go 实现与本机真实测试输出。
水位不应该是产品级常量，而应由设备内存与分档比例算出整数 MB 预算。本节把低端 35% 预算、70/85/95 三档压力线与无感优先的降级阶梯组合成一份可执行计划，并给出消消与方舟在 2GB、3GB、4GB、6GB 设备上的完整水位对照。
《裂隙战场》《群岛纪元》《泡泡工坊》的榜单需求并不相同。本节把榜单拆成受众、分区、分段和同分排序四个维度，比较有序集合、最大堆与分桶计数的更新成本，说明只展示 Top N 时如何保留精确名次，并给出一个带分段策略、确定性排序和输入校验的可运行榜单模型。
从库存只剩一件却被两个请求同时卖出的场景出发，把库存不超卖、订单状态单向推进、支付不重复扣款写成可执行谓词，再用故障注入反推每种不变量需要的最弱一致性模型，附条件更新、版本 CAS 与幂等扣款的 Go 实现和判据表，让每条规则都能被测试直接断言。