jmh比手写system.nanotime()更可靠，因其自动处理预热、分叉、统计校验，避免jit未优化、gc暂停、cpu波动等干扰；需控制数组长度、数据类型、jit状态等变量，并覆盖小/中/大三档规模及基本/引用类型进行对比。
直接用 JMH（Java Microbenchmark Harness）做基准测试是最可靠的方式。它能规避 JVM 预热、代码优化、GC 干扰等常见误差，比手写 System.nanoTime() 更严谨。
为什么不用 System.nanoTime() 简单测？
手动计时容易受以下因素干扰：
- JVM 刚启动时未完成 JIT 编译，首次执行慢
- 垃圾回收可能在测量区间内触发
- CPU 频率动态调整、线程调度抖动影响纳秒级结果
- 多次运行未取平均值，单次结果偶然性大
所以简单循环 + `nanoTime` 只适合粗略验证，不能作为性能依据。
用 JMH 测 HashSet.contains 的标准流程
以对比 HashSet.contains() 和 ArrayList.contains() 为例：
- 添加 JMH 依赖（Maven）：
org.openjdk.jmh
jmh-core
1.37 - 定义测试状态类（@State），在 @Setup 方法中预热数据：插入 10 万条唯一元素，并确保目标查找项一定存在
- 用 @Benchmark 标记两个方法，分别调用 set.contains(target) 和 list.contains(target)
- 加 @Fork(3) 表示每组测试跑 3 轮；@Warmup(iterations = 5) 预热 5 轮；@Measurement(iterations = 10) 实际采样 10 轮
- 运行 mvn clean compile exec:java -Dexec.mainClass="org.openjdk.jmh.Main" -Dexec.args=".*Contains.*"
关键细节不能忽略
真实反映性能，要注意三点：
- 数据规模要合理：太小（如 100 元素）看不出差异；太大（如千万级）可能触发频繁扩容或 GC，掩盖核心操作耗时。建议从 1 万到 100 万逐档测试
- 避免“假热点”：不要只测固定位置（如 always look for element_0）。应随机选取目标，或遍历全部元素再统计平均耗时，防止 CPU 分支预测作弊
- 自定义对象必须重写 hashCode 和 equals：否则 HashSet 会把不同对象全塞进同一个桶，退化成链表遍历，O(1) 变成 O(n)，测出来的是 bug 不是性能
替代方案：用 JUnit + JMH 插件快速验证
如果项目暂不支持完整 JMH 流程，可用简化方式辅助判断：
- 用
System.nanoTime()测 100 次查找的总耗时，除以 100 得平均值 - 强制 JVM 预热：先执行 1000 次无关 contains 调用，再开始计时
- 每次测试前调用
System.gc()（仅用于排除 GC 干扰，生产环境勿用） - 至少运行 5 组，剔除最高最低值后取均值
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
