一文看懂C#中List的扩容机制

可以清楚的看到,一个int[] 占用 16777240 byte /1024/1024 =16M，一个 int[] 占用 33554456 byte/1024/1024 =32M,可这是翻倍的空间哈。

2. 真的以为是仅仅翻了一倍吗？

为什么我要这么说呢？仔细看看Capacity的Set实现，如下代码：

public int Capacity
{
	get{ return _items.Length; }
	set
	{
		if (value > 0)
		{
			T[] array = new T[value];
			if (_size > 0)
			{
				Array.Copy(_items, 0, array, 0, _size);
			}
			_items = array;
		}
	}
}

大家仔细研读，这个流程是先定义好新size的数组array，然后将老的数组(_items) copy到 新数组array中，然后将array的引用给了老的数组,不难看出真正的Size应该是 array(32M) + _items（16M） =48M 才是真正的大小，只要GC没有回收老的_items(16M)那就一直保持48M的大小，你说呢？

要怎么验证呢? 大家可以用windbg去看看托管堆中 int[] 不就可以啦。

var list1 = Enumerable.Range(0, (int)Math.Pow(2, 22)).ToList();
list1.Add(1);

0:000> !DumpHeap -mt 00007ffde2ac8538 -min 102400
  Address  MT Size
0000024c103e9ba0 00007ffde2ac8538 4194328 
0000024c107e9bd8 00007ffde2ac8538 8388632 
0000024c10fe9c10 00007ffde2ac8538 16777240 
0000024c11fe9c48 00007ffde2ac8538 33554456 

Statistics:
  MT Count TotalSize Class Name
00007ffde2ac8538 4 62914656 System.Int32[]
Total 4 objects

从信息中看(16777240 + 33554456)byte = 48M，按照刚才的理论这个16777240的int[]应该是没有引用根的等待被GC回收，所以用!gcroot 把两个 int[] 都打印出来。

0:000> !gcroot 0000024c10fe9c10
Found 0 unique roots (run '!GCRoot -all' to see all roots).

0:000> !gcroot 0000024c11fe9c48
Thread 63dc:
 0000007b4abfee60 00007ffd85950938 ConsoleApp6.Program.Main(System.String[]) [C:dreamCsharpConsoleApp1ConsoleApp6Program.cs @ 28]
 rbp-38: 0000007b4abfee88
  -> 0000024c00002da0 System.Collections.Generic.List`1[[System.Int32, mscorlib]]
  -> 0000024c11fe9c48 System.Int32[]

Found 1 unique roots (run '!GCRoot -all' to see all roots).

可以看到：0000024c10fe9c10 确实是没有引用根，也就验证了其实真正的是48M，而不是32M，翻了2倍哦。。。有点小恐怖。

二： 如何压缩

1. 系统提供的压缩机制

回过头来看 Capacity 属性中的扩容机制，你只需要将Capacity设置与Count平齐，_items数组多余的虚占空间就给清掉了。

static void Main(string[] args)
 {
  var list1 = Enumerable.Range(0, (int)Math.Pow(2, 22)).ToList();
  list1.Add(1);
  list1.Capacity = list1.Count;

  Console.ReadLine();
 }

从图中可以看到，数组中的 8388608-4194305 =4194303 个int直接给灭掉了，优化了空间。