静态代码块应仅执行轻量、无副作用的预处理，如预编译正则、空容器声明、极简单例和硬编码参数；严禁I/O、网络、反射及非final方法调用，真实资源交由JMH的@Setup管理。
静态代码块在性能基准测试中不直接参与被测逻辑，但作为预处理入口，能高效完成测试环境的一次性准备——前提是严格规避耗时与依赖，否则反而污染测试结果。
适合预处理的测试资源类型
静态代码块只应承担轻量、确定、无副作用的初始化任务，确保JVM预热和基准测量不受干扰：
- 预编译正则Pattern：如
static final Pattern EMAIL_PATTERN = Pattern.compile("^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}$");，编译开销前置，避免每次测试调用重复编译 - 固定结构的空容器：如
static final Map<String, Integer> CACHE = new ConcurrentHashMap<>(64);，仅分配结构，不填充数据 - 基础工具单例：如
static final ObjectMapper JSON = new ObjectMapper();，不注册模块、不设反序列化特性，保持构造极简 - 硬编码测试参数：如
static final int TEST_SIZE = 10_000;，全部来自final static常量，杜绝运行时读取配置
必须避开的预处理陷阱
一旦静态块引入不可控延迟或状态，基准测试将失去可比性与可信度：
- 禁止I/O操作：不能在static块中读取properties文件或JSON资源，否则每次fork新JVM进程都会触发重复加载，扭曲warmup阶段行为
- 拒绝网络或数据库连接：哪怕只是尝试ping本地服务，也会因超时或重试机制导致benchmark线程阻塞，破坏
@Warmup稳定性 - 避免反射或动态类加载：如
Class.forName("xxx")可能触发未知类初始化链，引发意外GC或类加载竞争 - 不调用非final静态方法：若依赖其他类的静态方法，而该方法尚未初始化，可能返回默认值（如0、null），造成测试数据失真
与JMH协同的最佳实践
静态块要真正服务于基准测试，需配合JMH生命周期设计，而非替代它：
立即学习“Java免费学习笔记（深入）”；
- 静态块只做“零成本准备”：例如预热一个
ThreadLocal<DecimalFormat>的初始值，但格式化器本身延迟构造 - 真实资源延迟到
@Setup阶段：连接池、缓存数据、大对象数组等，一律交给JMH管理，在每个Benchmark方法执行前按需初始化 - 用
@State(Scope.Benchmark)隔离实例状态：避免静态共享干扰多线程吞吐量测试，尤其当测试涉及写操作时 - 验证static块是否生效：在
@Setup中打印日志或检查静态字段值，确认其在warmup开始前已就绪，而非被JIT优化掉
典型误用与修正对比
错误写法会把基准测试变成环境启动测试；正确写法让预处理隐形且可靠：
-
错误：在static块中加载10MB测试JSON并解析为List → 导致fork延迟飙升，warmup不充分，
AverageTime波动剧烈 -
修正：static块仅声明
static final String TEST_JSON_PATH = "/test-data.json";，实际读取放在@Setup里，且用Blackhole.consumeCPU()防止死码消除 -
错误：static块调用
System.getProperty("os.name")再分支初始化 → 不同OS下执行路径不同，跨平台测试结果不可比 -
修正：所有分支逻辑移至
@Param驱动，静态块保持纯线性、无条件执行
