如何在ASP.NET Core SignalR事件处理器中正确使用依赖注入？

我使用ASP.NET Core SignalR客户端订阅服务器消息，客户端启动时通过后台服务建立连接，并注册消息处理逻辑（对应HubConnectionExtensions的On方法）。

每条消息的处理逻辑是一个返回Task的Handler，该Handler依赖多个服务（如数据库仓储、外部API调用服务），所有依赖均通过ASP.NET Core默认DI容器（IServiceProvider）注入。

当前问题：启动阶段就注册了处理器，此时所有依赖已被解析，后续应用内存占用持续增长直至耗尽。调试后怀疑是DI或GC在消息处理完成后未正确清理资源，但不确定具体原因。

想请教两个问题：

1. 这种启动时解析依赖并注册处理器的方式，是否会导致内存泄漏？
2. 针对SignalR消息触发、依赖DI多服务调用的场景，正确的处理方式是什么？网上大多是简单控制台日志示例，缺乏深度实践。

一、内存增长的核心原因 #

你遇到的内存问题大概率是依赖生命周期不匹配导致的：

• 若启动时解析的依赖是Singleton生命周期，通常不会有问题；但如果是Scoped或Transient类型，一旦被绑定到SignalR的消息处理委托中，就会被长期持有（因为HubConnection和注册的On委托属于Singleton级别），导致这些本该被回收的实例无法被GC清理，最终引发内存泄漏。

举个典型例子：如果你的Handler依赖一个Scoped的DbContext，启动时解析该DbContext并绑定到处理委托，这个DbContext会被持续持有，不会被释放，同时它内部的连接池、缓存等资源也会长期占用内存，日积月累就会耗尽内存。

二、正确的处理方案 #

核心原则：不要在启动时直接解析Scoped/Transient依赖，而是在每次收到消息时，从DI容器中获取新的实例。

方案1：用IServiceScopeFactory创建局部作用域

在消息处理委托内部，通过IServiceScopeFactory创建独立作用域，在作用域内解析所需依赖，处理完成后销毁作用域，确保资源被正确释放。

示例代码：

// 后台服务中注入IServiceScopeFactory
public class SignalRBackgroundService : BackgroundService
{
    private readonly HubConnection _hubConnection;
    private readonly IServiceScopeFactory _scopeFactory;

    public SignalRBackgroundService(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
        _hubConnection = new HubConnectionBuilder()
            .WithUrl("https://your-signalr-server/hub")
            .Build();
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        // 注册消息处理逻辑时，不直接解析依赖
        _hubConnection.On<MessageModel>("ReceiveMessage", async (message) =>
        {
            // 每次收到消息时创建新作用域
            using var scope = _scopeFactory.CreateScope();
            var handler = scope.ServiceProvider.GetRequiredService<IMessageHandler>();
            
            // 执行消息处理
            await handler.ProcessMessageAsync(message);
        });

        await _hubConnection.StartAsync(stoppingToken);
        await Task.Delay(Timeout.Infinite, stoppingToken);
    }

    public override async Task StopAsync(CancellationToken stoppingToken)
    {
        await _hubConnection.StopAsync(stoppingToken);
        await _hubConnection.DisposeAsync();
        await base.StopAsync(stoppingToken);
    }
}

// 消息Handler注册为Scoped
public class MessageHandler : IMessageHandler
{
    private readonly IDbContext _dbContext;
    private readonly IExternalApiService _apiService;

    // 构造函数注入Scoped/Transient依赖
    public MessageHandler(IDbContext dbContext, IExternalApiService apiService)
    {
        _dbContext = dbContext;
        _apiService = apiService;
    }

    public async Task ProcessMessageAsync(MessageModel message)
    {
        // 处理逻辑：操作数据库、调用外部API等
        await _dbContext.Messages.AddAsync(message);
        await _dbContext.SaveChangesAsync();
        await _apiService.SendNotificationAsync(message);
    }
}

方案2：利用.NET 6+泛型HubConnection的DI支持（适合ASP.NET Core客户端）

如果你的客户端本身是ASP.NET Core应用，且使用.NET 6及以上版本，可以借助SignalR客户端的泛型Hub支持，让DI自动管理作用域：

• 定义继承自Hub的接口，通过HubConnectionBuilder.WithHub指定，这样消息处理方法中可直接注入Scoped依赖，底层会自动为每次消息创建作用域。

三、额外注意事项 #

• 避免在处理委托中捕获外部变量：注册On方法时，如果捕获了启动阶段的变量（如直接捕获Scoped依赖实例），会导致变量被委托长期持有，无法被GC回收。
• 检查依赖生命周期配置：确保所有依赖的生命周期配置正确，比如DbContext必须是Scoped，无状态的外部API服务可设为Singleton。
• 用工具定位泄漏点：可以使用Visual Studio内存分析器或dotMemory工具，捕获内存快照，查看哪些对象被长期持有，精准定位泄漏根源。

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