.net 与DataContext和PropertyChanged事件相关的奇怪内存泄漏

我有一个用C#编写的windows服务

运行几天后，它将使用大约2GB的ram

使用“.NET内存分析器”，我注意到某个T_TurbineEventLog类的实例数量急剧增加。 这些对象来自一个循环，该循环每分钟通过LINQ到SQL查询获取它们（每次都有很多），在某些情况下，我会保留对其中少数对象的引用

内存探查器告诉我，这些对象中的大多数仅通过最短根路径保持活动状态，类似于以下内容（从我的内存中）：

根->…->T_TurbineEventLog->PropertyChanged->…（事件处理程序）->IdentityManager->…缓存->T_TurbineEventLog[]->T_TurbineEventLog

因此，在我看来，我自己保持活动状态的少数T_TurbineEventLog对象通过事件处理程序间接链接到原始SQL查询结果的总和（请记住，上面显示的是最短的根路径）

我使用（var db=new MyDataContext…）读取了一个小

中的对象，因此我猜datacontext应该取消订阅PropertyChange事件，但由于某种原因没有取消订阅

我已经尽我最大的能力使用谷歌，但这似乎不是一个已知的问题。
那么我做错了什么呢

到目前为止，解决方案是设置
ObjectTrackingEnabled=false
，这实际上消除了泄漏。
看起来设置
ObjectTrackingEnabled=false
是最好的解决方案。请认识到，上下文保留它获取的所有对象，以便它可以监视更改。仅处理它不会删除INotifyPropertyChanged/INotifyPropertyChanging上的事件挂钩，因此它们的保留时间比应该的长。由于您不需要更改跟踪，删除它不仅可以修复内存泄漏，还可以提高性能。我也看到了您描述它的方式。在我的情况下，我必须经过一些地方，其中使用了一个小的“using”语句来处理datacontext，并使用ObjectTracking=false选项。我在使用Ants profiler时，看到datacontext中某个特定类的实例数量在不断攀升。您是否在声明datacontext的using（…）范围之外使用实体？仅仅因为删除了数据上下文，就可能存在对其他事物的引用。如果您使用的是数据上下文范围之外的实体，则需要创建非LINQ/POCO类来镜像数据模型并深入复制到这些实体中。如果您需要示例，我可以提供它们。