【随笔】CLR:向头对象（Object Header）迈进一大步！！！

前言

　　在我之前一篇随笔里（戳我），我们知道，一个引用类型的对象，包含了2个额外的开销，一个是头对象（object header），一个是MT。我们接下来看看头对象到底有多神秘。。。

Object Header中的布局

头对象共32位，每一位都有不同的用途

1. 当27位为1时：则0~26位存储的都是和thin lock相关的信息，其中还细分了3个范围用来存放不同的信息
2. 当27位为1时&26位为1时：则0~25位存储的都是对象的hash值
3. 当27位为1时&26位为0时：则0~25位存储的都是sync block index，指向的是sync block table

相关资料可参见：

https://mycodingplace.wordpress.com/2018/01/10/object-header-get-complicated/

https://www.markopapic.com/csharp-under-the-hood-locking/

https://github.com/dotnet/coreclr/blob/master/Documentation/botr/threading.md

Object Header常用的4个用途

1。线程同步

　　lock的时候会用到，（戳我），这里不再演示，不过下面我想用lldb来一探究竟。

先来看下我们的代码：

然后我们用lldb， attach进去看看

试了下，这个syncblk命令不可用，我们换一个

发现还真有2处地方，拥有锁，我们通过地址，继续剖析：

图中，第二个锁，就忽略了，应该是console程序用的，和本案例无关，我们只看第一把锁，这已经证明了当前执行线程中的内存中，存在一把锁，而且是thinlock，

被锁的对象，则是Person对象p1。好奇的你应该会问：thinlock又是什么鬼。我找了一些资料

https://devblogs.microsoft.com/premier-developer/managed-object-internals-part-2-object-header-layout-and-the-cost-of-locking/

https://mycodingplace.wordpress.com/2018/01/10/object-header-get-complicated/

2。Hash值存储

上代码

程序跑起来，然后找到person对象：

当我们调用了对象的gethashcode方法之后，clr会把这个对象的hash值，存储在对象头中：

我们把对象头中的前8位拿出来，0x0e97b065，然后转成2进制，得到1110100101111011000001100101，我们逐位代入到表格中：

由表格中可以得出，当前同步信息存储的这个值，符合BIT_SBLK_IS_HASH_OR_SYNCBLKINDEX：1 & BIT_SBLK_IS_HASHCODE：1

表示0~25位之间，存放的是该对象的hash值。我们把值取出来则为10100101111011000001100101，然后转化成10进制则为：43495525

刚好与我们打印出来的内容一致。

所以说，对象的头信息中还有存放Hash值的用途。

3。用于GC回收时的标记阶段

4。用于GC析构阶段