1.概述

1.1 简介

内存管理一直都是一个让人比较头疼的东西，尤其是现在重度游戏越来越多，每一次卡顿、每一次内存增长对玩家来说都是一个比较差的体验。技术群里总是有人调侃，游戏开发久了人就会变成“GC怪”。事实上，在游戏开发过程中，随着功能的不停迭代，内存问题一直都不能松懈。 Unity 2018集成了正式版的 .NET 4.x 和 C#7.3 ，引入了ref return和ref locals，让值类型操作更加高效，UnsafeUtility让Unsafe编程和Native Memory操作更加方便。Unity 2019加入了增量式GC，减少了GC带来的卡顿问题。目前来说，虽然内存管理还是一个需要注意的问题，但是却比以往版本灵活易用了很多。 本文希望可以从原理出发，以逐步递进的方式讲解GC优化的问题，主要关注于逻辑代码方面，希望可以给大家带来一定的参考价值。

1.2 什么是GC

GC的全称是Garbage Collection，也就是垃圾回收，是一种自动管理堆内存的机制，管理堆内存上对象的分配和释放。 一般来说，程序比较常用的有三种内存管理方式。 第一种是手动管理，即像C/C++一样使用malloc/free或者new/delete来为对象分配释放内存。这种管理方法的优点就是速度快，没有任何额外的开销，缺点是必须追踪每一个对象的使用情况，很容易发生各种问题，比如内存泄漏、野指针和空悬指针等。 第二种方法是使用引用计数（Reference Count）。它的思想是对象创建出来后，维护一个针对该对象的计数，使用该对象的地方对该计数加1，使用完毕后再减1，当计数为0时，销毁该对象。这种方法可以看做是一种半自动的内存管理方式，优点是可以把分配和释放的开销分布在实际使用过程当中，速度也比较快，不过会存在一个循环引用的问题。引用计数是一种比较常用的内存管理方法，比如Unity中的物理引擎PhysX就是使用引用计数来管理各种对象的。 最后一种方法是本文的重点，即追踪式GC器（Tracing Garbage Collector），Unity使用的GC器是一种叫标记/清除（Mark/Sweep）的算法，它的思路是当程序需要进行垃圾回收时，从根（GC Root）出发标记所有可达对象，然后回收没有标记的对象，这是一种全自动的内存管理方法，程序员完全不用追踪对象的使用情况，也不存在循环引用无法回收的问题，而在Unity中，使用的是一种叫Boehm-Demers-Weiser的GC器，它有以下特点： Stop The World：即当发生GC时，程序的所有线程都必须停止工作，等GC完成才能继续，Unity不支持多线程GC，即使是Unity 2019后使用的增量式GC，在回收时也是要停掉所有线程。 不分代：.NET和Java会把托管堆分成多个代（Generation），新生代的内存空间非常小，而且一般来说，GC主要会集中在新生代上，这让每一次GC的速度也非常快，但是Unity的GC是完全不分代的，即只要发生GC，就会对整个托管堆进行GC（Full GC）。 不压缩：不会对堆内存进行碎片整理，如下图： 图片来源于Unity的官方示例图

不分代：

不压缩：

GC会造成托管堆出现很多这样的空白“间隙”，这些间隙不会合并，当申请一个新对象时，如果没有任何一个间隙大于这个新对象大小，堆内存就会增加。

1.2 为什么要优化GC

优化GC是指降低内存开销,而不是指垃圾回收的过程。

1.GC的触发会导致进程锁死,GC的内存越多,锁死的时间越多.

2.进程自动触发GC,具有不可控性.

1.3 影响GC性能的主要因素

影响GC速度的因素主要有两个： 可达对象数量 托管堆的大小 可达对象是指不会当次GC被回收的对象，减少此类开销的主要方法就是减少对象数量，参考以下实现方法：

class Item
{
      public int a;
      public short b;
}
Item[] items;

对于items数组，每一个元素都会产生一个对象。 而以下代码，不管a和b有多少个元素，数组都只有一个对象，这样就会减少对象数量。

class Item
{
      public int[] a;
      public short[] b;
}
Item item;

而优化托管堆大小主要通过以下几个方面： 减少临时分配：临时分配的内存会产生碎片。 减少内存泄漏：即再也用不到但是又因为存在对其引用无法回收的对象。

1.4 什么时候会触发GC

1.第一代(第0代?)内存不够的时候

2.系统内存不足

3.主动调用GC.Collect()（不是必定会触发）

1.5 容易产生GC的地方以及解决办法

1. New obj

通过复用内存解决：类型池，对象池，容器池。

 2. Boxing(装箱)

如：Dictionary使用枚举或者自定义结构体当做Key

 3. String操作

字符串操作带来的GC很难避免，应尽量避免使用gameObject.name和gameObject.tag。常用字符串使用全局字符串常量。高频率拼接显示字符串的界面可以考虑用ZString,比如大量倒计时界面。

4.匿名函数和闭包

第一次匿名函数会有124B的GC，引用了外部变量每次都会GC，但是并不好避免经常会在回调里面写匿名函数。

 5.委托滥用

同一个委托+=操作触发GC,需要将原来的内存拼接上新的内存,整块移动到新的内存块,GC成指数型增长。

 执行第一次：

 执行第二次：

6. 一些语法糖

2.类和结构

类和结构的区别以及装箱和拆箱，基本上都是老生常谈了，不过，在开发过程中，还是会产生一个疑问：我的数据该使用类还是结构？这个问题接下来的几个部分都会有涉及到。

2.1 如何估算对象和结构体的大小

结构是值类型，它的结构体实例是存放在栈或者堆中的。在栈中我们保有的是实例的值，所以每一次赋值，都会在栈中多赋值一份实例出来。结构体在内存中所占大小，就是其字段所占大小，但是，结构体的大小并不是简单的所有字段的大小相加，而是存在一个对齐规则，在默认的对齐规则中，基本类型字段是按照自身大小对齐的，如byte是按1字节对齐，int是按4字节对齐。如下面的结构体：

  struct S
  {
      byte b1;
  }

这个结构体的大小是1，如果在下面添加一个字段：

  struct S
  {
      byte b1;
      int i1;
  }

这个结构体的大小是8，因为int是4字节对齐的，所以只能从第四个字节开始。 如果再添加一个字段：

  struct S
  {
      byte b1;
      int i1;
      byte b2;
  }

这个结构体的大小是12，由于struct本身也是要对齐的，所以它的对齐规则是按照其中元素最大的对齐规则决定的。如当前这个结构体是按照i1的对齐规则决定的，也就是四字节对齐，不足四字节则不齐。如果想优化其大小，调整顺序如下，结构体的大小就变成了8。

  struct S
  {
      byte b1;
      byte b2;
      int i1;
  }

类是引用类型，它的对象实例存放在堆中，对象实例一定是会占用堆内存的，而在栈中，我们保有的是实例的引用，对象在堆内存中大概是如下图所示： 其中vtable是类的共有数据，包含静态变量和方法表（在Mono中，结构的静态变量也存放在vtable里，它是缓存在一个叫tablecache的哈希表当中的，而IL2CPP中类和结构的静态变量存在一个单独的类里）。Monitor是线程同步用的，这两个指针分别占用一个IntPtr.Size大小（32位中是4字节，64位中是8字节），再下面是所有字段，字段是从第9个字节或17个字节开始的，字段的对齐规则与结构体的对齐规则相同，区别是Mono中对象实例会把引用类型的引用摆在最前面。一个对象实例的大小（instance_size）就是IntPtr.Size * 2+字段所占大小，结构体被装箱后在堆内存的大小也一样。 通过调整字段顺序，可以优化对象和结构体大小，特别是有容器存放多个对象或结构体的，可以减少堆内存占用。 此外，我们还可以通过StructLayoutAttribute自定义类和结构字段的对齐方式。比如下面的结构体：

  [StructLayout(LayoutKind.Sequential, Pack = 1)]
  public struct S
  {
      byte b1;
      int i1;
      byte b2;
  }

该结构体强制按1字节对齐，所以它的大小就是6。

  [StructLayout(LayoutKind.Explicit)]
  public struct S
  {
      [FieldOffset(0)]byte b1;
      [FieldOffset(0)]int i1;
      [FieldOffset(1)] byte b2;
  }

这个结构体的大小是4，它实现了类似C/C++中union的类型，b1、b2与i1共用同一段内存，b1和b2也代表了i1的前两个字节。 注意，内存对齐是会考虑硬件优化的，使用StructLayout修改对齐方式有可能会降低性能。

2.2 装箱和拆箱

装箱和拆箱的过程很多文档都会有描述，这里就不再细说了。只说几个比较