从零手撸C#泛型集合：比List＜T＞更轻量的实现方案

从零手撸C#泛型集合：比List 更轻量的实现方案

在追求极致性能的C#开发场景中，我们常常会不满足于标准库提供的通用解决方案。List<T>无疑是日常开发中最常用的集合类型，它功能强大、接口丰富，但这份“强大”背后也意味着一定的开销。当你需要处理海量数据、构建底层框架，或者在资源受限的嵌入式环境中运行时，List<T>的通用性设计有时会显得“臃肿”。你是否想过，如果亲手打造一个专为特定场景优化的轻量级集合，性能能提升多少？内存占用又能减少几何？

这篇文章就是为那些不满足于“够用就好”，渴望深入理解集合内部机制，并愿意为性能提升付出实践的高阶开发者准备的。我们将抛开System.Collections.Generic的“黑盒”，从零开始，一步步设计并实现一个线程安全的轻量级泛型集合。这个过程不仅是一次编码练习，更是一次对内存布局、迭代器模式、并发控制等核心概念的深度探索。你会发现，理解“轮子”如何制造，远比单纯使用“轮子”更能让你在面试和实际项目中游刃有余。

1. 剖析List ：知其然，更要知其所以然

在动手造轮子之前，我们必须先彻底理解现有的“轮子”——List<T>。很多人对它的认知停留在“动态数组”层面，但这远远不够。通过查阅.NET Runtime的源码（例如在source.dot.net上），我们可以一窥其内部构造。

List<T>内部维护了一个T[] _items数组和一个int _size计数器。其“动态”特性源于当容量不足时，会调用EnsureCapacity方法，通常以翻倍（_items.Length * 2）的策略分配新数组并拷贝旧数据。这个策略在通用场景下平衡了性能与内存，但并非没有代价。

注意：频繁的扩容操作，特别是当集合增长到很大时，会导致多次大规模的内存分配和数组拷贝，这是List<T>在特定高性能场景下的主要瓶颈之一。

除了扩容开销，List<T>为了提供丰富的功能（如AsReadOnly,FindAll,ConvertAll等），其方法实现中包含了许多边界检查、版本号校验（用于在枚举时检测集合是否被修改）等安全措施。这些措施对日常开发是福音，但在你完全掌控数据流、且对性能有极致要求的场景下，就可能成为不必要的负担。

让我们用一个简单的表格对比一下List<T>的通用设计与我们即将打造的自定义集合的目标差异：

理解了这些差异，我们就能有的放矢地进行设计。我们的目标不是复刻一个List<T>，而是打造一个在特定约束下表现更优的专用工具。

2. 设计蓝图：定义我们的轻量级集合LightList<T>

明确了目标，我们开始绘制蓝图。我们将这个集合命名为LightList<T>。它的核心设计哲学是：在保证基础功能正确的前提下，做最大程度的简化与优化。

首先，我们定义其核心字段和属性。与List<T>类似，我们需要一个内部数组和大小计数器，但我们可以更激进一些。

public class LightList<T> { // 内部数组，存储元素 private T[] _items; // 当前集合中元素的数量 private int _count; // 用于同步的锁对象（为实现线程安全准备） private readonly object _syncRoot = new object(); // 可配置的扩容因子，默认1.5倍，比List的2倍更节省内存 private const double GrowthFactor = 1.5; private const int DefaultCapacity = 4; public int Count => _count; public int Capacity => _items.Length; public LightList(int initialCapacity = DefaultCapacity) { if (initialCapacity < 0) throw new ArgumentOutOfRangeException(nameof(initialCapacity)); _items = new T[initialCapacity]; _count = 0; } }

这里有几个关键设计点：

1. 初始容量可配置：允许使用者根据预估数据量进行初始化，避免早期频繁扩容。
2. 更温和的扩容因子：我们使用1.5而不是2.0作为默认扩容因子。这是一个权衡，2倍扩容能减少扩容次数但可能浪费更多内存；1.5倍在内存利用上更经济，但扩容稍频繁。这个因子甚至可以做成可配置的。
3. 显式的同步根：我们提前声明了_syncRoot，为后续实现线程安全版本做好准备。.NET框架中一些古老集合（如ArrayList）也采用此模式，它比锁定整个集合实例（lock(this)）更安全。

接下来是核心的Add方法。这是性能的关键路径之一。

public void Add(T item) { // 检查容量，不足则扩容 if (_count == _items.Length) { // 计算新容量，确保至少增长1个位置 int newCapacity = Math.Max(_items.Length + 1, (int)(_items.Length * GrowthFactor)); // 对于超大数组，考虑限制最大增长，这里简单处理 Array.Resize(ref _items, newCapacity); } _items[_count] = item; _count++; }

我们的Add方法极其简洁，移除了List<T>中用于快速路径检查的IList接口实现等逻辑。Array.Resize方法内部会创建新数组并拷贝，对于我们的轻量级目标，暂时可以接受。在更极致的优化中，我们可能会自己管理数组的分配和拷贝。

3. 实现线程安全：细粒度锁与无锁编程的权衡

线程安全是高性能集合无法回避的话题。List<T>本身不是线程安全的，这意味着在多线程环境下同时进行读写操作会导致状态不一致甚至程序崩溃。我们的LightList<T>可以选择提供线程安全的版本。

最简单的方式是使用粗粒度锁，即在每个公共方法入口加锁：

public void AddThreadSafe(T item) { lock (_syncRoot) { Add(item); // 调用非线程安全的内部方法 } }

这种方式实现简单，但并发度低，任何时刻只有一个线程能操作集合。对于写多读少的场景，这可能成为瓶颈。

我们可以尝试细粒度锁。一种思路是借鉴并发集合的设计，例如只对可能修改内部数组结构的操作（如Add导致扩容、RemoveAt）进行加锁，而对于单纯的读取（如Get）或不会引发结构变更的写入（如Set到已有索引）进行无锁操作。但这需要非常小心地处理内存可见性和操作原子性。

提示：在C#中，对int、bool等基础类型的简单读写通常是原子性的，但并不意味着线程安全。一个线程在读取_count的同时，另一个线程可能正在修改它和_items数组，这会导致读取到不一致的状态。

更高级的做法是探索无锁编程。例如，我们可以尝试用Interlocked类原子地操作_count，并使用循环和CompareExchange来实现无锁的添加。但这对于涉及数组扩容的场景异常复杂，极易出错。

对于大多数实际场景，我个人的经验是：如果对并发性能要求极高，直接使用System.Collections.Concurrent命名空间下的专业并发集合（如ConcurrentBag<T>、ConcurrentQueue<T>）通常是更明智的选择。它们由微软的专家精心优化和测试过。我们自制集合的线程安全版本，更多是作为一种学习和理解并发原理的实践。

因此，在我们的LightList<T>中，我们可以提供一个Synchronized包装器，或者通过一个bool标志位在构造时选择是否启用线程安全模式（内部使用粗粒度锁）。这给了使用者选择的灵活性。

public class LightList<T> { private readonly bool _isSynchronized; // ... 其他字段 public LightList(int initialCapacity = DefaultCapacity, bool isSynchronized = false) { // ... 初始化 _isSynchronized = isSynchronized; } private void MaybeLock(Action action) { if (_isSynchronized) { lock (_syncRoot) { action(); } } else { action(); } } public void Add(T item) { MaybeLock(() => { // 原有的Add逻辑 if (_count == _items.Length) { /* 扩容 */ } _items[_count] = item; _count++; }); } }

4. 迭代器模式与零分配枚举

foreach循环是C#中遍历集合的标准方式，它依赖于集合公开的GetEnumerator方法。List<T>的枚举器是一个结构体（struct），这意味着在栈上分配，避免了堆内存分配（即“零分配”），这对性能敏感代码和避免GC压力至关重要。

我们的LightList<T>也必须实现IEnumerable<T>和IEnumerator<T>接口来支持foreach。关键在于，我们要让枚举器也是一个结构体。

首先，我们实现一个嵌套的结构体枚举器：

public struct Enumerator : IEnumerator<T> { private readonly T[] _items; private readonly int _count; private int _index; internal Enumerator(T[] items, int count) { _items = items; _count = count; _index = -1; // 初始位置在第一个元素之前 } public T Current { get { // 简单的边界检查，由于我们内部控制，这里比List的检查更轻量 if (_index < 0 || _index >= _count) throw new InvalidOperationException(); return _items[_index]; } } object IEnumerator.Current => Current; public bool MoveNext() { int newIndex = _index + 1; if (newIndex < _count) { _index = newIndex; return true; } return false; } public void Reset() => _index = -1; // 结构体枚举器通常没有需要释放的非托管资源，Dispose留空即可 public void Dispose() { } }

然后，在LightList<T>类中实现GetEnumerator方法：

public Enumerator GetEnumerator() { return new Enumerator(_items, _count); } // 显式实现接口方法，通常就调用上面的方法 IEnumerator<T> IEnumerable<T>.GetEnumerator() => GetEnumerator(); IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();

现在，当用户使用foreach (var item in myLightList)时，编译器会调用返回结构体的GetEnumerator()方法，整个过程在栈上完成，没有堆分配。这是实现高性能集合的一个关键技巧。

你可能会注意到，我们的枚举器没有像List<T>那样包含一个版本号字段来在集合被修改时抛出异常。这是我们在“安全性”和“极致性能”之间做出的一个选择。如果你需要这个功能，可以在LightList<T>中增加一个int _version字段，每次修改集合时递增它，并在枚举器中捕获创建时的版本号，在MoveNext或Current中进行检查。

5. 内存布局优化与进阶技巧

到了这一步，我们已经有了一个可用的、比List<T>更轻量的基础集合。但对于追求极致的开发者，我们还可以深入内存层面进行优化。

1. 使用Span<T>和Memory<T>：.NET Core及更高版本引入了Span<T>和Memory<T>，它们提供了对连续内存区域的统一、安全且高性能的抽象。我们的LightList<T>内部可以改用Memory<T>来管理内存，这为与新的API（如管道Pipelines、IO操作）集成提供了更好的兼容性。Add方法中的扩容可以变为对Memory<T>的重新分配。

2. 结构体泛型约束：如果我们的集合明确只用于存储值类型（struct），我们可以添加泛型约束where T : struct。这允许编译器进行更多优化，并且完全避免了装箱/拆箱操作。我们甚至可以针对特定的值类型（如int,double）通过条件编译生成特化版本，实现类似C++模板的效果。

3. 池化数组：频繁的扩容和垃圾回收是性能杀手。在超高吞吐量的场景下，可以考虑使用数组池。System.Buffers.ArrayPool<T>.Shared提供了一个共享的数组池，我们可以从池中租用（Rent）数组，用完后归还（Return）。这极大地减少了GC压力。

private T[] _items; private bool _usesArrayPool; public LightList(bool useArrayPool = false) { _usesArrayPool = useArrayPool; if (useArrayPool) { _items = ArrayPool<T>.Shared.Rent(DefaultCapacity); } else { _items = new T[DefaultCapacity]; } } private void Resize(int newCapacity) { T[] newArray; if (_usesArrayPool) { newArray = ArrayPool<T>.Shared.Rent(newCapacity); Array.Copy(_items, newArray, _count); ArrayPool<T>.Shared.Return(_items); // 归还原数组 } else { newArray = new T[newCapacity]; Array.Copy(_items, newArray, _count); } _items = newArray; }

4. 内联与激进优化：对于Get、Set这类极其简单的方法，我们可以考虑使用[MethodImpl(MethodImplOptions.AggressiveInlining)]特性提示JIT编译器进行内联优化，减少方法调用的开销。但这把双刃剑需要谨慎使用，并最好通过性能测试来验证效果。

经过这一系列从设计到实现，再到深度优化的探索，我们得到的不仅仅是一个可替代List<T>的轻量集合，更是一套应对高性能、特定场景需求的方法论。在实际项目中选择使用标准库还是自研轮子，需要权衡开发成本、维护成本与性能收益。但对于框架开发者、游戏引擎程序员或基础设施工程师而言，这种“造轮子”的能力和背后的思考深度，往往是解决棘手性能问题的关键。下次当你面对性能剖析器上List<T>占据的热点路径时，或许可以自信地考虑，是否到了需要亲手打造一把更称手工具的时候了。