Microsoft DI的GetService方法ThrowHelper行出现StackOverflow异常求助

根因定位 #

你观察到栈溢出出现在ThrowHelper.ThrowObjectDisposedException()行只是表层现象，该行本身不会触发栈溢出，核心问题是已被释放的ServiceProvider被注入到了长生命周期服务中，被反复调用GetService触发异常递归调用，或是依赖链深度超过了线程栈上限。

常见疑问解答

• 微软DI原生bug的概率极低：该场景的栈溢出几乎都是生命周期管理错误导致的，你用到的Hangfire是高频踩坑点。Hangfire的任务执行默认处于独立生命周期域，如果你把根容器或已释放的Scope直接注入到了Hangfire的任务类中，任务触发时访问已经被标记为_disposed的ServiceProvider，就会触发该问题。
• 依赖层级过深的概率较低：.NET默认线程栈大小为1MB，对应依赖注入层级上限约为100~200层，普通业务系统很少触及该阈值，除非存在极深的嵌套泛型依赖或装饰器链，若你的依赖链长度不超过50层可直接排除该可能。
• Hangfire多任务不会耗尽栈空间：每个任务运行在独立线程上，各线程栈空间互相隔离，任务数量过多只会耗尽内存或CPU资源，不会导致栈溢出，该猜测不成立。

排查与修复方案 #

1. 优先修正Hangfire DI集成逻辑
   不要将根ServiceProvider直接注入到Hangfire的任务类或JobActivator中，必须采用官方标准集成方案：每次任务执行前从根容器创建独立Scope，任务执行完成后立即释放Scope，避免Scope提前释放后仍被调用。
2. 开启DI生命周期验证
   在服务注册阶段开启作用域验证，启动项目时会自动输出所有生命周期不匹配的依赖项，远高于手动排查效率：

builder.Host.UseDefaultServiceProvider(options => 
{
    // 开发环境建议开启，生产环境可关闭避免性能损耗
    options.ValidateScopes = true;
    options.ValidateOnBuild = true;
});

3. 抓取完整调用栈定位问题
   在VS调试设置中关闭"仅我的代码"、勾选"启用本机代码调试"，或使用dotnet-dump工具在栈溢出触发时抓取进程转储，用VS或Windbg打开转储即可看到完整的递归调用链，直接定位到反复调用已释放ServiceProvider的具体服务。
4. 临时规避方案
   若需要先恢复业务再排查，可临时调大线程栈大小（仅作临时验证，不推荐生产长期使用），或在异常触发点增加判断直接终止调用链，避免递归触发栈溢出。

内容的提问来源于stack exchange，提问作者James X.