虽然看了一些书，还网络上的一些博文，不过对CLR托管内存细节一直比较模糊。而且因为工作原因总会有很多质疑，想要亲眼看到内存里二进制数据的变化。

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

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

内存查看工具: winhex 7.5

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

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

进行之前需要先简单了解CLR对象分配（类型对象指针要知道），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里面（即他的回收确实也只能靠根搜索）