c# HashSet的擴容機制需要注意的
一:背景
1. 講故事
自從這個純記憶體專案進了大客戶之後,搞得我現在對記憶體和CPU特別敏感,跑一點資料記憶體幾個G的上下,特別沒有安全感,總想用windbg抓幾個dump看看到底是哪一塊導致的,是我的程式碼還是同事的程式碼? 很多看過我部落格的老朋友總是留言讓我出一套windbg的系列或者視訊,我也不會呀,沒辦法,人在江湖飄,遲早得捱上幾刀,逼著也得會幾個花架子😄😄😄,廢話不多說,這一篇就來看看 HashSet 是如何擴容的。
二:HashSet的擴容機制
1. 如何檢視
瞭解如何擴容,最好的辦法就是翻看HashSet底層原始碼,最粗暴的入口點就是 HashSet.Add
從圖中可以看到最後的初始化是用 Initialize
的,而且裡面有這麼一句神奇的程式碼: int prime = HashHelpers.GetPrime(capacity)
;,從字面意思看是獲取一個質數,哈哈,有點意思,什麼叫質數? 簡單說就是隻能被 1 和 自身 整除的數就叫做質數,那好奇心就來了,一起看看質數是怎麼算的吧! 再次截圖。
從圖中看,HashSet底層為了加速預設定義好了 72 個質數,最大的一個質數是 719w,換句話就是說當元素個數大於 719w 的時候,就只能使用 IsPrime
方法動態計算質數,如下程式碼:
public static bool IsPrime(int candidate) { if ((candidate & 1) != 0) { int num = (int)Math.Sqrt(candidate); for (int i = 3; i <= num; i += 2) { if (candidate % i == 0) { return false; } } return true; } return candidate == 2; }
看完了整個流程,我想你應該明白了,當你第一次Add的時候,預設的空間佔用是 72 個預定義中最小的一個質數 3,看過我之前文章的朋友知道List的預設大小是4,後面就是簡單粗暴的 * 2 處理,如下程式碼。
private void EnsureCapacity(int min) { if (_items.Length < min) { int num = (_items.Length == 0) ? 4 : (_items.Length * 2); } }
2. HashSet 二次擴容探究
當HashSet的個數達到3之後,很顯然要進行二次擴容,這一點不像List用一個 EnsureCapacity 方法搞定就可以了,然後細看一下怎麼擴容。
public static int ExpandPrime(int oldSize) { int num = 2 * oldSize; if ((uint)num > 2146435069u && 2146435069 > oldSize) { return 2146435069; } return GetPrime(num); }
從圖中可以看到,最後的擴容是在 ExpandPrime
方法中完成的,流程就是先 * 2, 再取最接近上限的一個質數,也就是 7 ,然後將 7 作為 HashSet 新的Size,如果你非要看演示,我就寫一小段程式碼證明一下吧,如下圖:
2. 您嗅出風險了嗎?
<1> 時間上的風險
為了方便演示,我把 72 個預定義的最後幾個質數顯示出來。
public static readonly int[] primes = new int[72] { 2009191,2411033,2893249,3471899,4166287,4999559,5999471,7199369 };
也就是說,當HashSet的元素個數為 2893249 的時候觸發擴容變成了 2893249 * 2 => 5786498 最接近的一個質數為:5999471,也就是 289w 暴增到了 599w,一下子就是 599w -289w = 310w 的空間虛佔,這可是增加了兩倍多哦,嚇人不? 下面寫個程式碼驗證下。
static void Main(string[] args) { var hashSet = new HashSet<int>(Enumerable.Range(0,2893249)); hashSet.Add(int.MaxValue); Console.Read(); } 0:000> !clrstack -l 000000B8F4DBE500 00007ffaf00132ae ConsoleApplication3.Program.Main(System.String[]) [C:\4\ConsoleApp1\ConsoleApp1\Program.cs @ 16] LOCALS: 0x000000B8F4DBE538 = 0x0000020e0b8fcc08 0:000> !DumpObj /d 0000020e0b8fcc08 Name: System.Collections.Generic.HashSet`1[[System.Int32,System.Private.CoreLib]] Size: 64(0x40) bytes File: C:\Program Files\dotnet\shared\Microsoft.NETCore.App\5.0.0-preview.5.20278.1\System.Collections.dll Fields: MT Field Offset Type VT Attr Value Name 00007ffaf0096d10 4000017 8 System.Int32[] 0 instance 0000020e2025e9f8 _buckets 00007ffaf00f7ad0 4000018 10 ...ivate.CoreLib]][] 0 instance 0000020e2bea1020 _slots 00007ffaeffdf828 4000019 28 System.Int32 1 instance 2893250 _count 0:000> !DumpObj /d 0000020e2025e9f8 Name: System.Int32[] Size: 23997908(0x16e2dd4) bytes Array: Rank 1,Number of elements 5999471,Type Int32 (Print Array) Fields: None
而且最重要的是,這裡是一次性擴容的,而非像redis中實現的那樣漸進式擴容,時間開銷也是大家值得注意的
<2> 空間上的風險
這個有什麼風險呢?可以看一下:289w 和 599w 兩個HashSet的佔用空間大小,這也是我最敏感的。
static void Main(string[] args) { var hashSet1 = new HashSet<int>(Enumerable.Range(0,2893249)); var hashSet2 = new HashSet<int>(Enumerable.Range(0,2893249)); hashSet2.Add(int.MaxValue); Console.Read(); } 0:000> !clrstack -l OS Thread Id: 0x4a44 (0) 000000B1B4FEE460 00007ffaf00032ea ConsoleApplication3.Program.Main(System.String[]) [C:\4\ConsoleApp1\ConsoleApp1\Program.cs @ 18] LOCALS: 0x000000B1B4FEE4B8 = 0x000001d13363cc08 0x000000B1B4FEE4B0 = 0x000001d13363d648 0:000> !objsize 0x000001d13363cc08 sizeof(000001D13363CC08) = 46292104 (0x2c25c88) bytes (System.Collections.Generic.HashSet`1[[System.Int32,System.Private.CoreLib]]) 0:000> !objsize 0x000001d13363d648 sizeof(000001D13363D648) = 95991656 (0x5b8b768) bytes (System.Collections.Generic.HashSet`1[[System.Int32,System.Private.CoreLib]])
可以看到, hashSet1的佔用: 46292104 / 1024 / 1024 = 44.1M
, hashSet2 的佔用 : 95991656 / 1024 / 1024 = 91.5M
,一下子就浪費了: 91.5 - 44.1 = 47.4M
。
如果你真以為僅僅浪費了 47.4M 的話,那你就大錯特錯了,不要忘了底層在擴容的時候,使用新的 size 覆蓋了老的 size,而這個 老的 size 集合在GC還沒有回收的時候會一直佔用堆上空間的,這個能聽得懂嗎? 如下圖:
要驗證的話可以用 windbg 去託管堆上抓一下 Slot[] m_slots
和 int[] m_buckets
兩個陣列,我把程式碼修改如下:
static void Main(string[] args) { var hashSet2 = new HashSet<int>(Enumerable.Range(0,2893249)); hashSet2.Add(int.MaxValue); Console.Read(); } 0:011> !dumpheap -stat 00007ffaf84f7ad0 3 123455868 System.Collections.Generic.HashSet`1+Slot[[System.Int32,System.Private.CoreLib]][]
這裡就拿 Slot[] 說事,從上面程式碼可以看到,託管堆上有三個 Slot[] 陣列,這就有意思了,怎麼有三個哈,是不是有點懵逼,沒關係,我們將三個 Slot[] 的地址找出來,一個一個看。
0:011> !DumpHeap /d -mt 00007ffaf84f7ad0 Address MT Size 0000016c91308048 00007ffaf84f7ad0 16743180 0000016c928524b0 00007ffaf84f7ad0 34719012 0000016ce9e61020 00007ffaf84f7ad0 71993676 0:011> !gcroot 0000016c91308048 Found 0 unique roots (run '!gcroot -all' to see all roots). 0:011> !gcroot 0000016c928524b0 Found 0 unique roots (run '!gcroot -all' to see all roots). 0:011> !gcroot 0000016ce9e61020 Thread 2b0c: 0000006AFAB7E5F0 00007FFAF84132AE ConsoleApplication3.Program.Main(System.String[]) [C:\4\ConsoleApp1\ConsoleApp1\Program.cs @ 15] rbp-18: 0000006afab7e618 -> 0000016C8000CC08 System.Collections.Generic.HashSet`1[[System.Int32,System.Private.CoreLib]] -> 0000016CE9E61020 System.Collections.Generic.HashSet`1+Slot[[System.Int32,System.Private.CoreLib]][]
從上面可以看到,我通過 gcroot 去找這三個地址的引用根,有兩個是沒有的,最後一個有的自然就是新的 599w 的size,對不對,接下來用 !do 打出這三個地址的值。
0:011> !do 0000016c91308048 Name: System.Collections.Generic.HashSet`1+Slot[[System.Int32,System.Private.CoreLib]][] Size: 16743180(0xff7b0c) bytes Array: Rank 1,Number of elements 1395263,Type VALUETYPE (Print Array) Fields: None 0:011> !do 0000016c928524b0 Name: System.Collections.Generic.HashSet`1+Slot[[System.Int32,System.Private.CoreLib]][] Size: 34719012(0x211c524) bytes Array: Rank 1,Number of elements 2893249,Type VALUETYPE (Print Array) Fields: None 0:011> !do 0000016ce9e61020 Name: System.Collections.Generic.HashSet`1+Slot[[System.Int32,System.Private.CoreLib]][] Size: 71993676(0x44a894c) bytes Array: Rank 1,Type VALUETYPE (Print Array) Fields: None
從上面的 Rank 1,Number of elements
資訊中可以看到,原來託管堆不僅有擴容前的Size :2893249
,還有更前一次的擴容Size: 1395263
,所以按這種情況算: 託管堆上的總大小近似為: 23.7M + 47.4M + 91.5M = 162.6M
,我去,不簡單把。。。 也就是說:託管堆上有 162.6 - 91.5 =71.1M
的未回收垃圾 ➕ 剛才的 47.4M 的空間虛佔用,總浪費為:118.5M
,但願我沒有算錯。。。
3. 有解決方案嗎?
在List中大家可以通過 Capacity
去控制List的Size,但是很遺憾,在 HashSet 中並沒有類似的解決方案,只有一個很笨拙的裁剪方法: TrimExcess
,用於將當前Size擴充套件到最接近的 質數 值, 如下程式碼所示:
public void TrimExcess() { int prime = HashHelpers.GetPrime(m_count); Slot[] array = new Slot[prime]; int[] array2 = new int[prime]; int num = 0; for (int i = 0; i < m_lastIndex; i++) { if (m_slots[i].hashCode >= 0) { array[num] = m_slots[i]; int num2 = array[num].hashCode % prime; array[num].next = array2[num2] - 1; array2[num2] = num + 1; num++; } } }
應用到本案例就是將 289w 限制到 347w,仍然有 58w的空間佔用。 如下圖:
三: 總結
HashSet的時間和空間上虛佔遠比你想象的大很多,而且實佔也不小,因為底層用到了雙陣列 m_slots
和 m_buckets
,每個Slot還有三個元素: struct Slot { int hashCode;internal int next;internal T value; }
所以瞭解完原理之後謹慎著用吧。
以上就是c# HashSet的擴容機制需要注意的的詳細內容,更多關於c# HashSet 擴容機制的資料請關注我們其它相關文章!