system.loadlibrary()成功的关键是库文件位置和名匹配规则，而非静态代码块本身；库必须置于java.library.path指定路径，按平台查找对应文件，且需注意大小写、架构、依赖及权限。
静态代码块本身不负责“配置”，它只是执行加载动作的入口；真正需要配置的是 库文件位置 和 库名匹配规则。System.loadLibrary() 能否成功，关键不在 static 块怎么写，而在运行环境是否满足前提条件。
库文件必须放在 java.library.path 指定路径下
System.loadLibrary("mylib") 会按平台查找：
- Windows：找 mylib.dll
- Linux：找 libmylib.so
- macOS：找 libmylib.dylib
它不会自动扫描 classpath 或 resources 目录，只在 java.library.path 列出的路径中搜索。启动 JVM 时需显式配置：
- -Djava.library.path=/opt/myapp/libs
- -Djava.library.path=./libs:/usr/local/lib
可在代码中验证当前值：
System.out.println(System.getProperty("java.library.path"));
静态代码块里只需一行调用，但要注意时机
典型写法（安全、简洁）：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
public class NativeBridge {
static {
System.loadLibrary("mylib"); // 不带路径、不带扩展名、不带 lib 前缀（Linux/macOS）
}
public static native int compute(int a, int b);
}
注意：
- 必须在任何 native 方法被调用之前执行完这个语句
- 不要在 static 块里做额外初始化（如调用 native init 方法），失败会导致类永久不可用
- 重复调用 System.loadLibrary("mylib") 是安全的，JVM 自动忽略
如果库不在标准路径，改用 System.load() + 提取到临时目录
例如库打包在 jar 的 /native/win64/mylib.dll 中：
- 先用
getClass().getResourceAsStream()读取字节流 - 写入
Files.createTempFile(...)得到绝对路径 - 再调用
System.load("/tmp/xxx.dll")
这种方式绕过 java.library.path 限制，但需确保临时文件有执行权限（Linux/macOS），且进程退出后手动清理或依赖 JVM 自动回收。
常见配置失败原因和检查点
即使 static 块执行了，仍报 UnsatisfiedLinkError，优先核对：
- 库名是否拼错？System.loadLibrary("MyLib") 实际找的是 mylib.dll（全小写、无下划线）
- 架构是否匹配？x86 JVM 不能加载 x64 库，ARM 设备不能运行 x86_64 .so
- 依赖库是否缺失？用 ldd libmylib.so（Linux）或 Dependency Walker（Windows）检查
- 权限是否足够？Linux/macOS 下库文件需有可读+可执行位（chmod +x）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
