.Net平台的GC垃圾回收

一、先了解下必备的知识前提

内存中的托管与非托管，可简单理解为：

托管：可借助GC从内存中释放的数据对象（以下要描述的内容点）

非托管：必须手工借助Dispose释放资源（实现自IDisposable）的对象

内存中有栈和堆的概念区分，仅简单说明：

栈：小型的，当前运行函数、值类型及指针等（这里不再详细阐述）

堆：存放数据对象实例的内存空间，GC清理的区域（以下要描述的内容点）

作者：[Sol·wang] - 博客园，原文出处：https://www.cnblogs.com/Sol-wang/p/14792628.html

二、.Net GC的简单描述

GC垃圾回收是对于内存堆的处理过程。

当一个应用程序进程创建时，会为此应用程序在物理内存堆中分配一块虚拟的连续性内存空间，以供应用程序后续运行时存放产生的数据对象实例。

GC是一个独立的进程，用来自动维护管理内存堆中的空间分配和释放。它通过一个或多个线程进行垃圾回收，默认启用后台线程垃圾回收。
（关于前台线程与后台线程，可参考其它）

三、.Net平台的GC垃圾回收，什么时候会被触发呢？

1、当被分配的堆中虚拟内存空间不够用时，系统会自动 压缩/回收/扩大 被分配的虚拟内存块，以适应新产生的数据对象存储。

2、当整个物理内存不够用时，系统会自动 压缩/回收 各个进程占用的内存空间，以适应新产生的数据对象存储。

3、当应用程序中手动触发GC回收时，GC按照手动指定的方式进行垃圾回收。

四、从作用域上 去理解堆中的代

先这样去理解吧

假设一个实例变量声明时的作用域较大，那它就不会马上被回收，因为作用域大的因素，有可能后续程序还会经常用到。

假设一个实例变量声明时的作用域较小，那它就有可能被优先回收，因为生存周期较短，过了作用域范围，此变量不会再被使用。

假设一个静态的或全局的作用域变量，那它通常不会被回收，因为这样的全局声明会在任意代码段长期被使用。

所以，为了更好的回收，结合上面的三个假设案例，堆中将各数据对象实例归纳为：0代、1代、2代

0代：存放临时或最新创建的数据对象实例。最常被回收的对象实例。

1代：存放一段时间内再次使用的数据对象实例，生命周期较长的数据对象实例。较少被回收的对象实例。

2代：存放常住内存的对象实例，如：静态类型，全局作用域等的对象实例。通常为应用程序退出后回收。

五、堆中对象 在代之间的转移：幸存者的提升

应用程序持续运行中，

新创建的对象首先被放在0代中，当运行一段时间后，有些变量超出了自己所在的作用域，不会再被使用，会被GC清理；

由于有些变量作用域大，当前还未超出自己所在的作用域，接下来可能还会被使用，所以GC不会清理；

0代中，有些数据对象实例会被GC清理，有些数据实例对象未被GC清理，那么，未被GC清理的数据对象实例，我们称它为幸存者。

此时，0代中的幸存者会被转移到1代中（想想上面提到1代存放的是哪类对象实例...）；

那么，以此类推，长期/处处被使用的对象实例，就会从1代中转移到2代中；

因此，2代中存放的通常为静态或全局作用域或长期被使用到的对象实例。

幸存和提升：

垃圾回收中未回收的对象也称为幸存者，并会被提升到下一代：

• 第 0 代垃圾回收中未被回收的对象将会升级至第 1 代。
• 第 1 代垃圾回收中未被回收的对象将会升级至第 2 代。
• 第 2 代垃圾回收中未被回收的对象将仍保留在第 2 代。

六、GC是如何去确定要清理的对象实例？

GC在堆中生成各对象间的结构图，作为回收对象的依据，找出非活动的对象。

所有数据对象实例之间的关联引用关系，都会生成一个完整的结构图，一些不在结构图中的 或超出所在作用域的 或不再被继续使用的对象实例，被称为非活动对象。被视为GC要清理的对象。

准确的说，依据：

• 堆栈根
• 垃圾回收句柄
• 静态数据

七、手动GC垃圾回收

在某些不常见的情况下，强制回收可提高应用程序的性能。在此，可使用 GC.Collect 方法强制执行垃圾回收，从而诱导垃圾回收。

注意，是诱导，而不是即刻回收。

为了考虑到应用程序当前的稳定运行，执行GC.Collect并不一定及时产生效果，它需要一个过程，这里仅仅是一个触发，会去收集将要回收的对象，回收动作会在未来某个合适的时间段进行。（当然，也可以强制阻塞式回收，这里略过）

（思考一下：无用的实例=null，造成堆中无主的废数据，再执行GC.Collect()后的效果？）

关于 GC.Collect 方法的参数，会用到上面提到的概念及场景：

• 对指定的代进行回收
• 指定回收次数
• 强制回收 或 择机回收
• 阻塞式回收 或 后台线程回收
• 压缩 或 回收

（阻塞式回收方式：都先停一停，先让我回收完）

当然，通常建议：0代，择机，后台回收（阻塞式风险太大，通常选择择机方式，具体自我考量）

至此，关于GC垃圾回收的叙述，基本已结束，下面是关于优化层面的内容。

八、内存堆中的弱引用

当应用程序正在执行使用的对象，GC是不可能回收的，那么，就认为应用程序对该对象具有强引用。

强引用：应用程序正在使用的对象实例，不能被GC回收。

弱引用：应用程序暂时没使用的对象实例，暂时可被GC定义为可回收的实例，在回收之前，也可被应用程序再次使用后变为强引用。

假设一个对象实例被GC清理后，后续又被再次用到的场景，就会重新创建对象实例；那如果这个对象实例又比较大，创建过程又比较繁琐耗时，这样的频繁创建... ...

当然还有优化的空间，所以，弱引用优化了以上场景。

弱引用的优点：对于频繁创建的大实例，弱引用可以做到一次创建多次使用，避免大对象实例多次创建的性能消耗。

（对于小对象使用弱引用，所带来的对对象管理上的性能消耗，是否值得？）

若要对某对象建立弱引用，使用要跟踪的对象实例创建 WeakReference。 然后将 Target 属性设置为该对象，将该对象的原始引用设置为 null。
（参考官方文档）

也就是说：我们可以自定义控制哪些对象实例要不要暂时不被GC垃圾回收。

九、多应用共享内存时的垃圾回收

当多个应用程序在一台主机同时运行时，对内存空间大小的分配，建议是灵活可变的，以达到各应用程序对内存利用的平衡及稳定性。

假设一台主机，其中部署着 应用A、应用B、应用C。应用A 占用内存空间为 20%；应用B 占用内存空间为 20%；应用C 占用内存空间为 30%；（剩余内存空间为系统本身所需占用）

一个场景：应用A 突然有一个显著的并发量的提升，原本分配给应用A的内存空间已经无法满足当前的应用负载开销，需要继续扩大内存空间；此时的应用B、应用C 处于比较空间的状态，对于内存的空间使用比较小；那么 系统可以自动根据实际状况来调整各应用在内存空间中的占比，压缩应用A与应用B的使用空间，之后产生的空闲空间再分配给应用A，以使得应用A能处理更多的并发量。

正如以下操作，如果启用 gcTrimCommitOnLowMemory 设置，垃圾回收器会计算系统内存负载，并在负载达到 90% 时进入修整模式。除非负载下降到不到 85%，否则会一直处于修整模式。

如果条件允许，垃圾回收器可以决定 gcTrimCommitOnLowMemory 设置对当前应用没有帮助并忽略它。

如下启用 gcTrimCommitOnLowMemory 的设置：

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <runtime>
        <gcTrimCommitOnLowMemory enabled="true"/>  
    </runtime>
</configuration>