静态块不适用于系统负载基准测试，因其在类加载初始化阶段执行，无法访问实例成员、未就绪的运行环境，且禁止阻塞操作，易致类不可用；应改用应用启动后、独立测试模块或运维端点等可控入口。
静态块不适合直接用于系统负载的基准测试与记录。
为什么静态块不适用
静态初始化块在类加载的“初始化阶段”执行，时机早、上下文受限：
- 它无法访问实例成员，也不能创建完整运行环境（如未启动的线程池、未初始化的监控客户端、未连接的数据库）
- 不能执行阻塞式 I/O、网络调用或耗时计算——一旦失败会触发
ExceptionInInitializerError，导致整个类不可用 - 负载测试本身需要可控的并发、可配置的持续时间、可观测的指标采集（如 QPS、延迟分布、错误率），这些都超出静态块的能力边界
- 多个类的静态块执行顺序不确定，无法协调“测试开始”和“测试结束”的全局信号
真正可行的负载基准入口点
应将负载测试逻辑放在明确的生命周期节点中，例如：
-
应用主流程启动后：在
main方法或 Spring Boot 的@PostConstruct/ApplicationRunner中触发 - 独立测试模块：用 JMH、Gatling 或自定义 Benchmark Runner 启动，与业务类解耦
-
运维接口暴露：通过 Actuator 端点（如
/actuator/benchmark）按需触发，支持参数化（并发数、持续时间、目标 URL）
若坚持在类加载阶段“预埋”能力，可这样设计
静态块只做轻量级准备，把重活交给后续调用：
- 声明
private static final AtomicReferenceRECORDER = new AtomicReference(); - 在静态块中仅初始化一个空壳记录器（如内存缓冲区、日志门面），不连接外部系统
- 提供
public static void startLoadTest(int concurrency, Duration duration)方法，由外部显式调用——此时应用已就绪，线程、连接池、MetricsRegistry 全部可用 - 首次调用该方法时，才完成真实 recorder 的构建（如注册 Micrometer 计时器、开启采样线程）
一个更推荐的替代方案
用模块初始化表达式（C#）或 static {} + 工厂模式（Java）做“懒加载式基准能力注册”：
- 定义
LoadBenchmarkService单例，构造器中不做实际测试，只校验依赖是否就位 - 暴露
run(HttpClient client, String endpoint, LoadProfile profile)方法，接收运行时参数 - 在 Spring 容器启动完成后，用
@EventListener监听ContextRefreshedEvent，再决定是否自动执行一次冷启基准
负载测试不是类初始化的副产品，而是有明确目标、可重复、可观测的工程动作。把它塞进静态块，就像用螺丝刀拧灯泡——工具错位，结果难控。
