Ninject 中的错误？

Question

寻求关于我是否有真正的错误的建议，如果是，如何最好地修复它：

我有一个 24/7 运行的高度多线程进程。有一些对象是通过 Ninject 在 ThreadScope 中提供的绑定进行注入的。

随着进程的负载不断增加，进程开始越来越频繁地崩溃。事件日志中的错误消息是这样的：

<前><代码>>框架版本：v4.0.30319 描述：进程被终止 >由于未处理的异常。异常信息： > System.NullReferenceException 堆栈：位于 > **Ninject.Activation.Caching.GarbageCollectionCachePruner.PruneCacheIfGarbageCollectorHasRun(System.Object)** >在 System.Threading.ExecutionContext.runTryCode(System.Object) 处 > System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup（TryCode， > CleanupCode、System.Object）位于 > System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, > System.Threading.ContextCallback、System.Object、布尔值）位于 > System.Threading._TimerCallback.PerformTimerCallback(System.Object)

下载 Ninject 的源代码并进行谷歌搜索后，这似乎是 Ninject 或 .NET 框架的一个问题（取决于你听的是谁）。

看起来绑定缓存的修剪正在尝试重新启动finally子句中已处理的计时器对象。 一年前曾尝试解决该逻辑的问题，但似乎还不够： http://groups.google.com/group/ninject/browse_frm/thread/cedf5d129120ee18/27119d7d3761eedd?tvc=1#27119d7d3761eedd

Microsoft 在这篇 MSDN 文章中解释了系统计时器的工作原理：http://msdn.microsoft.com/en-us/library/ system.threading.timer.aspx

根据 MSDN 文章，GC 可能在调用 TimerCallback 之前清理了计时器对象。因此，在“finally”子句中重新启动计时器会导致崩溃。

问题：如何在 Ninject 代码中解决这个问题？在这种情况下我应该忽略该错误吗？我应该创建一个新的计时器吗？我应该做点别的吗？我目前已经修改了代码以忽略该错误，以便我可以简单地阻止我的进程崩溃......但担心这不是一个很好的解决方案，任何建议都会受到赞赏。

相关文章： http://groups.google.com/group/ninject/browse_thread/thread/ 8cdf8362a41153c7

.NET 3.5 C# 错误与 System.计时器 System.ObjectDisposeException：无法访问已处置的对象

Ninject 垃圾收集

Answer 1

2.2 中存在一个错误，当缓存 (Ninject) 被释放时会导致竞争条件。此问题已在 3.0 中修复，

请参阅 https://github.com/ninject/ninject/blob/fa46b56b683d5ddf570d00c1bd057ecfa0b3b487/src/Ninject/Activation/Caching/GarbageCollectionCachePruner.cs

通常，除非您正在创建，否则您不应该看到任何问题并在运行时处置内核 - 这不是一个好方法无论如何都要使用 Ninject，并且应尽可能避免使用。这样，出现此问题的唯一情况应该是关机时。