不能直接用 System.nanoTime() 测集合操作性能，因为 JVM 会通过死代码消除、未预热、GC 干扰、线程干扰等导致结果失真；必须用 JMH 配合 @State、Blackhole、@Fork/@Warmup/@Measurement 等机制确保测量准确。
集合操作性能为什么不能用 System.nanoTime() 直接测
因为 JVM 会优化掉没用的计算结果，比如你写个 list.add(x) 但没读它、没用它，JIT 编译器可能直接删掉这行；循环里反复新建 ArrayList 还不加 @Setup，测出来的其实是对象分配+GC开销，不是 add 本身。更糟的是，没预热时 JIT 还没编译，前几轮慢得离谱，拿平均值一算就失真。
- 死代码消除：JVM 发现返回值/中间变量没被消费，整段逻辑跳过
- 未预热：第一次执行是解释模式，比最终编译后慢 5–10 倍
- GC 干扰：频繁创建集合对象触发 Young GC，时间全算在
add()头上 - 线程干扰：多线程共享一个
ArrayList但没同步，结果不可复现
@State(Scope.Benchmark) 和 @State(Scope.Thread) 怎么选
测集合本身的线程安全行为（比如 CopyOnWriteArrayList 写多读少场景），要用 @State(Scope.Benchmark) —— 所有线程共用同一个实例，才能暴露竞争和复制开销；而测单线程吞吐（比如 ArrayList.add() 在无竞争下的极限），该用 @State(Scope.Thread)，避免缓存行伪共享或锁争用污染结果。
-
@State(Scope.Benchmark)：适合测“共享状态下的并发行为”，如ConcurrentHashMap.put()、BlockingQueue.offer() -
@State(Scope.Thread)：适合测“单线程内方法本征开销”，如ArrayList.get()、HashSet.contains() - 千万别用
@State(Scope.Group)除非你明确要模拟分组协作，日常几乎用不到
怎么防止集合测试被编译器“优化掉”
JMH 不会自动帮你保留集合操作的结果。比如你测 list.remove(0)，但没把返回值或修改后的 list 拿去用，JIT 可能直接砍掉整条语句。必须用 Blackhole 消费返回值，或把关键状态显式输出。
- 对返回值：用
blackhole.consume(list.remove(0)) - 对 void 方法（如
list.clear()）：需在@TearDown或后续方法中访问 size / 遍历验证，否则可能被优化 - 别在
@Benchmark方法里打印日志、调用System.out—— I/O 开销远超集合操作本身 - 参数化集合大小要用
@Param({"100", "10000"})，别在方法里写死 new，否则每次迭代都重建，测的是构造不是操作
@Fork、@Warmup、@Measurement 的合理配比
默认 1 次 fork + 5 轮预热太脆弱。真实集合测试建议至少 @Fork(3)，每轮预热不少于 10 秒（@Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)），测量也拉长到 10 轮——小集合操作快至纳秒级，短时间测量噪声大，标准差超过均值 5% 就该怀疑数据不可靠。
-
@Fork(3)：启动 3 个独立 JVM 进程，排除偶然 GC、系统调度等干扰 -
@Warmup(iterations = 10)：确保 JIT 已完成 C1/C2 编译，且类已初始化完毕 -
@Measurement(iterations = 10)：多次采样取中位数，比平均值更能抵抗异常抖动 - 别设
@Fork(jvmArgs = {"-Xmx2g"})过大堆内存——集合测试通常只占几 MB，堆大反而延长 GC 周期，掩盖真实延迟
@State 注解放错作用域，或者漏掉一次 blackhole.consume()，结果就可能差出一个数量级。 
