建議 20：優先使用泛型集合取代非泛型集合
優勢
- 型別安全：編譯期捕獲型別錯誤，避免執行期
InvalidCastException
- 效能優越：避免值型別的裝箱/拆箱，記憶體佔用更少，GC 壓力更小
效能實測（1000 萬次 Add/Index）
| 集合 | 耗時 (ms) | Gen 0 GC 次數 |
|---|
ArrayList | ~1,850 | ~42 |
List<int> | ~1,200 | ~18 |
List<T> 速度提升 ~35%，GC 次數減少 ~57%。數據量越大差距越明顯。
建議 21：根據場景選擇正確集合
| 場景 | 推薦集合 | 關鍵特性 |
|---|
| 固定大小、頻繁索引存取 | T[] / Array | 記憶體連續、零額外負擔、最快索引 |
| 動態增刪、順序存取 | List<T> | 動態擴容、快速尾端新增、索引 O(1) |
| 鍵值對查找、唯一鍵 | Dictionary<TKey,TValue> | O(1) 查找/新增/刪除、雜湊表實作 |
| 先進先出 (FIFO) | Queue<T> | Enqueue/Dequeue O(1) |
| 後進先出 (LIFO) | Stack<T> | Push/Pop O(1) |
| 唯一值集合、集合運算 | HashSet<T> | O(1) Contains、Union/Intersect/Except |
| 排序鍵值對 | SortedDictionary<TKey,TValue> | 紅黑樹、鍵有序、O(log n) 操作 |
| 排序唯一值 | SortedSet<T> | 紅黑樹、值有序、O(log n) |
核心原則：先分析「主要操作是什麼？（索引、查找、增刪、排序、去重）」，再選擇對應時間複雜度最優的集合。
建議 22：確保集合執行緒安全
問題示範
var list = new List<Person> { ... };
var t1 = new Thread(() => {
foreach (var p in list) { Console.WriteLine(p.Name); Thread.Sleep(1000); }
});
var t2 = new Thread(() => { Thread.Sleep(1000); list.RemoveAt(2); });
t1.Start(); t2.Start();
// 結果：t1 拋出 InvalidOperationException「集合已修改，枚舉操作可能無法執行」
非泛型集合：SyncRoot 模式
var arrayList = new ArrayList { ... };
lock (arrayList.SyncRoot) { foreach (...) { ... } }
lock (arrayList.SyncRoot) { arrayList.RemoveAt(2); }
泛型集合：自訂鎖物件
var list = new List<Person> { ... };
private static readonly object _syncLock = new object();
lock (_syncLock) { foreach (var p in list) { ... } }
lock (_syncLock) { list.RemoveAt(2); }
進階：.NET 4.0+ 並行集合
| 集合 | 適用場景 | 特性 |
|---|
ConcurrentQueue<T> | 生產者/消費者佇列 | 無鎖、高併發 Enqueue/TryDequeue |
ConcurrentStack<T> | 無鎖堆疊 | Push/TryPop |
ConcurrentDictionary<TKey,TValue> | 高併發字典 | TryAdd/GetOrAdd/AddOrUpdate 原子操作 |
BlockingCollection<T> | 有界緩衝、生產消費 | 支援 Take/Add 阻塞、CompleteAdding |
選擇指南
- 簡單同步、低併發、操作需原子性：
lock + 一般集合
- 高併發、大量存取、需無鎖效能：
Concurrent* / BlockingCollection
- 唯讀場景：
ImmutableList<T>、ImmutableDictionary<TKey,TValue>（System.Collections.Immutable）
總結
- 預設用
List<T>、Dictionary<TKey,TValue> 等泛型集合
- 依操作特徵選擇專用集合（Queue、Stack、HashSet、Sorted* 等）
- 多執行緒環境務必同步：
lock、並行集合、或不可變集合
- 效能敏感處先測試再優化，避免過早優化
