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, Number of elements 5999471, 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; }，因此瞭解完原理以後謹慎着用吧。

---

如您有更多問題與我互動，掃描下方進來吧~

---