.NET4 ExpandoObject 使用泄漏内存
.NET4 ExpandoObject usage leaking memory
我有一个继承的 .NET 4.0 应用程序 运行 作为 Windows 服务。无论如何,我都不是 .NET 专家,但在编写代码 30 多年之后,我知道如何找到自己的出路。
当服务首次启动时,它会占用大约 70MB 的私有工作集。服务越长 运行s,占用的内存就越多。增加并没有那么显着,以至于您只是坐着观看时就会注意到,但是我们已经看到应用程序 运行 很长一段时间(100 多天)后达到数 GB(当前为 5GB)的实例记录)。我将 ANTS Memory Profiler 附加到一个 运行ning 实例,发现 ExpandoObject 的使用似乎解释了数兆字节的字符串,这些字符串没有被 GC 清除。可能还有其他泄漏,但这是最引人注目的,因此首先受到攻击。
我从其他 SO 帖子了解到,"normal" ExpandoObject 的使用在读取(但不写入)动态分配的属性时会生成内部 RuntimeBinderException。
dynamic foo = new ExpandoObject();
var s;
foo.NewProp = "bar"; // no exception
s = foo.NewProp; // RuntimeBinderException, but handled by .NET, s now == "bar"
您可以在 VisualStudio 中看到异常发生,但最终它是在 .NET 内部处理的,您得到的只是您想要的值。
Except...异常消息 属性 中的字符串似乎保留在堆上并且永远不会被垃圾收集,即使在生成它的 ExpandoObject 超出范围之后很久也是如此。
简单示例:
using System;
using System.Dynamic;
namespace ConsoleApplication2
{
class Program
{
public static string foocall()
{
string str = "", str2 = "", str3 = "";
object bar = new ExpandoObject();
dynamic foo = bar;
foo.SomePropName = "a test value";
// each of the following references to SomePropName causes a RuntimeBinderException - caught and handled by .NET
// Attach an ANTS Memory profiler here and look at string instances
Console.Write("step 1?");
var s2 = Console.ReadLine();
str = foo.SomePropName;
// Take another snapshot here and you'll see an instance of the string:
// 'System.Dynamic.ExpandoObject' does not contain a definition for 'SomePropName'
Console.Write("step 2?");
s2 = Console.ReadLine();
str2 = foo.SomePropName;
// Take another snapshot here and you'll see 2nd instance of the identical string
Console.Write("step 3?");
s2 = Console.ReadLine();
str3 = foo.SomePropName;
return str;
}
static void Main(string[] args)
{
var s = foocall();
Console.Write("Post call, pre-GC prompt?");
var s2 = Console.ReadLine();
// At this point, ANTS Memory Profiler shows 3 identical strings in memory
// generated by the RuntimeBinderExceptions in foocall. Even though the variable
// that caused them is no longer in scope the strings are still present.
// Force a GC, just for S&G
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
Console.Write("Post GC prompt?");
s2 = Console.ReadLine();
// Look again in ANTS. Strings still there.
Console.WriteLine("foocall=" + s);
}
}
}
我想 "bug" 是旁观者的眼睛(我的眼睛说 bug)。我错过了什么吗?这是群里.NET高手们的正常预料吗?有什么方法可以告诉它清除这些东西吗?首先不使用 dynamic/ExpandoObject 是最好的方法吗?
这似乎是由于编译器为动态 属性 访问生成的代码执行了缓存。 (使用 VS2015 和 .NET 4.6 的输出进行分析;其他编译器版本可能会产生不同的输出。)
编译器将调用 str = foo.SomePropName;
重写为类似这样的内容(根据 dotPeek;请注意 <>o__0
等是不合法的 C# 标记,但由 C# 编译器创建):
if (Program.<>o__0.<>p__2 == null)
{
Program.<>o__0.<>p__2 = CallSite<Func<CallSite, object, string>>.Create(Binder.Convert(CSharpBinderFlags.None, typeof (string), typeof (Program)));
}
Func<CallSite, object, string> target1 = Program.<>o__0.<>p__2.Target;
CallSite<Func<CallSite, object, string>> p2 = Program.<>o__0.<>p__2;
if (Program.<>o__0.<>p__1 == null)
{
Program.<>o__0.<>p__1 = CallSite<Func<CallSite, object, object>>.Create(Binder.GetMember(CSharpBinderFlags.None, "SomePropName", typeof (Program), (IEnumerable<CSharpArgumentInfo>) new CSharpArgumentInfo[1]
{
CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, (string) null)
}));
}
object obj3 = Program.<>o__0.<>p__1.Target((CallSite) Program.<>o__0.<>p__1, obj1);
string str1 = target1((CallSite) p2, obj3);
Program.<>o__0.<>p__1
是 CallSite<Func<CallSite,object,object>>
类型的静态字段(在私有嵌套 class 上)。它持有对第一次访问 foo.SomePropName
时按需编译的动态方法的引用。 (大概这是因为创建绑定很慢,所以缓存它可以显着提高后续访问的速度。)
此 DynamicMethod
持有对 DynamicILGenerator
的引用,后者引用最终持有令牌列表的 DynamicScope
。这些标记之一是动态生成的字符串 'System.Dynamic.ExpandoObject' does not contain a definition for 'SomePropName'
。该字符串存在于内存中,因此动态生成的代码可以抛出(并捕获)带有 "right" 消息的 RuntimeBinderException
。
总的来说,<>p__1
字段保留了大约 2K 的数据(包括该字符串的 172 个字节)。没有支持的方法来释放此数据,因为它以编译器生成的类型上的静态字段为根。 (您当然可以使用反射将该静态字段设置为 null
,但这将非常依赖于当前编译器的实现细节,并且很可能在将来中断。)
据我目前所见,在 C# 代码中使用 dynamic
似乎为每个 属性 访问分配了大约 2K 的内存;您可能只需要考虑使用动态代码的代价。但是(至少在这个简化的示例中),该内存仅在代码第一次执行时分配,因此程序运行时间越长,它不应该继续使用更多内存;可能有不同的泄漏将工作集推到 5GB。 (字符串有三个实例,因为执行 foo.SomePropName
的代码有三行;但是,如果您调用 foocall
100 次,仍然只有三个实例。)
为了提高性能并减少内存使用,您可能需要考虑使用 Dictionary<string, string>
或 Dictionary<string, object>
作为更简单的 key/value 存储(如果代码编写方式可行的话) ).请注意,ExpandoObject
实现了 IDictionary<string, object>
,因此以下小的重写会产生相同的输出,但避免了动态代码的开销:
public static string foocall()
{
string str = "", str2 = "", str3 = "";
// use IDictionary instead of dynamic to access properties by name
IDictionary<string, object> foo = new ExpandoObject();
foo["SomePropName"] = "a test value";
Console.Write("step 1?");
var s2 = Console.ReadLine();
// have to explicitly cast the result here instead of having the compiler do it for you (with dynamic)
str = (string) foo["SomePropName"];
Console.Write("step 2?");
s2 = Console.ReadLine();
str2 = (string) foo["SomePropName"];
Console.Write("step 3?");
s2 = Console.ReadLine();
str3 = (string) foo["SomePropName"];
return str;
}
我有一个继承的 .NET 4.0 应用程序 运行 作为 Windows 服务。无论如何,我都不是 .NET 专家,但在编写代码 30 多年之后,我知道如何找到自己的出路。
当服务首次启动时,它会占用大约 70MB 的私有工作集。服务越长 运行s,占用的内存就越多。增加并没有那么显着,以至于您只是坐着观看时就会注意到,但是我们已经看到应用程序 运行 很长一段时间(100 多天)后达到数 GB(当前为 5GB)的实例记录)。我将 ANTS Memory Profiler 附加到一个 运行ning 实例,发现 ExpandoObject 的使用似乎解释了数兆字节的字符串,这些字符串没有被 GC 清除。可能还有其他泄漏,但这是最引人注目的,因此首先受到攻击。
我从其他 SO 帖子了解到,"normal" ExpandoObject 的使用在读取(但不写入)动态分配的属性时会生成内部 RuntimeBinderException。
dynamic foo = new ExpandoObject();
var s;
foo.NewProp = "bar"; // no exception
s = foo.NewProp; // RuntimeBinderException, but handled by .NET, s now == "bar"
您可以在 VisualStudio 中看到异常发生,但最终它是在 .NET 内部处理的,您得到的只是您想要的值。
Except...异常消息 属性 中的字符串似乎保留在堆上并且永远不会被垃圾收集,即使在生成它的 ExpandoObject 超出范围之后很久也是如此。
简单示例:
using System;
using System.Dynamic;
namespace ConsoleApplication2
{
class Program
{
public static string foocall()
{
string str = "", str2 = "", str3 = "";
object bar = new ExpandoObject();
dynamic foo = bar;
foo.SomePropName = "a test value";
// each of the following references to SomePropName causes a RuntimeBinderException - caught and handled by .NET
// Attach an ANTS Memory profiler here and look at string instances
Console.Write("step 1?");
var s2 = Console.ReadLine();
str = foo.SomePropName;
// Take another snapshot here and you'll see an instance of the string:
// 'System.Dynamic.ExpandoObject' does not contain a definition for 'SomePropName'
Console.Write("step 2?");
s2 = Console.ReadLine();
str2 = foo.SomePropName;
// Take another snapshot here and you'll see 2nd instance of the identical string
Console.Write("step 3?");
s2 = Console.ReadLine();
str3 = foo.SomePropName;
return str;
}
static void Main(string[] args)
{
var s = foocall();
Console.Write("Post call, pre-GC prompt?");
var s2 = Console.ReadLine();
// At this point, ANTS Memory Profiler shows 3 identical strings in memory
// generated by the RuntimeBinderExceptions in foocall. Even though the variable
// that caused them is no longer in scope the strings are still present.
// Force a GC, just for S&G
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
Console.Write("Post GC prompt?");
s2 = Console.ReadLine();
// Look again in ANTS. Strings still there.
Console.WriteLine("foocall=" + s);
}
}
}
我想 "bug" 是旁观者的眼睛(我的眼睛说 bug)。我错过了什么吗?这是群里.NET高手们的正常预料吗?有什么方法可以告诉它清除这些东西吗?首先不使用 dynamic/ExpandoObject 是最好的方法吗?
这似乎是由于编译器为动态 属性 访问生成的代码执行了缓存。 (使用 VS2015 和 .NET 4.6 的输出进行分析;其他编译器版本可能会产生不同的输出。)
编译器将调用 str = foo.SomePropName;
重写为类似这样的内容(根据 dotPeek;请注意 <>o__0
等是不合法的 C# 标记,但由 C# 编译器创建):
if (Program.<>o__0.<>p__2 == null)
{
Program.<>o__0.<>p__2 = CallSite<Func<CallSite, object, string>>.Create(Binder.Convert(CSharpBinderFlags.None, typeof (string), typeof (Program)));
}
Func<CallSite, object, string> target1 = Program.<>o__0.<>p__2.Target;
CallSite<Func<CallSite, object, string>> p2 = Program.<>o__0.<>p__2;
if (Program.<>o__0.<>p__1 == null)
{
Program.<>o__0.<>p__1 = CallSite<Func<CallSite, object, object>>.Create(Binder.GetMember(CSharpBinderFlags.None, "SomePropName", typeof (Program), (IEnumerable<CSharpArgumentInfo>) new CSharpArgumentInfo[1]
{
CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, (string) null)
}));
}
object obj3 = Program.<>o__0.<>p__1.Target((CallSite) Program.<>o__0.<>p__1, obj1);
string str1 = target1((CallSite) p2, obj3);
Program.<>o__0.<>p__1
是 CallSite<Func<CallSite,object,object>>
类型的静态字段(在私有嵌套 class 上)。它持有对第一次访问 foo.SomePropName
时按需编译的动态方法的引用。 (大概这是因为创建绑定很慢,所以缓存它可以显着提高后续访问的速度。)
此 DynamicMethod
持有对 DynamicILGenerator
的引用,后者引用最终持有令牌列表的 DynamicScope
。这些标记之一是动态生成的字符串 'System.Dynamic.ExpandoObject' does not contain a definition for 'SomePropName'
。该字符串存在于内存中,因此动态生成的代码可以抛出(并捕获)带有 "right" 消息的 RuntimeBinderException
。
总的来说,<>p__1
字段保留了大约 2K 的数据(包括该字符串的 172 个字节)。没有支持的方法来释放此数据,因为它以编译器生成的类型上的静态字段为根。 (您当然可以使用反射将该静态字段设置为 null
,但这将非常依赖于当前编译器的实现细节,并且很可能在将来中断。)
据我目前所见,在 C# 代码中使用 dynamic
似乎为每个 属性 访问分配了大约 2K 的内存;您可能只需要考虑使用动态代码的代价。但是(至少在这个简化的示例中),该内存仅在代码第一次执行时分配,因此程序运行时间越长,它不应该继续使用更多内存;可能有不同的泄漏将工作集推到 5GB。 (字符串有三个实例,因为执行 foo.SomePropName
的代码有三行;但是,如果您调用 foocall
100 次,仍然只有三个实例。)
为了提高性能并减少内存使用,您可能需要考虑使用 Dictionary<string, string>
或 Dictionary<string, object>
作为更简单的 key/value 存储(如果代码编写方式可行的话) ).请注意,ExpandoObject
实现了 IDictionary<string, object>
,因此以下小的重写会产生相同的输出,但避免了动态代码的开销:
public static string foocall()
{
string str = "", str2 = "", str3 = "";
// use IDictionary instead of dynamic to access properties by name
IDictionary<string, object> foo = new ExpandoObject();
foo["SomePropName"] = "a test value";
Console.Write("step 1?");
var s2 = Console.ReadLine();
// have to explicitly cast the result here instead of having the compiler do it for you (with dynamic)
str = (string) foo["SomePropName"];
Console.Write("step 2?");
s2 = Console.ReadLine();
str2 = (string) foo["SomePropName"];
Console.Write("step 3?");
s2 = Console.ReadLine();
str3 = (string) foo["SomePropName"];
return str;
}