.NET 7 SignalR Hub内存持续增长问题及配置咨询

一、关于DefaultMessageBufferSize配置的说明 #

旧版ASP.NET SignalR的GlobalHost.Configuration.DefaultMessageBufferSize配置在ASP.NET Core SignalR（.NET 5+，包括.NET 7）中已被移除——新版SignalR是完全重写的架构，不再使用旧版的消息缓冲区机制。

如果需要实现类似的「重连时消息回溯」功能，需自行实现：

• 用有限容量的缓存（比如结合长度限制的ConcurrentQueue）存储最近发送的消息
• 在客户端重连时，从缓存中拉取指定数量的历史消息发送给客户端

二、内存持续增长的常见原因及解决建议 #

常见原因 #

• 未清理连接相关的静态/全局集合：若在Hub中用静态字典、列表存储连接ID或客户端信息，断开连接时未移除，会导致集合无限膨胀
• 事件订阅未取消：Hub实例订阅了外部事件，但断开时未取消订阅，导致实例被事件持有者引用无法被GC回收
• 大消息或高频大消息堆积：发送的消息体积过大，或客户端接收不及时，导致服务器内存中暂存大量未发送/未确认的消息
• 依赖注入生命周期错误：将Scoped/Transient服务注册为Singleton，导致服务持有Hub实例或连接信息的引用无法释放
• 资源未释放：为每个连接创建的定时器、流、第三方客户端等资源，断开时未手动释放
• 日志或诊断数据堆积：开启了过于详细的SignalR日志，且未配置日志滚动清理，导致日志占用内存

解决建议 #

• 用内存分析工具定位泄漏点：使用dotMemory、Visual Studio内存探查器捕获内存快照，分析哪些对象持续增长且未被GC回收
• 严格清理连接相关数据：在OnDisconnectedAsync中移除该连接在静态集合中的所有条目
• 取消事件订阅：在OnDisconnectedAsync中取消为当前连接订阅的所有事件（可使用CancellationTokenSource跟踪连接生命周期）
• 优化消息大小：对消息进行压缩（如Gzip），只发送必要数据，避免冗余字段
• 检查DI配置：确保服务生命周期符合要求，避免Singleton服务持有Scoped资源的引用
• 手动释放资源：在OnDisconnectedAsync中释放定时器、流等手动创建的资源
• 配置日志滚动策略：限制日志文件大小和保留数量，避免日志占用过多内存
• 启用GC日志：通过环境变量COMPlus_GCLogFile开启GC日志，检查垃圾回收是否正常执行

三、频繁断开连接引发的内存增长问题及清理方案 #

频繁的OnDisconnectedAsync调用本身不会直接导致内存增长，但如果连接生命周期内创建的资源未在断开时正确清理，就会引发内存泄漏：比如在OnConnectedAsync中为每个连接添加静态集合条目、创建定时器、订阅事件，但断开时未做对应清理，这些资源会一直占用内存。

具体清理方案 #

1. 移除连接信息：若用静态字典存储连接与客户端的映射，在OnDisconnectedAsync中执行：

// 假设_staticConnectionDict是存储连接ID和客户端数据的静态字典
if (_staticConnectionDict.TryRemove(Context.ConnectionId, out var clientData))
{
    // 同时释放clientData中的资源（如果有）
    clientData.Dispose();
}

2. 取消定时器/异步任务：若为连接创建了定时器，在断开时停止并释放：

// 假设_timer是为当前连接创建的定时器
_timer?.Change(Timeout.Infinite, Timeout.Infinite);
_timer?.Dispose();

3. 取消事件订阅：手动取消为当前连接订阅的外部事件：

// 假设订阅了某个外部事件
_externalService.SomeEvent -= OnSomeEvent;

4. 释放自定义资源：若为连接分配了自定义资源（如数据库连接、第三方SDK实例），在断开时调用Dispose释放

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