Java集合这10个坑， senior踩了7年才爬出来

国内某大厂2024年技术债审计报告显示，集合类误用占生产事故的23%，平均修复成本4.7人天。这组数字背后，是无数工程师在ArrayList和LinkedList之间反复横跳的深夜。

Java集合框架（Java Collection Framework，JCF）像一把瑞士军刀——人人都会拔刀，但多数人只用过主刀。Senior工程师和普通开发者的差距，往往藏在那些"知道但没用对"的细节里。

空集合：别再用new ArrayList<>()了

方法返回空列表时，你的第一反应是什么？如果代码里还有return new ArrayList<>()，内存里正在发生一场微型灾难。

每次new ArrayList<>()都会分配底层数组，即使长度为0。Collections工具类提供的emptyList()、emptySet()、emptyMap()返回的是不可变单例对象，全局复用，零分配开销。

关键区别：emptyList()返回的实例调用add()会直接抛UnsupportedOperationException，这在防御性编程里反而是 feature 而非 bug——调用方被迫处理空逻辑，而不是拿到一个能偷偷修改的"空"容器。

Spring框架源码里，Collections.emptyList()出现超过1800次。不是他们抠门，是GC压力在高压场景下会指数级放大。

不可变包装：API安全的最后防线

2023年某支付平台出过一起典型事故：内部服务A返回的订单列表被服务B误清空，导致对账系统崩盘。根因是A直接把内部List引用交了出去。

Collections.unmodifiableList()的解法看似完美，实则有个致命盲区——它只包装了一层视图。如果原始List被其他代码修改，"不可变"视图会同步变化。这相当于给房门加了把锁，但窗户还开着。

Java 10引入的List.copyOf()才是正解，它创建的是真正的不可变副本。Guava的ImmutableList更早解决了这个问题，但代价是额外依赖。

选择策略很清晰：对外暴露只读视图用unmodifiable，需要绝对隔离用copyOf，能接受第三方库直接用Guava。

Map初始化：那个被忽略的负载因子

HashMap的默认负载因子是0.75，这个数不是拍脑袋定的——它平衡了时间复杂度和空间利用率。但知道这一点的人，90%没看过源码里的注释。

更隐蔽的坑是初始容量。new HashMap<>(100)实际能容纳75个元素就会触发扩容，因为阈值=容量×负载因子。如果明确要存100个KV对，正确写法是new HashMap<>(133)，或者干脆用Maps.newHashMapWithExpectedSize(100)（Guava）。

扩容的代价不止是数组拷贝。JDK 8之前，链表转红黑树的阈值是8，但触发扩容时所有元素要rehash，这个CPU开销在批量插入场景下能吃掉20%的吞吐量。

Stream与集合：别在热路径上作死

Lambda和Stream让代码变漂亮了，但漂亮是有价格的。某电商核心链路压测显示，把list.stream().filter().collect()换成传统for-each循环，TP99下降了12%。

Stream的惰性求值是双刃剑。filter+map+collect的链条里，每个中间操作都生成新的Stream对象，短链条无所谓，三层以上嵌套建议手写循环。更隐蔽的是装箱拆箱——Stream比IntStream慢一个数量级，这个差距在百万级数据量下直接决定服务是否超时。

并行流（parallelStream）是另一个雷区。默认的ForkJoinPool线程数等于CPU核数，IO密集型任务会饿死其他线程。更糟的是，错误的数据源（如Stream.iterate）会让并行流比串行还慢，因为拆箱开销抵消了并行收益。

PriorityQueue：堆结构的认知偏差

很多人以为PriorityQueue是有序的，直到第一次调用iterator()才发现顺序是乱的。它的有序只体现在poll()和peek()，底层是数组实现的小顶堆，遍历顺序是堆的物理存储顺序而非逻辑顺序。

这个特性决定了它的适用场景：任务调度、Top-K问题、合并K个有序列表。如果需要的是全序遍历，TreeSet才是正确答案，虽然O(log n)的插入比PriorityQueue的O(log n)常数更大，但查询有序集合时是O(1) vs O(n log n)的差距。

JDK 21的虚拟线程（Virtual Threads）让PriorityQueue的使用场景进一步收窄。轻量级线程的调度本身不依赖传统优先级队列，JVM层面的work-stealing算法接管了大部分调度决策。

IdentityHashMap：对象身份的照妖镜

这个类在标准库里的存在感极低，但解决的是真·硬核问题：用==而非equals判断键相等。序列化框架、对象图遍历、调试工具是它的主战场。

普通HashMap里，两个内容相同的String是同一个键；IdentityHashMap里，只有同一个引用才算命中。这个差异在实现对象深拷贝时至关重要——你需要区分"值相等"和"是同一个对象"，避免循环引用导致的栈溢出。

性能方面它也有优势：免去了equals()和hashCode()的调用，纯引用比较。但代价是失去了Map接口的常规语义，用之前得确认团队里其他人能看懂。

Collections.rotate：循环移位的隐藏选手

面试题里常见的"数组循环右移k位"，标准库早就给了答案。Collections.rotate(list, 1)把最后一个元素移到队首，rotate(list, -1)反过来。实现是三次反转算法，O(n)时间、O(1)空间，比大多数人手写的版本都干净。

这个API的冷门程度令人费解——它在Apache Commons Collections里也有对应实现，但JDK原生版本零依赖。可能是命名太直白，反而让人以为"这么简单的操作不会有专门方法"。

EnumSet/EnumMap：被低估的专用容器

当键或值是枚举类型时，HashMap和HashSet是性能罪犯。EnumSet用位向量实现，64个枚举值以内的集合只占一个long的空间；EnumMap用数组索引，操作都是O(1)且无哈希冲突。

内存对比更夸张：存储WeekDay的EnumSet比HashSet省90%以上空间，且GC友好。Spring的注解处理、Netty的事件循环都在重度使用这两个类，只是藏在框架深处，普通业务代码很少触及。

限制也很明确：必须是枚举类型。但"我的场景用不上枚举"往往是设计问题——状态机、类型码、配置开关，这些本该是枚举的战场，很多人却用String和int凑合。

ConcurrentHashMap：size()的陷阱

并发容器里最常用的类，藏着最不直观的API。size()和isEmpty()在JDK 8之前是全局加锁的，虽然后来改成分段累加，但仍是O(n)而非O(1)。

更隐蔽的是computeIfAbsent的递归调用限制。如果回调函数里又操作了同一个ConcurrentHashMap，可能触发死锁或IllegalStateException。这个限制在文档里写得很清楚，但Stack Overflow上相关提问超过400个。

替代方案是LongAdder配合外部计数，或者用Guava的CacheBuilder——如果场景允许过期策略的话。

Oracle 2024年Java开发者调研有个有趣数据：自称"精通集合框架"的受访者中，能正确说出ConcurrentHashMap size()时间复杂度的不到15%。知识幻觉比无知更危险。

你最近一次review代码时，发现过集合类的误用吗？是空集合的分配开销，还是不可变视图的线程安全问题——或者，是那个永远没人敢动的祖传HashMap初始容量？