前提条件：

要出现这种内存泄露，必须先准备一块任意的内存块：（无任何外部引用，理论上应该会在用完后被GC，但在该BUG下会错误的泄露，不被GC掉）

byte[] buffer = new byte[2097168];  // 内存起始地址：0xbe82f000，内存结束地址：0xde468c50 内存占用大小：2 MB

NOTE：大小任意，越大越容易被泄露。

一块struct结构的数组：（struct内必须有一个类似指针的值类型, 如int，和另一个引用类型，如string）

struct Slot {
    int hashCode;
    String value;
}
Slot[] slots = new Slot[5000];   // 内存起始地址：0xde45f000， 内存结束地址：0xde468c50， 内存占用大小：40016 B,

NOTE：大小任意，数组内的元素越多越容易触发泄露。例如 HashSet<String> 内部使用了该数据格式。

通过在GC中打点，和使用GDB调用GC过程，以便观察所有对象的分配和GC的过程发现：buffer对象错误的被slots对象引用，导致buffer对象无法被正常GC，造成内存泄露。

原因分析：

首先对于mono/il2cpp的Boehm GC库而言， mono/il2cpp的对象在分配内存的时候，会有几种类型：

NORMAL：无类型的内存分配，对于GC而言，因为无法得到对象的类型元数据，所以在做GC时会按指针对齐的方式扫描该内存块，只要发现类似通过指针校验的地址都会认为该对象引用了该指针地址指向的对象。
PTRFREE：无指针内存分配，明确告知GC，该对象内无任何指针信息，即在GC时无需查找该对象内是否引用其他对象。在mono/il2cpp中的int型的数组，byte型的数组，字符串等使用该类型的内存分配。
TYPED：有类型的内存分配，让GC知晓该对象的内存布局，在做GC时无需盲目的扫描内存查找引用的指针，而直接按照对象的内存布局查找指针地址，建立对象和对象之间的引用关系，在mono/il2cpp中的class类型的对象是使用该类型的内存分配。

而在本例中：slots的分配是用NORMAL类型，buffer对象的分配是用PTRFREE类型。

因此在做GC的时候，对于slots对象，GC会扫描该对象的内存区间，查找其内部的指针地址，即从0xde45f000到0xde468c50地址按照指针对齐的方式查找指针地址：
例如：0xde45f000 0xde464d44 0xde464f40 0xde46513c ....
其中出现了 0xde464f40 这个地址的值刚好为：0xbe82f000（即Slot结构体内hashCode的值），而GC会错误的将该int型数值当做指针，而该指针刚好又指向了一块GC托管的内存块，即buffer对象，因此GC认为该buffer对象被slots对象内部引用了，buffer对象也被GC标记，不会被释放。

4cc08e81ac33f9ddf066b1aa4f2d731.png

该问题的关键在于，GC将slot结构体内的hashcode这个int值错误的当做的指针，而该int值刚好又指向了另一个托管的对象，因此GC错认为了两个对象存在引用关系，而造成内存泄露。

最小化Demo：

public class NewBehaviourScript : MonoBehaviour {


    struct Slot
    {
        public int hashCode;
        public string value;
    }


    private static Slot[] slots = new Slot[5000];


    void Start () {
        for(var i = 0; i < slots.Length; ++i) {
            slots[i].hashCode = i * (1024 * 1023) + 1;
        }
     }


    void Update () {
        byte[] buffer = new byte[2 * 1024 * 1024]; // memory leak
    }
}

将struct Slot修改为class Slot，则可修复内存泄露问题，因为class对象的内存分配时TYPED类型。

因为Mono的GC的设计问题，Unity游戏中几乎不可避免的都会随着时间出现内存泄露问题，因为例如HashSet这种数据结构内部都会出现该问题。但我们可以做的事情，依然是内存使用的两大真理（特别是虚拟机类型的语言）：