应充分预热jvm、多次采样、排除gc等干扰，用system.nanotime()批量测量百万次contains()，分别统计命中/未命中平均值与99分位耗时，并用jmh或对比arraylist/treeset验证常数级性能。

直接用 System.nanoTime() 测量单次 contains() 耗时意义不大，因为 JVM 预热、JIT 编译、GC 干扰等因素会让结果严重失真。要测出 HashSet 真实的查找性能，关键在于：**预热充分、多次采样、排除干扰、关注平均与分布**。

预热集合和 JVM

HashSet 查找快慢受底层哈希表结构（如桶数量、是否触发扩容）和 JIT 优化程度影响。必须先让 JVM 运行足够多次，触发热点代码编译：

• 构造一个中等规模（如 10 万）的 HashSet，并插入随机或典型数据
• 在正式计时前，反复调用 contains() 至少数千次（例如 10,000 次），不记录耗时
• 可配合 -XX:+PrintCompilation 观察方法是否已被编译

批量测量 + 统计分析

单次调用可能低至纳秒级，且易受系统噪声干扰。应测量大量查询（如 100 万次），再计算平均值、中位数、99 分位耗时：

js2java

JavaScript 到 Java 全栈翻译助手，专为前端开发者学习 Java 或快速实现后端业务逻辑而设计。当用户提到以下场景时必须使用此技能： - "帮我把这段 JS 代码转成 Java" - "用 Java 怎么写这个逻辑" - "我习惯用 JS 写，想翻译成 Java" - "教我 Java，我要写后端接...

下载

• 用 System.nanoTime() 记录起止时间，避免 currentTimeMillis() 的低精度问题
• 混合测试“命中”（存在元素）和“未命中”（不存在元素），两者行为不同：命中取决于哈希定位+equals；未命中通常只需一次哈希+桶空检查，但最坏情况也要遍历链表/红黑树
• 建议分别统计：存在元素的平均耗时、不存在元素的平均耗时、以及长尾（如 99% 分位）耗时

控制变量，避免常见干扰

很多看似微小的操作会污染结果：

• 不要在循环内创建新对象（如每次 new String）、避免触发 GC；查询 key 应复用已有引用
• 关闭日志输出、IDE 调试器、其他高负载程序；可在命令行用 -Xmx2g -Xms2g 固定堆大小，减少 GC 波动
• 使用 JMH（Java Microbenchmark Harness）是更可靠的选择——它自动处理预热、Fork JVM、统计校准等，比手写循环严谨得多

对比基准，理解结果含义

单纯看“平均 8ns”没意义，要结合场景判断是否合理：

• 对比 ArrayList.contains()（O(n)）和 TreeSet.contains()（O(log n)），确认 HashSet 确实呈常数级增长
• 改变 HashSet 初始容量（如 new HashSet(1000) vs new HashSet(100000)），观察扩容对后续查找的影响
• 故意用低质量 hashcode（如所有对象返回 1）制造哈希碰撞，验证退化为链表遍历时的性能下降

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南