【隨筆】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析構階段