C# 持有对实体框架对象的字符串属性的引用会阻止GC收集它吗？

我使用entity framework从MySQL数据库加载条目，并创建一个新对象，将数据库对象中的字符串属性发送到构造函数中，然后返回新对象（不直接引用任何数据库类）

当我运行内存分析器时，我会看到内存中保存的这些数据库实体的负载。这是正确的还是有什么办法可以解决这个问题

var eoList = new List<EnterpriseObject>();
using(var context = new DatabaseContext())
{
    var infos = context.tableName.Where(dbObject => dbObject.Date > DateTime.UtcNow).ToList();

    foreach (var dbObject in infos)
    {
        IEnumerable<SomeEnum> enums = dbObject.enumStrings.Select(enumString => enumString.ToSomeEnum()); // Added in edited, as this was the problem, this IEnumerable was a property in the EnterpriseObject and somehow kept references to the DbObjects. Changing the property to a List<SomeEnum> fixed my problem.
        var entepriseObject = new EnterpriseObject(dbObject.Name, dbObject.Date, enums);
        eoList.Add(enterpiseObject);
    }
}
return eoList;

var eoList=newlist（）；
使用（var context=new DatabaseContext（））
{
var infos=context.tableName.Where（dbObject=>dbObject.Date>DateTime.UtcNow.ToList（）；
foreach（infos中的var dbObject）
{
IEnumerable enums=dbObject.enumStrings.Select（enumString=>enumString.ToSomeEnum（））；//在编辑中添加，因为这是问题所在，此IEnumerable是EnterpriseObject中的一个属性，并且以某种方式保留了对DbObjects的引用。将属性更改为列表修复了我的问题。
var EnterpriseObject=新企业对象（dbObject.Name、dbObject.Date、enums）；
eoList.Add（enterpiseObject）；
}
}
回归风尘；

只要引用了“eoList”对象，上面的代码是否会将“infos”中的所有引用都保留在内存中

如果是，有没有更好的方法来避免这个问题

托马斯

---

编辑：对于其他正在查看此问题的人，请检查我添加的代码行，这是问题所在。

假设

.Name

和

.Date

返回的类型不令人惊讶1，则不，您的

企业对象

不知道这些值来自

dbObject

，并且不会（本身）负责让他们活着

我希望一个好的内存分析器能告诉你对象是如何扎根的，也就是“是什么让这个对象保持活力？”。如果没有，您可以进行内存转储，并使用WinDbg/SOS回答相同的问题。不要猜测根源可能是什么

在

WinDBg

、

SOS

和

gcroot

上搜索可能会得到一些结果，但在大约10年左右的时间里，似乎没有人写过任何关于它的新文章。visualstudio还有一个

visualos.Extension

，看起来可以做得很好，但我自己还没有尝试过

---

---

1I.e。如果发现

Date

返回

this

，并且类型还支持从自身到

DateTime

的隐式转换，那么

其中
lambda编译：-）
会令人惊讶，假设
.Name
和
返回不令人惊讶的类型1，您的
enterpriseeobject
不知道这些值来自
dbObject
，并且不会（自身）负责使它们保持活动状态

我希望一个好的内存分析器能告诉你对象是如何扎根的，也就是“是什么让这个对象保持活力？”。如果没有，您可以进行内存转储，并使用WinDbg/SOS回答相同的问题。不要猜测根源可能是什么

在
WinDBg
、
SOS
和
gcroot
上搜索可能会得到一些结果，但在大约10年左右的时间里，似乎没有人写过任何关于它的新文章。visualstudio还有一个
visualos.Extension
，看起来可以做得很好，但我自己还没有尝试过


1I.e。如果发现
Date
返回
this
，并且类型还支持从自身到
DateTime
的隐式转换，那么
Where
lambda编译：-）
上述代码是否会在内存中保留“infos”中的所有引用，只要“eoList”一词对象是否被引用？
否。在调试器中，
infos
可能一直保持活动状态，直到方法结束（发布版本将导致它在该版本之前符合GC的条件）。您应该在上面的代码示例中删除<代码> Toistist<代码>，并考虑只投影您需要的列（<代码>名称<代码> >代码>日期>代码>，以避免不必要的数据通过该线。<代码>我看到内存中的这些数据库实体的加载< /代码>您看到了多少个？占用多少内存？
只要引用了“eoList”对象，上面的代码是否会将“infos”中的所有引用都保留在内存中？
否。在调试器中，
infos
很可能一直保持活动状态，直到方法结束（发布
生成将导致它在该时间之前符合GC的条件）。您应该在上面的代码示例中删除<代码> Toistist<代码>，并考虑只投影您需要的列（<代码>名称<代码> >代码>日期>代码>，以避免不必要的数据通过该线。<代码>我看到内存中的这些数据库实体的加载< /代码>您看到了多少个？占用了多少内存？谢谢你的回答，是的，我的分析器确实告诉我它是如何扎根的，它声称EnterpriseObject拥有一个Linq.Enumerable+WhereSelectListIterator。我的EnterpriseObject有一个类型为IEnumerable的属性，其中OtherEnterpriseType是从DbObject的string属性解析的枚举。因此问题似乎是IEnumerable属性以某种方式保留了引用（可能是因为某些惰性计算）。当我将其从IEnumerable更改为列表时，引用不再存在。感谢您的回答，是的，我的探查器确实会告诉我它是如何根的，并且它声称by EnterpriseObject拥有一个Linq.Enumerable+Where SelectListIterator。我的EnterpriseObject有一个类型为IEnumerable的属性，其中OtherEnterpriseType是从DbObject的string属性解析的枚举。因此问题似乎是IEnumerable属性以某种方式保留了引用（可能是因为某些惰性计算）。当我将它从IEnumerable更改为List时，引用不存在