dotMemory
如今，许多开发人员都熟悉性能分析的工作流程：在分析器下运行应用程序，测量方法的执行时间，识别占用时间较多的方法，并致力于优化它们。然而，这种情况并没有涵盖到一个重要的性能指标：应用程序多次GC所分配的时间。当然，你可以评估GC所需的总时间，但是它从哪里来，如何减少呢？ “普通”性能分析不会给你任何线索。
垃圾收集总是由高内存流量引起的：分配的内存越多，需要收集的内存就越多。众所周知，内存流量优化应该在内存分析器的帮助下完成。它允许你确定对象是如何分配和收集的，以及这些分配背后保留了哪些方法。理论上看起来很简单，对吧？然而，在实践中，许多开发人员最终都会这样说：“好吧，我的应用程序中的一些流量是由一些系统类生成的，这些系统类的名称是我一生中第一次看到的。我想这可能是因为一些糟糕的代码设计。现在我该怎么做？”
这就是这篇文章的主题。实际上，这将是一系列文章，我将在其中分享我的内存流量分析经验：我认为什么是“糟糕的代码设计”，如何在内存中找到其踪迹，当然还有我认为的最佳实践。
简单的例子：如果您在堆中看到值类型的对象，那么装箱肯定是罪魁祸首。装箱总是意味着额外的内存分配，因此移除它很可能会让您的应用程序变得更好。
该系列的第一篇文章将重点关注装箱。如果检测到“bad memory pattern”，该去哪里查找以及如何采取行动？
本系列中描述的最佳实践使我们能够将 .NET 产品中某些算法的性能提高 20%-50%。
您需要什么工具
在我们进一步讨论之前，先看看我们需要的工具。我们在 JetBrains 使用的工具列表非常简短：
- dotMemory 内存分析器。无论您试图查找什么问题，分析算法始终相同：
- 在启用内存流量收集的情况下开始分析您的应用程序。
- 在您感兴趣的方法或功能完成工作后收集内存快照。
- 打开快照并选择内存流量视图。
- Heap Allocations Viewer插件。该插件会突出显示代码中分配内存的所有位置。这不是必须的，但它使编码更加方便，并且在某种意义上“迫使”您避免过度分配。
Boxing
装箱是将值类型转换为引用类型。 例如：
int i = 5;
object o = i; // 发生装箱
为什么这是个问题？值类型存储在栈中，而引用类型存储在托管堆中。因此，要将整数值分配给对象，CLR 必须从栈中取出该值并将其复制到堆中。当然，这种移动会影响应用程序的性能。
一个对象的至少占用3个指针单元：对象头（object header）、方法表指针（method table ref）、预留单元（首字段地址/数组长度）
在x64系统3个指针单元意味24字节的开销，而一个int类型本身只占用4字节，其次，栈内存的由执行线程方法栈管理，方法内声明的local变量、字面量更是能够在IL编译期就预算出栈容量，效率远高于运行时堆内存GC体系
如何发现
使用 dotMemory，找到boxing是一项基本任务：
- 打开View memory allocations视图。
- 查找值类型的对象（Group by Types），这些都是boxing的结果。
- 确定分配这些对象并生成大部分流量的方法。
当我们尝试将值类型赋值给引用类型时，Heap Allocation Viewer插件也会提示闭包分配的事实：
Boxing allocation: conversion from value type 'int' to reference type 'object'
从性能角度来看，您更感兴趣的是这种闭包发生的频率。例如，如果带有装箱分配的代码只被调用一次，那么优化它不会有太大帮助。考虑到这一点，dotMemory 在检测闭包是否引起真正问题方面要可靠得多。
如何修复
在解决装箱问题之前，请确保它确实会产生大量流量。如果是这样，你的任务就很明确：重写代码以消除装箱。当你引入某些值类型时，请确保不会在代码中的任何位置将值类型转换为引用类型。例如，一个常见的错误是将值类型的变量传递给使用字符串的方法（例如 String.Format）：
int i = 5;
string.Format("i = {0}", i); // 引发box
一个简单的修复方法是调用恰当的值类型 ToString() 方法：
int i = 5;
string.Format("i = {0}", i.ToString());
Resize Collections
动态大小的集合（例如 Dictionary, List, HashSet, 和 StringBuilder ）具有以下特性： 当集合大小超过当前边界时，.NET 会调整集合的大小并在内存中重新定义整个集合。显然，如果这种情况频繁发生，应用程序的性能将会受到影响。
如何发现
使用 dotMemory 比对两个快照
-
打开View memory allocations视图
-
找到产生大内存流量的集合类型
-
看看是否与
Dictionary<>.Resize、List<>.SetCapacity、StringBuilder.ExpandByABlock等等集合扩容有关
如何修复
如果“resize”方法造成的流量很大，唯一的解决方案是减少需要调整大小的情况数量。尝试预测所需的大小并用该大小初始化集合。
var list = new List<string>(1000); // 初始容量1000
此外请记住，任何大于或等于 85,000 字节的分配都会在大对象堆 (LOH) 上进行。在 LOH 中分配内存会带来一些性能损失：由于 LOH 未压缩，因此在分配时需要 CLR 和空闲列表之间进行一些额外的交互。然而，在某些情况下，在 LOH 中分配对象是有意义的，例如，在必须承受应用程序的整个生命周期的大型集合（例如缓存）的情况下。
Enumerating Collections
使用动态集合时，请注意枚举它们的方式。这里典型的主要头痛是使用 foreach 枚举一个集合，只知道它实现了 IEnumerable 接口。考虑以下示例：
class EnumerableTest
{
private void Foo(IEnumerable<string> sList)
{
foreach (var s in sList)
{
}
}
public void Goo()
{
var list = new List<string>();
for (int i = 0; i < 1000; i++)
{
Foo(list);
}
}
}
Foo 方法中的列表被转换为 IEnumerable 接口，这意味着枚举器的进一步装箱，因为List是结构体。
public struct Enumerator : IEnumerator, IEnumerator, IDisposable
{
public T Current { get; }
object IEnumerator.Current { get; }
public void Dispose();
public bool MoveNext();
void IEnumerator.Reset();
}
如何发现
- 打开View memory allocations视图
- 找到值类型
System.Collections.Generic.List+Enumerator并检查生成的流量。 - 查找生成这些对象的方法。
- Heap Allocation Viewer插件也会提示您有关隐藏分配的信息：
如何修复
避免将集合强制转换为接口。在上面的示例中，最佳解决方案是创建一个接受 List 集合的 Foo 方法重载。
private void Foo(List<string> sList)
{
foreach (var s in sList)
{
}
}
如果我们在修复后分析代码，会发现 Foo 方法不再创建枚举器。
don’t prematurely optimize
易读性应该在多数时候成为我们编码的第一原则，而非的性能优先或内存优先。本文讨论的一切都是微观优化，定期进行内存分析是良好的习惯
例如，交换a和b，从第一直觉上我们会编写出以下代码：
int a = 5;
int b = 10;
var temp = a;
a = b;
b = temp;
// 在c# 7+我们甚至可以用元组，进一步增强可阅读性
(a, b) = (b, a);
但是下面这种写法通过按位运算，可以不必申请额外空间来存储temp
a = a ^ b;
b = a ^ b;
a = a ^ b;
但这并不是我们鼓励的：过早的在编码初期进行优化，丧失可读性。在99%的情况下，我们的代码应该只依赖语义，剩下的，交给探查器！
上文Boxing提到的string.Format案例，只能代表今天，而不是明天。也许下一个将在IL编译时甚至JIT中去解决值类型装箱问题，Enumerating Collections也是同一个道理。
int i = 5;
string.Format("i = {0}", i); // 引发box
DefaultInterpolatedStringHandler
.net6引入的ref结构DefaultInterpolatedStringHandler，就是一个很好的案例
$"..." 这种字符串插值（String Interpolation）语法是在 C# 6.0 中引入的。
var i = 5;
var str = $"i = {i}"; // box
在.net6之前，上面的写法会发生装箱，生成的IL如下：
IL_001a: ldarg.0 // this
IL_001b: ldstr "i = {0}"
IL_0020: ldarg.0 // this
IL_0021: ldfld int32 Fake.EventBus.RabbitMQ.RabbitMqEventBus/'d__19' ::'5__1'
IL_0026: box [netstandard]System.Int32
IL_002b: call string [netstandard]System.String::Format(string, object)
IL_0030: stfld string Fake.EventBus.RabbitMQ.RabbitMqEventBus/'d__19' ::'5__2'
而从.net6开始，生成的IL发生了变化，由原来调用的System.String::Format(string, object)，变成了DefaultInterpolatedStringHandler，装箱也不见了，内部细节感兴趣的自己去阅读源码，内部用到了高性能的Span，unsafe和ArrayPool
IL_0014: ldloca.s V_3
IL_0016: ldc.i4.4
IL_0017: ldc.i4.1
IL_0018: call instance void [System.Runtime]System.Runtime.CompilerServices.DefaultInterpolatedStringHandler::.ctor(int32, int32)
IL_001d: ldloca.s V_3
IL_001f: ldstr "i = "
IL_0024: call instance void [System.Runtime]System.Runtime.CompilerServices.DefaultInterpolatedStringHandler::AppendLiteral(string)
IL_0029: nop
IL_002a: ldloca.s V_3
IL_002c: ldloc.0 // i
IL_002d: call instance void [System.Runtime]System.Runtime.CompilerServices.DefaultInterpolatedStringHandler::AppendFormatted(!!0/*int32*/)
IL_0032: nop
IL_0033: ldloca.s V_3
IL_0035: call instance string [System.Runtime]System.Runtime.CompilerServices.DefaultInterpolatedStringHandler::ToStringAndClear()
IL_003a: stloc.1 // str
不要过早优化
不要过早优化！！！
不要过早优化！！！
不要过早优化！！！
Link
本系列参考jetbrains官方团队的博客：https://blog.jetbrains.com/dotnet，加以作者的个人理解做出的二次创作，如有侵权请联系删除：2357729423@qq.com。