在内存中观察CRL托管内存及GC行为

虽然看了一些书，还网络上的一些博文，不过对CRL托管内存的介绍都不是十分清楚，大部分都是一样的，如果再要了解细节就十分困难了。

所以借助winhex直接查看内存以证实书上的描述或更进一步揣摩CRL托管内存的运作方式，这里写下来跟大家一起分享（由于自己这方面知识储备不太充足，下面的好多内容也是猜测，肯定有很对错误，希望了解的网友可以帮忙指正）

测试环境: windowsXP win10 win7 （dotnet4.0 Releases编译 ,下文截图为win7上的运行结果）

内存查看工具: winhex 7.5

虽然重点是监测二进制的内存，不过基本的测试代码还是要有的（测试是直接运行编译好的exe，没有使用调试模式，编译时要使用Releases，因为debug跟Releases在GC回收时对象是否可达的判断是不一样的）

下面对内存的查找部分看起来可能有点跳跃，因为是借助了反复测试得到的规律，很多过程没有赘述

进行之前需要先简单了解CRL对象分配（类型对象指针要知道），GC的基本过程（G0,G1,G2需要简单了解），二进制数据的存储（主要是大小端）

下图是测试中用到的引用对象的结构

下图为测试的主要步骤，会分8步进行，每一步也都标注出来了

 第1监测点

 

通过TestForGC_3对象里的值类型87564023523 （hex 146338F6E3 ，windows为小端存储，所以最后搜索E3 F6 38 63 14）

前面的78 41 9B 92 为32位类型对象指针 后面接着的是同步块索引 （如果是64位程序这2个数据则都将是64位）

 

 

根据前面TestForGC_3的地址70354802，我们在内存里搜索到了唯一的一个匹配项，说明这里一定是张表，这个指针指向了TestForGC_3的地址

 

 

这个就是 NextObjPrt 了  （这个也只是推测，根据后面的操作发现新增对象末尾地址总是002BFB

48里面的数据，以及之前的反复测试前面的类型指针也是匹配的，但测试结果并不是每次这个类型指针都是这个值，并且在不同系统版本下差距非常大）

后面的操作大家可以看到它的确就是NextObjPrt ，整个内存块里存着这个地址的位置也只有这里

 

---

第2监测点

 

 

按照顺序我们通过内存搜索先找到了a1的地址

这里顺便解析下对象（引用类型）在内存里的存储

最前面8字节为类型对象指针及同步块索引（每个32位，如果是64位应用则每个64位）

类型对象指针不是一成不变的，就是dotnet内置的类型也不能保证，这次运行是一个值（地址），另外一个实例运行起来可能是另外一个（地址） （这里的地址全部使用偏移地址）

后面接着的3个8字节数据发布是TypeA里3个引用类型变量的地址，可以看到第2个地址就紧接在下面（因为是一起分配的）

顺便看下string类型在内存里的存储

 

根据a1里面的存储的地址02483588，轻松定位到了“testtypea”字符串

同样与其他对象一样拥有类型对象指针，同步索引块，后面有4个字节的数据长度，然后后面跟数据

这也的确说明了string千真万确引用类型，毫无争议

最后TypeA里面还有一个引用对象TypeB，是一样的就不重复说了，不过TypeB的指针只存在a1里面（即他的回收确实也只能靠根搜索）

 

 

现在我们通过a1的位置，查找内存中含有其地址的内存，居然搜索到了5块内存，而且都靠的非常近

 

 

 

 

同样的方法搜索到bytesStart在内存里的地址

同样的结构类型指针，同步索引，后面跟8字节的长度，再后面就是数据

 

 

根据地址搜索bytesStart在内存里的指针，也只有1个（这种结果在同样环境下运行每次的表现都是已有的，不过在更换运行环境后就会有明显差异），而且也紧靠着a1的指针（可以推断他们确实是在一张“表”上）

 

 

现在看下刚刚找到的NextObjPrt里面的数据是多少（02486988），下面我们看下这个地址里是什么

 

 

可以看到就指向了最后分配的bytesStart地址的后面

每个引用对象后面都有8个全0的字节（多次测试，反复分析数据都是这样）

 

---

监测点3 （为了验证刚刚的NextObjPrt的确是那块内存）

 

到第3步，可以直观的看到bytesThen就直接使用了刚刚NextObjPrt后面指向的内存，

 

 

 

同时也看到NextObjPrt指示下的一片内存（这个时候对A0 6D 48 02 的搜索也证明内存里只有这么一块存的是这个数据）

而且可以看到这个地址确实就是bytesThen后面的内存地址

 

---

第4监测点 (重复创建10分份的typeA)

 

 

这次直接使用类型对象指针搜索新创建的10份TypeA （可能会搜索出其他数据，因为内存里有其他程序及测试前几次运行残留的数据）

可以看到这些TypeA直接分配在了bytesThen的后面（测试中尽量少使用终端打印。终端打印虽然1行代码，不过clr会创建很多对象去完成打印，不方便观察）

 

 

 

现在想知道这些TypeA的指针，却发现内存里根本没有这个地址（后面9个的结果一样）

甚至连里面的TypeB的指针也搜索不到

 

其实这些TypeA从一创建即为不可达，因为后面再也没有用到它们的地方，即一开始就没有任何对象引用过他们，在引用跟踪里一直被作为垃圾

 

 

 

这个时候NextObjPrt 已经指向了02487520

 

---

监测点5 （出RunCreat）

 

 

 

出RunCreat（）这个方法回到RunTest（）里，NextObjPrt指向依然没有变化（没有新的对象创建）。

 

---

监测点6 （回收G0）

 

 

执行完G0回收后 ，NextObjPrt直接变为了全0 (其实后面还有跟的8个字节的数据也变为了0，这8个字节可能为G0阀值)

 

 

 这里有个疏忽，本来先要监测a1的回收，现在发现后面的代码残留上一次的测试代码错误的把a1引用了， 所以要到这一行结束a1是垃圾

 

 

 

经过G0回收后，bytesStart  bytesThen，应该移动到G1，不过看他们在内存里的位置并没有发生任何变化（内存里也只有这一份）

那10个在RunCreat创建的TypeA也似乎没有什么变化

 

关于书上的描述跟图例，似乎在GC完成后，G0向G1的代提升会移动内存，不过现在看来并没有移动内存（目前GC把85000字节的数据当作大对象，所以这里的bytesStart  也不是大对象）

 

 

那如果bytesStart  bytesThen是存活的，不能回收，那下一个NextObjPrt也一定紧接着在bytesThen后面

整个内存符合条件的也就这么一处(即使是搜索?? 6D 48 02 也只有这一块内存符合条件)，虽然这块内存看起来没有什么特别的格式

 

---

监测点7 （下一个地址从什么地方开始分配）

 

 

可以看到bytes这个全a的数据真的是从刚刚推测的地址开始分配内存的，在RunCreat创建的TypeA也直接被覆盖了（确实被当作了垃圾）

 

 

NextObjPrt现在也正常的指向了bytes的后面

 

---

监测点8

 

 

 

 

数据确实在里面被改动了，而且bytesStart  bytesThen也的确处于G1

---

监测点9

 这次回收除了a1 其他的bytesStart  bytesThen bytes ，应该都会被回收

 

 

之前放着bytesStart  bytesThen bytes 指针的内存 数据已经被覆盖了，现在他们都被移动到另外一块内存

而a1 现在应该由g1提升到了g2

 

 

之前存放a1指针的地址也全部被覆盖了，在内存里搜索到4块新内存，其中一块还与前面的bytesStart  bytesThen 新指针放在一起

 

 

虽然现在NextObjPrt 现在不为0 ，但也明显被重置了 （因为打印的缘故，GC后马上创建了新的对象）

也很明显，并没有覆盖前面的内存，而是直接指向了后面的内存

 

 

现在来看刚刚被认为是标记GC后下一次分配内存的地址的的内存块，现在的地址02488A88，这个地址也十分合理，正好在两次NextObjPrt 的中间

标识这个地址的确是标记GC后 新NextObjPrt的初始值

 

---

监测结束

跳出RunTest，马上就执行了一次完全的GC

上面写的比较杂乱，虽然很对东西还是没有弄明白也没有发现什么规律，不过至少可以得到下面的一些结果

1：证明了NextObjPrt 的存在，也了解他的基本行为（其结构后面数据可能还包含G0阈值等其他数据）

2：GC回收使用的标记方法的确是根搜索

3：被回收的内存不会被擦除，只是通过移动NextObjPrt标记下一个内存能被分配的位置

4：对象从G0移动到G1，内存本身不会移动（可能记录对象的指针的表会有相应更新）

5：不是每次回收都会压缩内存，大部分时间都维持原有结构

6：对象在内存中的存储细节