Loading

在物理内存中观察CLR托管内存及GC行为

虽然看了一些书,还网络上的一些博文,不过对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的地址
 
 
 
这个就是 NextObjPtr 了  (这个也只是推测,根据后面的操作发现新增对象末尾地址总是002BFB
48里面的数据,以及之前的反复测试前面的类型指针也是匹配的,但测试结果并不是每次这个类型指针都是这个值,并且在不同系统版本下差距非常大)
后面的操作大家可以看到它的确就是NextObjPtr ,整个内存块里存着这个地址的位置也只有这里)【在托管堆中维护着一个NextObjPtr指针,指向下一个新建对象分配时在托管堆中所处的位置】
 

第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的指针(可以推断他们确实是在一张“表”上)
 
 
 
现在看下刚刚找到的NextObjPtr里面的数据是多少(02486988),下面我们看下这个地址里是什么
 
 
 
可以看到就指向了最后分配的bytesStart地址的后面
每个引用对象后面都有8个全0的字节(多次测试,反复分析数据都是这样)
 

监测点3 (为了验证刚刚的NextObjPtr的确是那块内存)
 
 
到第3步,可以直观的看到bytesThen就直接使用了刚刚NextObjPtr后面指向的内存,
 
 
 
 
同时也看到NextObjPtr指示下的一片内存(这个时候对A0 6D 48 02 的搜索也证明内存里只有这么一块存的是这个数据)
而且可以看到这个地址确实就是bytesThen后面的内存地址
 

第4监测点 (重复创建10分份的typeA)
 
 
这次直接使用类型对象指针搜索新创建的10份TypeA (可能会搜索出其他数据,因为内存里有其他程序及测试前几次运行残留的数据)
可以看到这些TypeA直接分配在了bytesThen的后面(测试中尽量少使用终端打印。终端打印虽然1行代码,不过clr会创建很多对象去完成打印,不方便观察)
 
 
 
 
现在想知道这些TypeA的指针,却发现内存里根本没有这个地址(后面9个的结果一样)
甚至连里面的TypeB的指针也搜索不到
 
其实这些TypeA从一创建即为不可达,因为后面再也没有用到它们的地方,即一开始就没有任何对象引用过他们,在引用跟踪里一直被作为垃圾
 
 
 
这个时候NextObjPtr 已经指向了02487520
 

监测点5 (出RunCreat)
 
 
 
出RunCreat()这个方法回到RunTest()里,NextObjPtr指向依然没有变化(没有新的对象创建)。
 

监测点6 (回收G0)
 
 
执行完G0回收后 ,NextObjPtr直接变为了全0 (其实后面还有跟的8个字节的数据也变为了0,这8个字节可能为G0阀值)
 
 
 这里有个疏忽,本来先要监测a1的回收,现在发现后面的代码残留上一次的测试代码错误的把a1引用了, 所以要到这一行结束a1是垃圾
 
 
 
经过G0回收后,bytesStart  bytesThen,应该移动到G1,不过看他们在内存里的位置并没有发生任何变化(内存里也只有这一份)
那10个在RunCreat创建的TypeA也似乎没有什么变化
 
关于书上的描述跟图例,似乎在GC完成后,G0向G1的代提升会移动内存,不过现在看来并没有移动内存(目前GC把85000字节的数据当作大对象,所以这里的bytesStart  也不是大对象)
 
 
那如果bytesStart  bytesThen是存活的,不能回收,那下一个NextObjPtr也一定紧接着在bytesThen后面
整个内存符合条件的也就这么一处(即使是搜索?? 6D 48 02 也只有这一块内存符合条件),虽然这块内存看起来没有什么特别的格式
 

监测点7 (下一个地址从什么地方开始分配)
 
 
 
可以看到bytes这个全a的数据真的是从刚刚推测的地址开始分配内存的,在RunCreat创建的TypeA也直接被覆盖了(确实被当作了垃圾)
 
 
 
NextObjPtr现在也正常的指向了bytes的后面
 

监测点8
 
 
 
 
数据确实在里面被改动了,而且bytesStart  bytesThen也的确处于G1
 

监测点9
 这次回收除了a1 其他的bytesStart  bytesThen bytes ,应该都会被回收
 
 
之前放着bytesStart  bytesThen bytes 指针的内存 数据已经被覆盖了,现在他们都被移动到另外一块内存
而a1 现在应该由g1提升到了g2
 
 
 
之前存放a1指针的地址也全部被覆盖了,在内存里搜索到4块新内存,其中一块还与前面的bytesStart  bytesThen 新指针放在一起
 
 
 
虽然现在NextObjPtr 现在不为0 ,但也明显被重置了 (因为打印的缘故,GC后马上创建了新的对象)
也很明显,并没有覆盖前面的内存,而是直接指向了后面的内存
 
 
现在来看刚刚被认为是标记GC后下一次分配内存的地址的的内存块,现在的地址02488A88,这个地址也十分合理,正好在两次NextObjPtr 的中间
标识这个地址的确是标记GC后 新NextObjPtr的初始值
 

监测结束

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

 

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

1:证明了NextObjPtr 的存在,也了解他的基本行为(其结构后面数据可能还包含G0阈值等其他数据)

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

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

4:对象从G0移动到G1,内存本身不会移动(可能记录对象的指针的表会有相应更新)

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

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

 

最后上面写了那么多,其实不单单就是为了看CLR物理内存,同样也是表达一种方法,用同样的方法也可以查看包括jvm在内的几乎所有进程的物理内存,同时winhex不仅可以查看,还拥有在运行时直接修改物理内存的能力。

 

posted @ 2017-02-27 03:31  lulianqi15  阅读(6975)  评论(16编辑  收藏  举报