Reactor Core中TimedScheduler的内存泄漏问题分析与修复

问题背景

在Reactor Core项目的Micrometer集成模块中，TimedScheduler是一个用于包装原生Scheduler并提供度量指标功能的装饰器类。它通过Micrometer库来收集和暴露调度器的各种运行时指标，如待处理任务数、活跃任务数等。

问题现象

开发团队发现，当使用TimedScheduler时，在某些特定场景下会出现内存泄漏问题。具体表现为：当一个被调度的任务在被执行前被取消（dispose）时，该任务对应的待处理任务指标样本（pending sample）不会被正确清理，导致这些样本对象在内存中不断累积。

问题分析

这个问题主要出现在以下典型场景中：

1. 使用timeout操作符时，会提交一个延迟任务来表示超时
2. 如果响应式链在超时触发前完成，这个延迟任务会被取消
3. 在现有实现中，任务取消时没有同步清理对应的待处理指标样本

这种场景在实际应用中非常常见，特别是频繁使用timeout操作符的情况下，内存泄漏问题会迅速显现。

技术细节

TimedScheduler内部使用LongTaskTimer来跟踪待处理任务。当任务被调度时，会创建一个Sample对象来记录任务进入待处理状态的时间。理想情况下，这个Sample应该在以下两种情况下被停止：

1. 任务被执行时
2. 任务被取消时

但原实现只处理了第一种情况，忽略了任务被取消的场景。

解决方案

经过讨论和验证，最终采用了以下解决方案：

1. 将TimedRunnable同时实现Disposable接口
2. 在任务类内部维护对实际Disposable的引用
3. 重写dispose方法，在取消任务时同时停止对应的指标样本
4. 重构调度逻辑，将重复的计数器操作集中到TimedRunnable中

这种设计既解决了内存泄漏问题，又避免了创建额外的包装对象，保持了良好的性能特性。

修复效果

修复后，系统能够正确跟踪所有场景下的任务生命周期：

• 任务正常执行：指标样本在执行时停止
• 任务被拒绝：指标样本在拒绝时停止
• 任务被取消：指标样本在取消时停止

这彻底解决了因任务取消导致的指标样本泄漏问题，保证了系统的稳定性和指标数据的准确性。

总结

这次修复展示了在构建监控系统时需要考虑的完整生命周期管理。特别是在异步、响应式编程模型中，任务的取消和拒绝是常见场景，监控系统必须妥善处理这些边界条件，才能提供准确可靠的指标数据，同时避免资源泄漏问题。

对于使用Reactor Core的开发者来说，这次修复意味着在使用timeout等操作符时，可以放心地依赖TimedScheduler提供的指标，而不必担心内存泄漏的风险。这也为其他类似的监控集成实现提供了良好的参考范例。