登录
首页 >  文章 >  java教程

Java集合类性能对比分析

时间:2026-01-14 08:27:40 290浏览 收藏

哈喽!今天心血来潮给大家带来了《Java集合类性能测试详解》,想必大家应该对文章都不陌生吧,那么阅读本文就都不会很困难,以下内容主要涉及到,若是你正在学习文章,千万别错过这篇文章~希望能帮助到你!

ArrayList随机访问为O(1),LinkedList为O(n),因前者基于数组后者为链表;频繁索引遍历时ArrayList快3–10倍;仅头部/中间高频增删且无随机访问需求时才选LinkedList。

Java集合框架中的集合类与性能测试

ArrayList 和 LinkedList 的随机访问性能差异明显

随机访问(比如 get(int index))时,ArrayList 是 O(1),LinkedList 是 O(n)。这不是理论推演,而是底层结构决定的:前者基于数组,后者靠双向链表逐个跳节点。

实操中容易误以为“链表插入快,所以通用更快”,但只要代码里有类似 list.get(i) 的循环遍历,LinkedList 往往比 ArrayList 慢 3–10 倍(JDK 17,百万元素级测试)。

  • ArrayList 替代 LinkedList 做索引遍历时,性能提升通常立竿见影
  • 若真需要频繁在头部/中间插入删除,且不依赖随机访问,才考虑 LinkedList;否则优先选 ArrayList
  • LinkedListget() 在 JDK 9+ 有小幅优化(从头或尾择近遍历),但无法改变渐进复杂度

HashMap 的扩容触发条件与负载因子影响实际吞吐

HashMap 不是“一直快”。当元素数量超过 capacity × loadFactor(默认 0.75)时,会触发 rehash —— 重建哈希表、重散列所有键,这个过程是 O(n) 且阻塞操作。

常见错误是初始化时不预估大小,比如已知要放 10 万条记录,却用默认构造函数 new HashMap()(初始容量 16),结果触发约 16 次扩容,大量内存拷贝和 hash 重计算拖慢整体性能。

  • 明确大小时,用 new HashMap(initialCapacity),且 initialCapacity 应 ≥ 预期总数 ÷ 0.75,向上取最近 2 的幂(如 10 万 → 至少 131072)
  • 负载因子设为 0.75 是时间与空间的权衡;调低(如 0.5)减少冲突但浪费内存;调高(如 0.9)节省内存但碰撞增多,get/put 可能退化为链表遍历
  • JDK 8 中,当桶内链表长度 ≥ 8 且 table.length ≥ 64,链表转红黑树 —— 这个阈值不能改,但可通过合理初始容量避免过早进入树化路径

ConcurrentHashMap 的迭代器不抛 ConcurrentModificationException,但不保证强一致性

这是最容易被文档误导的一点:ConcurrentHashMapkeySet().iterator() 确实不会抛 ConcurrentModificationException,但它也不承诺“看到所有已提交的修改”。迭代过程可能跳过某些刚 put 的条目,也可能重复看到某些条目(取决于分段锁/Node 节点状态)。

很多业务代码把它当“线程安全版 ArrayList 迭代”用,结果在统计类场景出错 —— 比如并发写入 + 后台定时 dump 全量 key,发现总数对不上。

  • 如果需要精确快照,用 mappingCount() 获取当前估算大小,或改用 new ConcurrentHashMap().keySet().toArray()(会加锁并复制,代价高但一致)
  • 不要在迭代器上做依赖“全量可见”的逻辑,比如“遍历所有 key 并发调用远程服务”,应先收集 key 列表再处理
  • forEach()reduce() 等方法内部使用了更稳定的批量操作协议,比手动迭代器更可靠

性能测试必须绕开 JVM 预热和 GC 干扰

直接写个 for 循环跑 1000 次 put()HashMap 速度?结果基本无效。HotSpot JVM 有 JIT 编译延迟,前几百次调用走的是解释执行,后面才优化成机器码;同时 GC 可能在任意时刻介入,导致某次耗时突增 10ms,拉垮平均值。

真实对比必须用 JMH(Java Microbenchmark Harness),它自动处理预热、fork JVM 进程、统计置信区间等。

public class MapBenchmark {
    @State(Scope.Benchmark)
    public static class MyState {
        HashMap<Integer, String> map = new HashMap<>(10000);
    }

    @Benchmark
    public void put(Blackhole blackhole, MyState state) {
        state.map.put(ThreadLocalRandom.current().nextInt(), "v");
        blackhole.consume(state.map);
    }
}
  • 不用 JMH 就别谈“XX 比 XX 快 20%”,那只是噪声
  • 测试集合类时,确保 key/value 类型、hashCode 实现、数据分布(是否全相同 hash?)贴近真实场景
  • GC 日志(-Xlog:gc*)必开,确认 benchmark 过程中没发生 full GC
实际压测中,最常被忽略的是集合类与业务数据特征的耦合——比如用 TreeSet 存 UUID 字符串,看似有序需求合理,但 String.compareTo() 在长随机字符串下比较成本远高于 int,而你本可用 HashSet + 外部排序解决。性能从来不是单看 API 名字就能定的。

本篇关于《Java集合类性能对比分析》的介绍就到此结束啦,但是学无止境,想要了解学习更多关于文章的相关知识,请关注golang学习网公众号!

前往漫画官网入口并下载 ➜
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>