mirror of
https://github.com/GeWuYou/GFramework.git
synced 2026-05-14 06:34:30 +08:00
- 修复 MicrosoftDiContainer 在等待线程与并发 Dispose 场景下泄露底层锁异常的问题 - 更新 IIocContainer 释放契约文档并移除 Clear 中不可达的 provider 释放逻辑 - 新增 benchmark cleanup helper、并发释放回归测试与 ai-plan 恢复入口
2.4 KiB
2.4 KiB
Microsoft DI Container Disposal 追踪
2026-05-06
阶段:PR #330 review triage 与修复面收敛(MICROSOFT-DI-DISPOSAL-RP-001)
- 使用
$gframework-pr-review抓取当前分支对应的PR #330latest-head review 后,主线程确认仍有效的 open AI 反馈集中在四类:IIocContainer缺少显式的释放生命周期文档MicrosoftDiContainer.Clear()在_frozen == false路径下仍保留不可达的_provider.Dispose()调用MicrosoftDiContainer.Dispose()会让等待中的读写线程泄露ReaderWriterLockSlim的ObjectDisposedException- 多个
GFramework.Cqrs.Benchmarkscleanup 顺序释放资源但缺乏异常隔离,前一个Dispose()失败会阻断后续资源回收
- 本轮决策:
- 先补
ai-plan/public/microsoft-di-container-disposal的 tracking / trace,保证该跨模块 PR follow-up 有明确恢复入口 - 通过
EnterReadLockOrThrowDisposed/EnterWriteLockOrThrowDisposed收口MicrosoftDiContainer的等待中竞态,而不是零散修补个别 API - 通过共享
BenchmarkCleanupHelper一次性收敛 benchmark 宿主 cleanup 的同类风险
- 先补
- 实现补充:
IIocContainer现已补充释放契约文档,明确Dispose()幂等性、根IServiceProvider与同步资源归属,以及释放后的统一异常语义MicrosoftDiContainer.Clear()已移除未冻结路径下不可达的_provider.Dispose()调用MicrosoftDiContainer.Dispose()现先发布_disposed,再等待遗留 waiter 退场后释放底层锁;若锁在有限自旋内未静默,则记录 warning 并跳过锁销毁,避免Dispose()无限阻塞GFramework.Cqrs.Benchmarks新增BenchmarkCleanupHelper,并统一接入 7 个GlobalCleanup入口
- 回归验证:
Dispose_Should_Translate_Waiting_Readers_To_Container_ObjectDisposedExceptionDispose_Should_Be_Idempotent_When_Called_Concurrentlydotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~IocContainerLifetimeTests|FullyQualifiedName~MicrosoftDiContainerTests"通过,57/57passeddotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release通过,0 warning / 0 error
当前下一步
- 推送当前分支后重新运行
$gframework-pr-review,确认 latest-head open threads 是否已与本地修复对齐