java静态块执行顺序严格遵循jvm规范：父类优先、源码顺序、仅执行一次；模块物理分离不影响该逻辑，触发时机取决于类首次主动使用，而非模块启动。
Java静态块在多模块项目中不会因为模块物理分离而改变执行逻辑，它的加载顺序仍严格遵循JVM规范：类首次主动使用时触发初始化，静态部分按“父类优先、源码顺序、单次执行”原则运行。模块只是编译和部署的组织方式，不干预类加载机制。
静态块触发时机由“主动使用”决定
静态块不是随模块启动就全部执行，而是等到某个类被首次主动使用时才初始化。常见主动使用场景包括：
- 创建该类的实例（new MyClass()）
- 访问该类的静态字段（非
final常量，或final但未在编译期确定值） - 调用该类的静态方法
- 反射获取该类（如
Class.forName("MyClass")） - 初始化该类的子类（前提是子类尚未初始化）
注意：public static final String X = "abc"这类编译期常量，引用它不会触发类初始化，也就不会执行静态块——这是常被误判的排查盲点。
跨模块调用时的类加载链依然完整
假设模块A定义了BaseConfig，模块B定义了SubConfig extends BaseConfig，且B依赖A：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 当B中首次
new SubConfig()时，JVM先确保BaseConfig已初始化：执行其静态变量赋值 → 静态块（按源码顺序） - 再执行
SubConfig自身的静态变量与静态块 - 模块物理路径（如Maven的
module-a和module-b目录）不影响这个顺序，只影响类能否被ClassLoader找到
若出现“父类静态块没执行”，大概率是父类根本未被主动使用，或被不同ClassLoader隔离（如OSGi、Spring Boot DevTools热替换场景），而非顺序错乱。
排查静态块未执行的三个关键检查点
遇到“预期中的日志没打印”或“静态变量为null”，按以下顺序快速定位：
-
确认是否真的触发了类初始化：在静态块第一行加
System.out.println("loading " + MyClass.class.getName());，看控制台是否输出；没有输出说明该类根本没被主动使用 -
检查是否有前向引用编译错误：静态块中不能读取其后声明的静态变量（如
static { System.out.println(s); }在static String s = "x";之前），Javac会直接报错 -
验证类加载器一致性：在多模块+自定义ClassLoader（如插件化、模块化容器）环境中，用
MyClass.class.getClassLoader()打印加载器哈希值，若父子类被不同ClassLoader加载，继承关系失效，静态初始化也会断开
模块间静态依赖建议解耦方式
避免模块A的静态块强依赖模块B的静态状态（例如在A的static{}里调用B的Utils.init()）：
- 改用懒加载模式：把初始化逻辑封装进静态方法，由业务方显式调用，而非放在静态块中隐式触发
- 利用服务发现机制：B模块提供
ServiceLoader接口实现，A模块在需要时动态加载，解除编译期静态耦合 - 配置驱动替代硬编码：将原本写死在静态块里的路径、端口等，改为从
application.properties或环境变量读取，延迟到运行时解析
静态块适合做无外部依赖、幂等、快速完成的类级准备动作。一旦涉及跨模块协作或外部资源，就该让位给更可控的生命周期管理方式。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
