TPL DataFlow v5.0构建多数据管道内存持续增长泄漏问题求排查方案

核心排查方向 #

• 检查BroadcastBlock的消息保留逻辑：TPL DataFlow的BroadcastBlock默认会留存最新的一条消息永久不释放，如果你没有显式配置Greedy = false或者没有给BroadcastBlock设置消息过期逻辑，单条大消息或者累计多次的大消息会长期占住内存。另外要确认两个下游ActionBlock的处理速度是否匹配上游，如果任意一个ActionBlock处理速度慢，加上你如果没给ActionBlock设BoundedCapacity，消息会在ActionBlock的输入队列里无限堆积，哪怕你给上游块设了限制也没用。
• 检查TransformBlock的资源泄漏：如果你的校验、解码逻辑里用到了非托管资源（比如原生指针、互操作对象、未释放的字节数组缓冲池对象），或者用到了大对象（超过85000字节的对象会进大对象堆LOH，LOH默认不会压缩，碎片化后会表现为内存持续上涨），哪怕逻辑执行完，这些对象如果没有被显式释放或者根引用没断开，GC不会回收。可以用内存诊断工具看是不是LOH占用持续走高，有没有大量存活的字节数组、自定义报文对象。
• 检查块的链接配置：你有没有给块之间的链接设置PropagateCompletion = true？如果没设的话，上游块完成后下游块不会收到完成通知，部分块的状态会一直挂在运行中，内部队列的消息不会被清理。另外如果加了过滤逻辑的链接，有没有配置丢弃不符合过滤规则的消息？如果没配置，不符合规则的消息会一直卡在块的输入队列里没人处理。
• 检查BufferBlock的生产逻辑：UDP收包逻辑是不是用了固定的缓冲池，或者有没有把收到的包的引用一直存在全局集合里？比如你为了去重或者日志留存，把封装后的数据包存在了全局的List、Dictionary里没有清理，也会导致内存只涨不跌。

验证&解决步骤 #

• 先给所有下游ActionBlock显式设置BoundedCapacity：new ActionBlock<YourMessage>(handler, new ExecutionDataflowBlockOptions { BoundedCapacity = 1024 })，值可以根据你的业务吞吐量调整，确保上游速度超过下游时，消息会在上游块卡住，而不是无限堆积在队列里。
• 修改BroadcastBlock的配置，默认的BroadcastBlock构造是留最新消息，如果你不需要留存历史消息，可以用重载设置：new BroadcastBlock<YourMessage>(msg => msg, new DataflowBlockOptions { BoundedCapacity = 1 })，如果你的消息是大对象，建议在这里做深拷贝返回，避免多个下游块持有同一个对象的引用导致延迟回收。
• 针对大对象堆优化：如果你的报文大小普遍超过85000字节，改用ArrayPool<byte>来复用字节数组，避免频繁分配大对象导致LOH碎片化。解码后的消息如果不需要跨块长期持有，用完就显式断开所有引用，比如不要把消息对象存到闭包、全局变量里。
• 添加诊断逻辑：给每个块的输入输出计数，比如用Interlocked.Increment统计每个块的接收、处理、输出消息数，看是不是某个块的输入数远大于输出数，快速定位到阻塞的节点。也可以在测试环境用dotMemory、VS的内存诊断工具拍两次内存快照，对比存活对象的类型和引用链，直接找到占内存的根对象。
• 检查异常处理逻辑：如果ActionBlock里的处理逻辑抛异常你没有捕获，默认情况下块会进入故障状态，后续所有消息都会堆在输入队列里不会被处理，内存也会持续上涨。建议给所有执行块加异常捕获，处理失败的消息要么转存到死信队列，要么显式丢弃，不要让故障块一直占着消息。

内容的提问来源于stack exchange，提问作者Chen Ben Hamo