Java并发性能测试需用JMH控制变量、固定JVM参数、避免伪共享，监控线程状态与锁竞争，合理配置线程池，并明确压测目标与指标可信度。
Java并发性能测试不是跑几个线程看不崩溃，而是得控制变量、隔离干扰、量化指标——否则测出来的“QPS提升20%”可能只是GC抖动的幻觉。
用JMH写基准测试而不是手写for+Thread
手写多线程循环调用方法会引入大量噪声：JVM预热不足、对象逃逸、即时编译未生效、线程调度随机性。JMH（Java Microbenchmark Harness）强制统一预热、分叉（fork）、统计方式，结果才可比。
- 必须用
@Fork(jvmArgs = {"-Xmx2g", "-XX:+UseG1GC"})固定JVM参数，避免不同轮次GC策略漂移 -
@State(Scope.Benchmark)声明共享状态时，要确认是否真需共享——多数场景应设为Scope.Thread防伪共享 - 禁止在
@Benchmark方法里打印日志、触发System.gc()、读配置文件——这些操作会污染测量周期 - 示例片段：
@Benchmark public void testConcurrentHashMapPut(Blackhole bh) { bh.consume(map.put(ThreadLocalRandom.current().nextInt(), "v")); }监控真实瓶颈而非只看吞吐量
高吞吐≠高性能。可能CPU跑满但实际是锁竞争或内存带宽打满；也可能吞吐一般但P99延迟爆炸——用户感知的是后者。
- 必看指标：
java.lang:type=Threading里的PeakThreadCount和CurrentThreadCpuTime，确认线程数没失控 - 用
jstack -l抓取堆栈，搜索java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject或parking to wait for，定位阻塞点 - JFR（Java Flight Recorder）开启
LockContention事件，直接看到哪个锁在哪争抢最狠 - 避免只信
top的%CPU——Java线程可能在做IO等待（WAITING状态），此时CPU低但响应卡死
线程池配置不能拍脑袋设成CPU核心数×2
CPU密集型和IO密集型任务对线程池的要求完全不同，混用会导致资源浪费或饥饿。
- CPU密集型（如加密计算）：
corePoolSize = Runtime.getRuntime().availableProcessors()，拒绝策略建议AbortPolicy，让调用方自己重试 - IO密集型（如HTTP调用、DB查询）：
corePoolSize ≈ CPU核心数 × (1 + 平均IO等待时间 / 平均CPU工作时间)，通常8–32之间，需压测验证 - 务必设置
allowCoreThreadTimeOut(true)，否则空闲核心线程永不回收，长连接场景下内存泄漏风险高 - 拒绝策略别用
CallerRunsPolicy测性能——它把压力转回主线程，测出来的是“假高吞吐”，上线后主线程卡死
避免共享变量导致的伪共享（False Sharing）
多个线程频繁修改同一缓存行（64字节）上的不同字段，会因CPU缓存一致性协议反复失效整行，性能断崖下跌——这个坑连很多资深开发者都会忽略。
- 典型场景：
AtomicInteger数组计数器、自定义计数类中的相邻long字段 - 用
@sun.misc.Contended注解（需启动参数-XX:-RestrictContended）隔离字段，或手动填充7个long占位 - JOL（Java Object Layout）工具验证：
new ClassLayout.parseClass(MyCounter.class).toPrintable()看字段布局和缓存行对齐 - 注意：LMAX Disruptor等高性能库大量使用该技巧，但普通业务代码过度优化反而增加维护成本
并发性能测试最难的从来不是写代码，而是识别“你以为在测并发，其实是在测GC”“你以为在压系统，其实是在压网卡缓冲区”。每次压测前，先问自己：这次想证伪什么假设？指标采集链路是否全链路可信？
- 必看指标：
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
