集合性能对比需综合操作类型、数据规模、内存开销、线程场景四指标：查删增遍历复杂度各异，小数据无差异而大数据显分野，内存与GC压力影响显著，线程安全机制带来性能权衡。
集合类性能对比不能只看“快不快”，得盯住四个硬指标：操作类型、数据规模、内存开销、线程场景。不同语言的集合实现逻辑不同，但分析思路一致——脱离场景谈性能，等于纸上谈兵。
看操作类型：查、增、删、遍历，谁在干啥？
同一集合，在不同操作下表现可能天差地别：
- 存在性检查（x in s）：set/dict 是 O(1) 哈希查找；list 是 O(n) 顺序扫描。10 万数据里查一个值，set 可能 0.02ms，list 要 8ms+。
- 随机访问（s[i]）：list/tuple 支持且极快；set/dict 根本不支持索引，强行转 list 再取就失去意义。
- 头部插入（insert(0, x)）：LinkedList 是 O(1)，ArrayList 是 O(n)（所有元素后移）；Python list 没有链表实现，这类操作应避免。
- 去重：set 天然 O(n) 完成；list 去重要嵌套循环或借助 dict.fromkeys()，时间复杂度升至 O(n²) 或更高。
看数据规模：小数据没差别，大数据见真章
100 个元素时，list 和 set 的差异几乎感知不到；但到 10 万以上，曲线就分叉了：
- 成员判断耗时：list 呈线性增长（10 万 → 约 10× 耗时），set 基本横平（哈希表均摊 O(1)）。
- 内存占用：set/dict 因哈希桶、空闲槽位和对象头，通常比同等数据的 list 高 2–3 倍；但若频繁查重，省下的 CPU 时间远超内存成本。
- 实测建议：用 timeit 模块固定重复次数（如 10000 次），测 1k/10k/100k 三档规模，画出趋势而非单点值。
看内存与 GC 压力：尤其 Java 中不可忽视
Java 里基本类型和包装类的代价会放大集合选型影响：
- int[][] 不规则数组存 10 万整数 ≈ 400KB；ArrayList
> 同结构常超 1.2MB（含 Integer 对象、ArrayList 元数据、冗余容量）。 - 自动装箱/拆箱引发额外 GC，高频读写场景下，数组的吞吐优势直接碾压嵌套集合。
- Python 虽无装箱问题，但 set 存字符串时，每个字符串对象仍需独立分配，大量短字符串可能触发更多小对象 GC。
看并发需求：线程安全不是免费的午餐
多线程下，性能≠单线程基准测试结果：
- synchronizedList：全方法加锁，高并发时严重串行化，吞吐低。
- ConcurrentHashMap：读不加锁，写只锁局部段或节点，吞吐量通常是 synchronizedMap 的 3–5 倍。
- CopyOnWriteArrayList：读完全无锁，但每次写都复制整个数组——适合日志收集、监听器列表等“读巨多、写极少”场景，写多则雪崩。
