????????提起GC大家肯定不陌生,但是让大家是说一下GC是怎么运行的,可能大多数人都不太清楚,这也很正常,因为GC这东西在.NET基本不用开发者关注,它是依靠程序自动判断来释放托管堆的,我们基本不需要主动调用Collect()释放内存,只需要注意对非托管资源进行及时释放就行。
????????虽说我们不用关注GC的运行,但是作为一个合格的程序员,还是有必要知道她是怎么工作的,因为垃圾回收对于一个程序来说真的太重要了,下面我们就用实际的应用来看下GC在.NET Core下是怎么工作的:
GC 会分配堆段,其中每个段都是一系列连续的内存。 置于堆中的对象归类为 3 个代系之一:0、1 或 2。 代系可确定 GC 尝试在应用不再引用的托管对象上释放内存的频率。 编号较低的代系会更加频繁地进行 GC。
对象会基于其生存期从一个代系移到另一个代系。 随着对象生存期延长,它们会移到较高代系。 如前所述,较高代系进行 GC 的频率较低。 短期生存的对象始终保留在第 0 代中。 例如,在 Web 请求存在期间引用的对象的生存期较短。 应用程序级别单一实例通常会迁移到第 2 代。
当 ASP.NET Core 应用启动时,GC 会:
进行以上内存分配是出于性能方面的原因。 性能优势来自连续内存中的堆段。
GitHub 上提供了?MemoryLeak 示例应用。 MemoryLeak 应用:
运行起来是这样的
GC = Server? asp.net 默认的是服务端GC
示例提供了很多接口用于调用测试
我们先来看一下第一个接口:
[HttpGet("bigstring")]
public ActionResult<string> GetBigString()
{
return new String('x', 10 * 1024);
}
创建一个 10-KB 字符串实例,并将它返回给客户端。 对于每个请求,会在内存中分配一个新对象并将它写入响应中。 字符串作为 UTF-16 字符存储在 .NET 中,因此每个字符都需要 2 字节内存。
使用压力测试工具Apache JMeter - Apache JMeter?
对这个接口进行压力测试,来观察内存使用情况
?
?
运行压力测试工具后可以看到内存使用及GC运行情况:
?
可以看到RPS在3K左右,当内存使用量升到了100M左右GC进行了第0代垃圾回收,第 0 代 GC 回收大约每两秒进行一次,内存消耗和释放(通过 GC)是稳定的,很少出现第1代回收,是因为分配的内存都是临时的小内存,并发量也在程序的可处理范围内,基本在第0代就可以完全回收。
接下来看下一个接口:
private static ConcurrentBag<string> _staticStrings = new ConcurrentBag<string>();
[HttpGet("staticstring")]
public ActionResult<string> GetStaticString()
{
var bigString = new String('x', 10 * 1024);
_staticStrings.Add(bigString);
return bigString;
}
GC 无法释放上面的静态资源对象。 引用了不再需要的对象会导致内存泄露。 如果应用经常分配对象,但在不再需要对象之后未能释放它们,则内存使用量会随着时间推移而增加。
上面的 API 创建一个 10-KB 字符串实例,并将它返回给客户端。 与上一个示例的不同之处在于,此实例由静态成员引用,这意味着它不能被GC回收。
?
运行压力测试工具后可以看到内存使用及GC运行情况:
?
在上图中:
/api/staticstring进行压力
测试,会导致内存线性增加。停止压力测试后内存还在持续占用,手动调用Collect()也无济于事
?
我们只能调用Clear()来清理静态资源,然后Collect()进行回收
[HttpGet("clear")]
public ActionResult<string> Clear()
{
_staticStrings.Clear();
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
return "";
}
?
来看下一个接口:
[HttpGet("fileprovider")]
public void GetFileProvider()
{
var fp = new PhysicalFileProvider(TempPath);
fp.Watch("*.*");
}
某些 .NET Core 对象依赖于本机内存。 GC 无法回收本机内存。 使用本机内存的 .NET 对象必须使用本机代码进行释放。
.NET 提供了?IDisposable?接口,使开发人员能够释放本机内存。 即使未调用?Dispose,正确实现的类也会在终结器运行时调用?Dispose
。
PhysicalFileProvider?是托管类,因此任何实例在请求结束时都会被回收。
?
运行压力测试工具后可以看到内存使用及GC运行情况:
?
上面的图表显示此类的实现存在一个明显问题,它会不断增加内存使用量,这是因为忘记调用应释放的相关对象的?Dispose
?方法
我改一下这个接口,使用using调用Dispose
?:
private static readonly string TempPath = Path.GetTempPath();
[HttpGet("fileprovider")]
public void GetFileProvider()
{
using (var fp = new PhysicalFileProvider(TempPath))
{
fp.Watch("*.*");
}
}
?
可以看到内存得到了稳定的释放,GC调用也相对稳定
频繁的内存分配/释放周期可能会导致内存碎片,尤其是在分配大型内存区块时。 对象在连续内存块中进行分配。 为了减少碎片,当 GC 释放内存时,它会尝试对其进行碎片整理。 此过程称为压缩。 压缩涉及移动对象。 移动大型对象会造成性能损失。 因此,GC 会为大型对象创建特殊内存区域,称为大型对象堆?(LOH)。 大于 85,000 字节(大约 83 KB)的对象:
当 LOH 已满时,GC 会触发第 2 代回收。 第 2 代回收:
下面的代码会立即压缩 LOH:
GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect();
在使用 .NET Core 3.0 及更高版本的容器中,LOH 会自动压缩。
我们来看下一个api:
[HttpGet("loh/{size=85000}")]
public int GetLOH1(int size)
{
return new byte[size].Length;
}
用压力测试工具调用?/api/loh/84975 这个接口
换一下对象大小?调用?/api/loh/84976?这个接口
比较上面两个图表
?84,976 字节会就触发了 85,000 限制
所以临时大型对象有性能问题,因为它们会导致第 2 代 GC。
为了获得最佳性能,应最大程度减少大型对象使用。 如果可能,请拆分大型对象。 例如,ASP.NET Core 中的响应缓存中间件会将缓存项拆分为小于 85,000 字节的块。