静态代码块是加载本地库的常用入口点，因其在类首次主动使用时执行且仅一次，适合一次性初始化；需确保在native方法调用前完成加载，推荐用system.loadlibrary()配合java.library.path，注意库名匹配、依赖、架构及权限问题。
Java 中 static 静态代码块本身不能直接加载本地动态链接库（如 .dll、.so 或 .dylib），但它常被用作调用 System.loadLibrary() 或 System.load() 的**执行入口点**，从而在类首次初始化时自动加载本地库。关键在于：静态代码块的执行时机与类加载机制配合，实现“一次加载、全局可用”。
静态代码块是加载本地库的常用位置
因为静态代码块在类被 JVM 第一次主动使用（如创建实例、访问静态成员）时执行，且只执行一次，所以适合做一次性初始化操作，比如加载 native 库。只要确保它在任何 native 方法被调用前完成加载，就不会抛出 UnsatisfiedLinkError。
典型写法如下：
// 假设本地方法声明在 NativeUtil.class 中
public class NativeUtil {
static {
System.loadLibrary("mylib"); // 加载 libmylib.so / mylib.dll / libmylib.dylib
}
public static native void doSomething();
}
loadLibrary 与 load 的区别要清楚
System.loadLibrary("name") 会按平台规则搜索库文件：
– Windows 查找 name.dll
– Linux 查找 libname.so
– macOS 查找 libname.dylib
它依赖 java.library.path 系统属性指定的路径（如 -Djava.library.path=/path/to/libs），不带路径和扩展名。
System.load("/full/path/to/libname.so") 则直接加载绝对路径文件，绕过路径查找逻辑，更可控但可移植性差。
- 推荐优先用
loadLibrary，配合启动参数设置java.library.path - 若库放在项目 resources 下，需先提取到临时目录再用
System.load(absolutePath) - 避免在静态块中多次调用
loadLibrary—— 重复调用同名库无害，但加载不同名库可能失败
常见失败原因和应对方式
即使静态块执行了 loadLibrary，仍可能报错。主要排查方向：
-
库名不匹配：传给
loadLibrary的名字必须与实际文件名前缀一致（去掉lib和扩展名），例如libhello.so→loadLibrary("hello") -
依赖缺失：动态库本身依赖其他 .so/.dll（如 OpenSSL、glibc 版本），需用
ldd（Linux）、otool -L（macOS）或Dependency Walker（Windows）检查 -
架构不兼容：JVM 是 64 位，但库是 32 位（或反之），会导致
UnsatisfiedLinkError: no xxx in java.library.path类似提示 -
权限或路径问题：Linux/macOS 上文件无执行权限，或
java.library.path没包含库所在目录
进阶：确保线程安全与初始化顺序
静态块天然线程安全（JVM 保证类初始化阶段的同步），所以多个线程同时首次访问该类，库也只会加载一次。
但要注意依赖关系：
- 如果类 A 的静态块加载库，而类 B 的静态字段依赖 A 的 native 方法，需确保 B 在 A 初始化之后才被使用，否则可能触发类初始化顺序问题
- 避免在静态块中调用尚未初始化的其他类的静态方法（尤其是跨模块场景），以防死锁或 NoClassDefFoundError
- 可在加载后加简单校验，比如调用一个轻量级 native 方法返回版本号，快速暴露加载失败
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
