1. 从一次深夜排查说起为什么要重新整理C#集合事情是这样的。前段时间帮朋友排查一个上位机软件的问题现象很典型设备每秒上报几百个数据点界面端用ListT做临时存储跑一会儿内存飙高、界面卡死。代码本身看不出大毛病数据也没丢就是慢、就是卡。后来把ListT换成QueueT再把批量刷新改成增量刷新问题直接消失。这事让我意识到很多人对集合的理解停留在“会用几个常用类”的层面但集合背后牵扯的是数据结构、内存分配、线程安全和GC压力这些才是决定程序能不能稳定跑起来的关键。C#里集合家族非常庞大——数组、List、Dictionary、HashSet、Queue、Stack、LinkedList、SortedDictionary还有一堆并发集合和只读集合每一个都不是随便拍脑袋选的。本文就把C#集合体系完整梳理一遍不仅讲“是什么”更讲“什么时候用”“为什么这么选”“踩过哪些坑”。不管你是刚接触C#的初学者还是已经写了两三年业务代码想补基础的老手这套梳理都能让你在集合选型这件事上不再靠感觉。2. 集合家族全景接口体系才是真正的“地图”2.1 为什么必须先搞懂IEnumerable而不是直接背类名很多人学集合是从ListT开始的这没错但如果你只看具体类很容易陷入“这俩类差不多嘛”的误区。实际上C#集合真正的地基是一整套接口体系理解了接口你就能一眼看穿每个集合的本质定位。最底层是IEnumerable和IEnumerableT。它们只承诺一件事这个对象可以被遍历。foreach能工作的原因就是编译器会把循环编译成对GetEnumerator()的调用。这个接口不保证元素数量、不保证随机访问、不保证能不能修改它仅仅是一个“能逐个拿出来”的约定。再往上是ICollectionT在遍历能力之上增加了Count、Add、Remove、Clear等操作相当于承诺“这是一个容量可知、可增删的容器”。IListT则在ICollectionT的基础上增加了索引访问能力——this[int index]、IndexOf、Insert、RemoveAt。IDictionaryTKey, TValue则代表另一条分支它不按位置存而是按键存。这个接口体系给我们的第一个实战启示是方法参数能接受IEnumerableT就尽量不要写死成ListT。我见过太多人写public void Process(ListData data)导致调用方明明有个HashSet或数组也得先.ToList()一下白白增加一次完整拷贝。改成IEnumerableT后调用方直接传内部只用foreach遍历这既是性能优化也是接口设计的基本修养。2.2 泛型集合与非泛型集合的历史包袱老代码里常看到ArrayList、Hashtable这哥俩在.NET 1.x时代是主力。它们的问题很明显内部存的是object往里放int会装箱拿出来要强转类型安全完全靠自觉。比如ArrayList里先放个int再放个string遍历时用(int)item强转直接抛异常。泛型集合从.NET 2.0开始全面替代它们ListT对应ArrayListDictionaryTKey, TValue对应Hashtable值类型不再装箱编译期类型检查也能挡掉大量低级错误。现在的实际建议是不需要再写非泛型集合了除非你在维护上古遗留代码或者在某些反射/动态场景下实在拿不到类型参数。我自己的原则是——新代码一律泛型遇到非泛型集合先怀疑是不是老系统没升级。2.3 数组、List、Collection和ReadOnlyCollection的定位区别T[]数组是CLR底层直接支持的类型内存连续、访问最快、无额外开销代价是长度固定扩容得自己新建数组再拷贝。ListT内部就是一个数组加扩容策略对开发者屏蔽了扩容细节适合绝大多数“动态长度”的场景。CollectionT可能很多人不熟它是ListT的一个可定制封装核心价值在于提供了InsertItem、RemoveItem、SetItem、ClearItems四个虚方法。如果业务要求在元素被添加/移除时自动触发某些逻辑——比如通知界面刷新、校验唯一性——继承CollectionT重写这几个方法比往每个调用点塞逻辑干净得多。ReadOnlyCollectionT则是把可变集合包一层壳对外只暴露读操作。注意它只是“禁止通过这个引用修改”底层原集合如果被改动壳里看到的也会变。想彻底不可变得配合ImmutableArrayT或ReadOnlyCollection加防御性拷贝。3. 高频集合逐个拆解原理、场景和性能特征3.1 List 的扩容机制与性能陷阱ListT是日常用得最多的集合但它内部有一个必须理解的机制——容量扩张。默认初始容量为0第一次Add时分配4个元素的数组之后每次容量不够就按当前容量的2倍扩容。扩容需要新建一个大数组把旧元素逐个拷贝过去然后旧数组交给GC回收。这意味着什么如果你知道最终数据量大概在1万条但让List从4开始一路倍增——4、8、16、32、64、128、256、512、1024、2048、4096、8192、16384——过程中发生了12次扩容和拷贝相对一次性分配1万容量的版本多出大量CPU和GC压力。正确做法是在构造时预估容量var list new ListData(10000);。另一个常见坑是RemoveAt(0)。List底层是数组删除头部元素后所有后续元素都要前移一位时间复杂度是O(n)。如果你经常从头部取数据——比如做任务队列——用ListT就是灾难换成QueueT才是正确姿势。判断依据很简单如果“从中间或头部增删元素”是高频操作List不是首选。3.2 DictionaryTKey, TValue的哈希原理与GetHashCode约定Dictionary是查找场景的默认选择增删查平均时间复杂度接近O(1)。它的核心是靠哈希表实现取键的GetHashCode()值映射到内部桶数组的索引碰撞时通过链表或开放寻址解决。C#内部实现混合了数组桶和链表冲突多时性能会明显下降——极端情况下所有键都哈希到同一桶查找退化成O(n)。用Dictionary有三条铁律。第一键对象必须正确重写Equals和GetHashCode规则是相等的对象必须返回相同的哈希码GetHashCode不应依赖可变字段否则键放进字典后字段一变哈希码变了这个条目就彻底找不到了。第二能用TryGetValue就不要用ContainsKey再[]取值避免两次哈希查找。第三确认键类型时优先考虑不可变类型——string、int、Guid都没问题自定义类型要格外谨慎。顺带提一个和字典强相关的场景热搜词里出现了“C#读power focus 6000扭矩值”“C#上位机通用框架”这类查询。这类设备数据的典型做法就是Dictionaryint, DeviceReading按设备ID或通道号索引然后用TryGetValue快速读取。查字典本身不慢真正拖垮性能的往往是字典里存的value对象太大、太多GC跟不上——下一步就是考虑对象池了。3.3 HashSet 去重和集合运算的利器如果你只需要判断“某个元素是否存在”不需要“由键找到值”那HashSetT比Dictionary更合适。它本质上是只存储键的哈希表同样接近O(1)的添加和查找但内存占用比Dictionary少一半还多。典型场景包括去重一批ID、判断新收到的数据是不是已经在处理队列里、做两个批次数据的交集/差集过滤。HashSetT还有一组很实用的集合运算方法UnionWith并集、IntersectWith交集、ExceptWith差集、SymmetricExceptWith对称差集。这组方法在处理多个摄像头回调里的设备ID管理、多来源数据合并去重时特别顺手。在使用上同样要遵守引用类型键的哈希码约定——去重判断依赖Equals和GetHashCode业务对象如果没重写这俩方法默认是引用比较容易得出“看起来一样但不重复”的结论。3.4 Queue 、Stack 和LinkedList 别再用List模拟它们QueueT是先进先出队列StackT是后进先出栈两者底层用数组实现Enqueue/Dequeue、Push/Pop都是O(1)。上位机里维护串口或网络接收缓冲天然适合QueueT接收线程往队列写处理线程从队列读中间解耦。注意这里有个线程安全问题——原生Queue不是线程安全的多线程读写需要加锁或用ConcurrentQueueT后面单独讲。LinkedListT是双向链表插入和删除节点是O(1)但随机访问是O(n)而且每个节点都有额外指针开销内存占用明显大于数组型集合。我坦白说业务代码里真正需要LinkedListT的场景非常少——LRU缓存、撤销/重做列表这类需要频繁在中间插入删除的场景才值得考虑。见很多人因为“看网上的文章说链表性能好”就在循环里对LinkedList做ElementAt(i)那真是拿链表的短处去对抗数组的长处性能只会更差。集合内部结构查找插入/删除适用场景T[]连续数组O(1) 索引O(n) 中间增删固定长度、极致性能List动态数组O(1) 索引O(n) 中间增删通用存储、尾部追加DictionaryK,V哈希表O(1) 平均O(1) 平均按键查找HashSet哈希表(仅键)O(1)O(1)去重、存在性判断Queue循环数组O(n)O(1) 两端FIFO缓冲、任务排队Stack数组O(n)O(1) 栈顶LIFO、回溯LinkedList双向链表O(n)O(1)(已知节点)频繁中间增删3.5 SortedDictionary与SortedList排序场景哪个更合适需要按键排序遍历时SortedDictionaryTKey, TValue和SortedListTKey, TValue都可行但内部实现完全不同。SortedDictionary基于红黑树插入删除O(log n)内存占用略大SortedList基于排序数组查找可以用二分O(log n)插入删除是O(n)但常数小数据量不大时反而更快。设计上的粗略判断是数据量小几百几千条、读多写少、希望内存紧凑选SortedList数据量大、写入删除频繁选SortedDictionary。两个都支持按键遍历时自动有序输出这和Dictionary的“不保证顺序”形成鲜明对比。顺带提醒一下普通Dictionary在.NET Core 3.0之后虽然实际插入顺序是保序的但这是实现细节不是语言规范永远不要依赖它。4. 并发集合多线程环境下的正确打开方式4.1 从ConcurrentDictionary到BlockingCollection上位机、采集系统、服务端程序几乎躲不开多线程读写集合。原生集合在并发写时会抛异常或产生脏数据——最典型的就是List多个线程同时Add导致数组越界异常。逐线程加锁是最原始的方案但锁粒度太大、竞争激烈时会成为瓶颈。.NET专门准备了一套并发集合放在System.Collections.Concurrent命名空间下。ConcurrentDictionaryTKey, TValue用细粒度锁和锁分段技术实现了线程安全的字典提供TryAdd、TryUpdate、GetOrAdd、AddOrUpdate等原子操作方法性能远好于外面套一个lock的普通字典。ConcurrentQueueT和ConcurrentStackT用无锁或轻量锁实现分别对应生产者消费者队列和并发栈模型。BlockingCollectionT则是更上层的封装默认基于ConcurrentQueue支持Add和Take当队列满时Add会阻塞空时Take会阻塞还支持在集合被标记为CompleteAdding后让消费线程自动退出。构建“采集线程多个处理线程”的上位机架构时这个类几乎就是标准答案。4.2 Channel 现代C#推荐的生产者消费者方案如果你在用.NET Core 3.0以上的版本我更推荐关注System.Threading.Channels命名空间下的ChannelT。它专门为生产者-消费者模式设计支持有界bounded和无界unbounded两种模式有界模式支持背压——生产者太快时WriteAsync会等待消费者跟上避免内存被无限堆积这一点在数据采集场景是保命级的。使用方式很简单var channel Channel.CreateBoundedbyte[](capacity: 1024); // 生产者 await channel.Writer.WriteAsync(data); // 消费者 await foreach (var item in channel.Reader.ReadAllAsync()) { Process(item); }相比BlockingCollectionChannel的API更现代、与异步编程配合更好ReadAllAsync可以直接用在await foreach里天然配合最新的C#异步流语法。做新项目时我默认用Channel除非团队对旧API更熟且不需要异步——那BlockingCollection也完全够用。4.3 小心不是“用了并发集合就万事大吉”并发集合保证的是“集合本身的线程安全”但它不保证“你的业务逻辑线程序安全”。举个例子两个线程同时执行dict.TryGetValue(key, out value)再根据结果决定是否dict.TryAdd这中间依然有竞态条件——判断在Add之前对方已经把数据加进去了。这种场景你得用GetOrAdd或者在外层再加锁让“读-判断-写”变成原子操作。还有一个容易忽略的问题并发集合里存的元素如果本身是可变的引用类型两个线程同时拿到同一个对象并修改其字段依然会互相踩踏。并发集合管的是“元素的增删查”管不了“元素内部状态的修改”。实践中要做到要么元素是不可变对象要么元素内部自带同步机制要么访问元素时额外加锁。5. 集合与LINQ别把整个集合装进内存5.1 延迟执行IEnumerable 的惰性求值怎么救性能LINQ的Where、Select、OrderBy等操作返回的是IEnumerableT关键特征是延迟执行——调用这些方法时并没有真的遍历数据真正执行要等到你foreach或调用ToList/ToArray的时候。这意味着你可以像搭流水线一样组合多个条件数据按需逐个流过管道。延展到集合场景我见过最典型的性能事故是数据库查了10万条记录拿到内存后先用Where过滤、再OrderBy排序、再Take(20)最后才用数据。正确做法是把过滤和下推尽量放到数据库SQL里实在不行也要注意——先Where再OrderBy再TakeCLR会尽量短路处理因为OrderBy必须知道全部数据才能排序但Where在前时Take可以在拿到足够元素后提前结束不需要枚举完整集合。5.2 Yield return自定义集合遍历的杀手锏想在自定义类型里支持foreach或者返回一个“按需计算”的集合序列用yield return是最优雅的写法。它本质上是由编译器生成一个状态机每次调用MoveNext()执行到下一次yield return为止。应用场景包括按页分批从外部服务拉数据并逐条返回、遍历一棵自定义树结构时避免一次性分配全量列表、生成无限序列比如斐波那契。public IEnumerableint GetValues() { for (int i 0; i 100; i) { yield return i * i; } }注意yield的返回值类型可以直接是IEnumerableT不必非得拼成ListT。很多人习惯在方法末尾.ToList()返回反而破坏了延迟执行的好处——调用方可能只取前3条你却把整个序列都算完了。5.3 ToList、ToArray、ToDictionary终止操作要谨慎LINQ以ToList()结尾意味着一次性枚举并构建一个完整集合。批量数据场景下ToList()可能瞬间分配大量内存触发多次GC。尤其是大对象堆LOH上的数组分配回收成本很高。如果后续逻辑只是只读遍历直接保留IEnumerableT或封装成ReadOnlyCollection更轻如果必须多次遍历ToList也好过一次遍历多次重算——因为IEnumerable被多次枚举会重新执行前面的逻辑如果前面是耗时的远程调用性能损失会翻倍。这背后的平衡点是惰性求值省内存但可能重复计算立即求值省CPU但占内存。项目里何时用哪个取决于管道前端代价高还是后端数据量大。绝大多数情况下我的选择是内存吃紧且只遍历一次用惰性数据量可控且会被多次访问转为List。6. 实战案例上位机数据采集中的集合应用6.1 设备列表管理从固定数组到字典的演进结合热搜词里反复出现的“C#上位机”场景我梳理一个很典型的设备管理需求现场有多个USB摄像头或传感器设备可能中途掉线重连界面需要实时显示每台设备的状态和最新读数。第一版用ListDeviceInfo存所有设备新数据来就Find(d d.Id id)更新。设备少没问题几十台时Find是O(n)线性查找每台设备每秒上报多次主线程轮询更新列表界面开始掉帧。第二版换成Dictionaryint, DeviceInfo按设备ID索引更新变为TryGetValueO(1)查找瞬间顺畅。再进一步如果设备上报顺序不固定、但同一种设备可能有多个实例用Dictionaryint, ConcurrentQueueReading按设备ID缓存最近N条读数处理线程从队列里取采集线程写入互不阻塞。这里还有一个细节设备的增删改查如果和界面刷新在同一个UI线程做高频更新会卡界面。常见手段是采集线程写集合UI线程用System.Windows.Forms.Timer或DispatcherTimer定时比如100ms一次从集合里批量读取快照去刷新界面。快照生成用ToArray()或ToList()把集合操作的耗时挡在UI线程之外。6.2 回调里区分多个摄像头Channel加字典组合热搜词里有一条很实际的问题——“C# directshow uvc 回调里区分多个摄像头”。用集合的思路去拆解解法其实就三步。第一步摄像头初始化时给每个设备分配一个唯一标识可能是指纹ID或端口序号存入Dictionaryint, VideoCapture键是设备标识值是采集对象。第二步在采集回调里拿到图像帧回调参数里带设备标识用TryGetValue确认设备有效后把帧数据写入该设备对应的Channelbyte[]或ConcurrentQueuebyte[]。第三步独立的处理任务对每个设备的channel做ReadAllAsync循环做图像处理或存储。这么做的好处是回调线程只做“快速入队”动作不在回调里做图像处理或UI更新避免了DirectShow回调线程阻塞导致的丢帧。框架层面还可以封装一个CameraManager内部维护设备字典和通道字典统一处理设备插拔、异常重连、资源释放——这套结构放在上位机通用框架里属于四梁八柱级别的基础设计。6.3 缓存最近N条数据环形缓冲还是Queue采集系统常常需要保留每台设备的最近N条数据方便界面画趋势图或故障分析。简单用List加if (count N) RemoveAt(0)是能跑但前文说过RemoveAt(0)是O(n)N越大越浪费。两个更合理的方案有限QueueTEnqueue时检查Count N就Dequeue再Enqueue操作都是O(1)代码直观。固定长度环形缓冲自建数组加读写指针性能和内存都最优但实现和维护成本高还需要处理读写指针重叠和线程安全。优先选队列数据量特别大且追求极致性能时才上环形缓冲。我见过的做法是如果还要应对多线程并发读写直接用ConcurrentQueue并配合Consumer线程定时把队列导出成快照比自己在队列外加锁更稳。7. 常见问题与排查技巧实录7.1 集合遍历时修改元素InvalidOperationException的根源“foreach里直接list.Remove(item)抛出InvalidOperationException”是新手最常撞的墙。原因是foreach依赖于集合的版本号——List内部维护_version字段任何结构性修改都会让版本号递增枚举器每次MoveNext时检查版本号是否一致不一致就抛错。正规改法有三种从后往前用for循环加RemoveAt先收集要删的元素再统一Remove用ListT.RemoveAll(predicate)一行搞定。注意RemoveAll会原地批量删除符合条件的元素内部做了优化比循环Remove快不少而且不会触发版本号异常。7.2 Dictionary键找不到频繁异常与Null安全用dict[key]取不存在的键会抛KeyNotFoundException在循环里频繁抛异常会对性能造成巨大影响——异常抛出和捕获的成本远高于普通判断。正确姿势是TryGetValue或者C# 8.0以后用dict.TryGetValue(key, out var value) ?? fallback这样优雅的写法再或者使用CollectionsMarshal.GetValueRefOrAddDefault这类高级API处理默认值场景。顺带提一个和“C#读power focus 6000扭矩值”类似的问题设备读不到值时会请求默认值。如果用TryGetValue失败就返回一个default没问题但要注意区分“设备确实没上报”和“上报了但值为0”两种情况——TryGetValue只回答“键存不存在”答案后你再判断值本身。7.3 内存暴涨集合里藏了大对象和重复引用排查上位机内存持续增长的问题多数情况下不是内存泄漏而是集合被不断添加且从不清理。典型场景把每次采集的新数据都往List里塞却没有对应的移除逻辑。尤其当元素是大字节数组——比如图像帧——这个List会迅速占满内存。定位方法用dotnet-counters和dotnet-dump抓内存快照重点看System.Collections.Generic.Listbyte[]或ConcurrentQueueT里的对象数量和大小。修复策略无非几种限制集合容量过旧数据淘汰、改用环形缓冲、把数据及时落盘或转存数据库、用对象池复用大数组防止LOH频繁分配。有一点想提醒Listbyte[]如果频繁扩容拷贝GC压力很大多帧图像场景预先分配固定大小数组池比反复new byte[width * height]高效得多。7.4 并发操作异常从e.Message看线程安全Collection was modified; enumeration operation may not execute.这条异常同样常见于并发场景——一个线程在foreach遍历一个字典另一个线程在Add新项。解决办法分几层如果只是单生产单消费用ConcurrentQueueT或ChannelT替代原生集合。如果是多读少写且写操作不频繁考虑ImmutableDictionaryTKey, TValue。它每次修改都返回一个新实例读线程永远拿到旧版本的快照不用加锁也能保持一致。如果既有频繁写又有频繁读优先ConcurrentDictionary把“复合操作”用AddOrUpdate、GetOrAdd这类原子方法表达避免自己拼多个调用。7.5 自定义类型去重无效Equals与GetHashCode成对重写HashSet去重和Distinct()去重都依赖于类型是否实现了值语义的Equals和GetHashCode。如果你的业务对象只有属性没有重写这两个方法默认走object的引用相等——不同实例哪怕是相同内容也算“不同”。两行代码给对象加上值语义public override bool Equals(object obj) { return obj is DeviceInfo other Id other.Id Name other.Name; } public override int GetHashCode() { return HashCode.Combine(Id, Name); }注意GetHashCode里只使用不可变字段否则对象放进HashSet或Dictionary后字段变了哈希码跟着变之后再也无法正确查找或去重。8. 选型决策速查一张表帮你做最终判断根据前文所有分析我整理了一张简化决策表可以直接贴到团队wiki里当参考需求首选方案备选方案不推荐按索引随机访问、尾部追加List数组LinkedList按键快速查找DictionaryK,VConcurrentDictionary多线程List线性搜索去重、存在性判断HashSetDictionaryK,V值为占位ListO(n)查询FIFO缓冲、任务队列QueueConcurrentQueue / ChannelList头部移除O(n)LIFO、回溯StackConcurrentStackList按键排序遍历SortedDictionary / SortedList普通Dictionary后手动OrderBy数据小List写排序麻烦多线程写读ConcurrentDictionary / ChannelBlockingCollection原生集合加裸lock只读共享数据ImmutableArray / ReadOnlyCollection普通集合防拷贝可变集合直接暴露9. 一些个人经验总结做C#开发这些年我最深的感受是集合选型不是看哪个类名顺眼而是看你的数据访问模式——是按下标找、按键找、按存在性找还是按顺序进出。访问模式决定数据结构数据结构决定性能上限这是逃不掉的规律。另外两件事值得长期坚持。第一对象映射或数据分组时优先选择字典或哈希集合尽量别用List.Exists这种O(n)查询数据量一大差距非常明显。第二异构数据从外部进入系统时第一时间放进合适的缓冲容器——串口、网络、摄像头回调这类高频场景Channel或ConcurrentQueue永远比“一个List加到处加锁”要靠谱。最后再分享一个小技巧写集合相关代码时随手给ListT预估容量、顺手用TryGetValue替代双重查找、用RemoveAll替代循环删除、用ReadOnlyCollection或IReadOnlyList暴露只读接口。这些小习惯单个看微不足道但堆在长时间运行的系统里省下来的CPU和内存相当可观。希望这套梳理能帮你少踩几个坑——至少别再让一个本该稳定的采集程序死在一次普通的RemoveAt(0)上。