ABP.io集成Hangfire循环作业时触发DbContext已释放异常的解决

• Scoped服务生命周期错配：你注册的自定义Hangfire服务为Scoped生命周期，在应用启动阶段调用BookingAlarmRecurringJob方法注册循环作业时，捕获的是启动流程作用域下的服务实例。这个实例关联的TMSDbContext会在启动流程结束后被DI容器自动释放，后续Hangfire每分钟触发作业执行时，调用的还是这个已经被释放的实例，直接触发DbContext访问异常。
• UOW特性完全失效：你在BookingAlarmFunction上添加的[UnitOfWork]没有实际执行逻辑——这个方法是被脱离ABP拦截管线的旧实例调用的，ABP的工作单元拦截器不会对这个实例生效，自然不会为作业创建独立的DbContext作用域。
• 异步调用逻辑错误：bookings.ForEach(async booking => { ... })是典型的fire-and-forget写法，循环内部的异步逻辑不会被外层方法await，会导致外层逻辑提前执行完毕，UOW还没等异步数据库操作跑完就被释放，进一步加剧DbContext已释放的问题。
• 自定义类命名冲突：将业务类直接命名为Hangfire，和第三方Hangfire库的类型同名，容易引发不必要的类型匹配问题。

步骤1：重构作业服务，适配DI生命周期 #

• 移除手动在ConfigureServices里的Scoped注册代码，将作业类改成实现ITransientDependency，由ABP自动完成生命周期注册，同时解决命名冲突问题：

  public class BookingAlarmJobService : ITransientDependency // 自动注册为Transient生命周期
  {
      private readonly IRepository<Booking, int> _bookingsRepository;
      private readonly IBookingSignalR _bookingSignalR;
      private readonly IObjectMapper _objectMapper;
      private readonly IUnitOfWorkManager _unitOfWorkManager;
  
      public BookingAlarmJobService(
          IRepository<Booking, int> bookingsRepository,
          IBookingSignalR bookingSignalR,
          IObjectMapper objectMapper,
          IUnitOfWorkManager unitOfWorkManager)
      {
          _bookingsRepository = bookingsRepository;
          _bookingSignalR = bookingSignalR;
          _objectMapper = objectMapper;
          _unitOfWorkManager = unitOfWorkManager;
      }
  
      // 供Hangfire调用的作业入口
      public async Task ExecuteBookingAlarmAsync()
      {
          // 手动创建独立UOW，确保整个作业执行期间DbContext保持存活
          using var uow = _unitOfWorkManager.Begin(requiresNew: true, isTransactional: true);
          
          var bookings = await _bookingsRepository.ToListAsync();
          
          // 替换原ForEach的异步写法，确保所有逻辑被await
          foreach (var booking in bookings)
          {
              if (IsPlanningAlramActive(booking))
              {
                  booking.IsPlanningAlarmActive = true;
                  await SendSignalR(booking);
              }
              else if (IsPickupAlarmActive(booking))
              {
                  booking.IsPlanningAlarmActive = false;
                  booking.IsPickupAlarmActive = true;
                  await SendSignalR(booking);
              }
          }
  
          // 提交UOW的数据库修改
          await uow.CompleteAsync();
      }
  
      // 原有辅助逻辑保持不变
      private bool IsPlanningAlramActive(Booking booking) { /* 原有判断逻辑 */ }
      private bool IsPickupAlarmActive(Booking booking) { /* 原有判断逻辑 */ }
      private async Task SendSignalR(Booking booking) { /* 原有SignalR发送逻辑 */ }
  }
  

步骤2：在应用启动阶段注册循环作业 #

在应用模块的OnApplicationInitialization方法中完成作业注册，不要捕获启动流程里的旧服务实例：

public override void OnApplicationInitialization(ApplicationInitializationContext context)
{
    // 每次注册时从DI容器解析全新的作业实例
    var jobService = context.ServiceProvider.GetRequiredService<BookingAlarmJobService>();
    RecurringJob.AddOrUpdate(
        () => jobService.ExecuteBookingAlarmAsync(),
        Cron.Minutely());
}

注意：不要写() => new BookingAlarmJobService()这种硬编码创建实例的代码，会导致构造函数的依赖无法被DI容器解析。

如果已经正常引用了Volo.Abp.Hangfire官方集成包，这个包默认会为每个Hangfire作业执行创建独立的ABP DI作用域、自动初始化UOW，此时只需要做两个修改：

• 将原代码里的bookings.ForEach(async ...)替换为普通的foreach循环加await，修正异步执行不等待的问题
• 移除手动注册Scoped服务的代码，让ABP自动完成服务注册，[UnitOfWork]特性会在Hangfire创建的独立作用域内正常生效。

• 不要在循环作业注册时，把根作用域里解析的Scoped服务实例直接传给RecurringJob.AddOrUpdate，根作用域的Scoped实例生命周期和应用启动流程绑定，不会随Hangfire作业的执行周期动态创建新实例。
• 不要在List.ForEach方法里传入async委托，C#的ForEach不支持等待异步委托执行，会导致方法提前返回，UOW被提前释放。
• 作业的异步方法必须确保返回Task，不要把async方法包装成同步调用，否则Hangfire会在异步逻辑未执行完成时就释放关联的作用域。

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