c# - String.Format 和垃圾回收

Question

在我对应用程序中高 CPU 使用率的持续调查中，我得出的结论是 GC 占用了大部分 CPU 时间。查看 w3wp 进程的内存转储(应用程序是 iis 托管的)我发现了一些奇怪的东西:堆上有很多 46 字节的大字符串对象，它们都死了并准备好被收集。 进一步调查以下命令:

!dumpheap -mt 00007ff9bd160e08 -dead -min 2e -max 2e

转储所有大小为 46 的死字符串对象告诉我，我目前有 260000 个该大小的死字符串。查看其中的一些很快就会发现它们都来自同一个地方，一个为我们的缓存创建键的辅助方法:

private static string Key(Guid ssoId)
{
    return string.Format("BasicUser:{0}-Brand:{1}", ssoId, MemBag.Client.BrandEnum);
}

46 字节的字符串是“BasicUser:”，仅此而已，至少据我所知:

0:000> !do 000000f1d48d49a0
Name:        System.String
MethodTable: 00007ff9bd160e08
EEClass:     00007ff9bca84860
Size:        46(0x2e) bytes
File:        C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
String:      BasicUser:
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ff9bd163980  40000ab        8         System.Int32  1 instance               10 m_stringLength
00007ff9bd1620f0  40000ac        c          System.Char  1 instance               42 m_firstChar
00007ff9bd160e08  40000ad       18        System.String  0   shared           static Empty
                                 >> Domain:Value  000000ee12ced200:NotInit  000000ee138a4440:NotInit  <<

所有这些分配似乎不仅会导致 gen0 回收，还会导致很多完整回收，大约 80-90% 的回收是完整回收!

该方法确实被调用了很多次，但它给 GC 带来如此大的压力是没有意义的!这里发生了什么？该方法是否以错误的方式实现？堆上的字符串“BasicUser:”怎么来的？字符串的其余部分在哪里？即使参数为空，“品牌”部分仍然缺失。

我对这个问题很困惑，真的需要一些意见，非常感谢任何帮助!

更新

它似乎总是 10 个字符长，我将代码更改为:

  return string.Format("BasicUsr:{0}-Brand:{1}", ssoId, MemBag.Client.BrandEnum);

更改用户 -> Usr，结果是我现在在堆上看到这样的字符串:"BasicUsr:b"似乎总是前 10 个字符，我是不是把字符串转储错了？

更新2

我有机会从实时服务器获取 1 分钟的 perfview 捕获，这就是我得到的，如果我没看错的话，我们会分配大量数据，这就是高内存压力的原因，几乎每个集合是gen2

Answer 1

也许存在引用这些字符串的第二代对象，将此方法的返回值存储在堆栈上的局部字段/变量中的对象？

如果第 0 代对象被引用，它不会被收集到第 0 代集合中，并且会被提升。如果您创建生存期较短的对象，即使在很短的时间内也会被 Gen 2 对象引用，这些对象会在分配过程中立即提升。

简而言之，我会执行以下步骤:

在 windbg 中，运行!dumpheap -type "System.String"-live

-live 开关将过滤引用的对象。

选择几个你正在谈论的固定大小的对象，然后调用!gcroot [对象地址]其中 [objAddr] 是 String 对象的地址。您很可能会找到暂时保存短生命周期字符串的对象。