长生命周期上下文不直接增加并发标记物理压力，而是通过固化引用链延长标记路径、引发跨代引用，导致rset更新开销增大和标记范围扩张；缓解需收缩上下文生命周期而非调优gc参数。
反应式流中长生命周期上下文对象本身不直接拖累并发标记阶段的物理压力，真正起作用的是它对对象图可达性边界和跨代引用关系的隐式固化。
长生命周期上下文如何延长标记路径
典型如 Reactor 的 ContextView 或自定义的 ThreadLocal 绑定上下文容器，一旦被业务逻辑长期持有（例如注入到 Mono/Flux 链路深处、缓存在全局 registry 中），就会成为 GC Roots 的间接延伸。JVM 并不区分“业务根”和“框架根”，只要能从 GC Roots（如静态字段、活跃线程栈帧、JNI 引用等）一路到达该上下文，它及其所持有的全部嵌套对象（日志 MDC、认证 token、追踪 span、临时缓存 map 等）都会被标记为存活。
这导致两个实际后果：
- 并发标记线程需遍历更宽、更深的对象图，尤其当上下文内含大量弱引用或软引用集合时，标记器仍要逐个检查其 referent 是否可达；
- 若上下文对象驻留在老年代，而它引用了大量年轻代中的瞬时对象（比如每次请求创建的 DTO、validator 实例），就会产生大量跨代引用（remembered set entry），迫使 G1/ZGC 在并发标记期间频繁更新 RSet，增加写屏障开销和 CPU 占用。
不是“对象活着”，而是“引用链没断”
很多团队误以为“只要不显式 retain 就没事”，但反应式编程中隐式持有非常普遍：
- Context 写入后未清理：Mono.subscriberContext(ctx -> ctx.put("traceId", id)) 后未在链尾调用 contextWrite(Context.empty()) 清空；
- Subscriber 泄漏：使用 doOnSubscribe 或 LambdaSubscriber 时，闭包捕获了外部上下文对象且未及时置 null；
- Operator 缓存副作用：flatMap + cache() 组合下，上游 Context 被绑定进缓存节点的内部状态，随缓存长期驻留。
这些都不是内存泄漏的典型堆转储特征（比如线程未终止），而是“合法存活但不该活这么久”的可达性污染。
缓解的关键不在回收器选型，而在上下文生命周期契约
并发标记阶段的物理压力（CPU、缓存行竞争、RSet 更新延迟）无法靠调大 -XX:ConcGCThreads 抵消，必须收缩标记范围：
- 对所有 Context.put() 操作加白名单校验，拒绝非必要键（如避免 put("requestBody", hugeObj)）；
- 用 ContextRegistry 替代全局 static Map，配合 weakReference 包装 value，并设置 TTL 清理策略；
- 在链路出口强制插入 .contextWrite(Context.empty()) 或基于 Scope 的自动 cleanup hook（如 Project Reactor 2026.0.0+ 支持的 ScopedContext）；
- 启用 -XX:+PrintAdaptiveSizePolicy 和 -Xlog:gc+remset* 查看 RSet 增长热点，定位哪些 operator 是跨代引用大户。
别忽略元空间与直接内存的连带影响
长生命周期上下文常伴随动态类生成（如 CGLIB 代理、运行时编译的 predicate）、DirectByteBuffer 分配（Netty PooledByteBufAllocator 中未释放的池化 buffer）。这些虽不在堆内，但会加剧元空间 GC 频率或触发 Cleaner 线程争抢，间接拖慢整体并发标记节奏——因为 ZGC/G1 的并发阶段需与应用线程共享 CPU 时间片，任何额外调度都稀释其吞吐。
真正解耦物理压力，是让上下文变“薄”、变“短”、变“可预测”，而不是给 GC 更多线程或更大堆。
