JDK中动态库加载路径问题，一文讲清
前言
本周协助测试同事对一套测试环境进行扩容，我们扩容很原始，就是新申请一台机器，直接把jdk、resin容器（一款servlet容器）、容器中web应用所在的目录，全拷贝到新机器上，servlet容器和其中的应用启动没问题。以为ok了，等到测试时，web应用报错，初始化某个类出错。报错的类长下面这样：
com.thinkive.tbascli.TBASCli
static {
String os = "win";
String pathSep = System.getProperty("path.separator");
if (pathSep.equalsIgnoreCase(":")) {
os = "linux";
}
try {
// 1
System.loadLibrary("TBASClientJNI");
} catch (SecurityException var5) {
var5.printStackTrace();
System.out.println("Load TBASClientJNI Library Failed");
} catch (UnsatisfiedLinkError var6) {
URL url = TBASCli.class.getClassLoader().getResource("");
String path = (new File(URI.create(url.toExternalForm()))).getAbsolutePath();
if (os.equalsIgnoreCase("win")) {
// 2
loadDLL(path);
} else if (os.equalsIgnoreCase("linux")) {
// 3
loadSO(path);
} else {
loadDLL(path);
}
}
...
}
简单来说，就是处理请求的代码用到这个类，然后类加载，执行static，结果执行System.loadLibrary失败了。
失败了也没啥，问题是，这个类是个底层框架里的类，然后失败原因也不打日志。
当时已经心里骂过人了，现在就不说啥了，说说当时处理过程。
处理经过
arthas使用watch查看方法执行上下文
当时以为是System.loadLibrary("TBASClientJNI");失败，抛了异常，进了catch分支，以为会进
loadDLL(path);
loadSO(path);
private static void loadSO(String path) throws SecurityException, UnsatisfiedLinkError {
String sep = System.getProperty("file.separator");
System.load(path + sep + "libTBASClient.so");
System.load(path + sep + "libTBASClientJNI.so");
}
这里看到最终会调System.load方法，就想用arthas的watch观察下参数：类似于下面这样：
watch java.lang.System load '{params, target, returnObj, throwExp}' -x 2
结果工具报错：
[arthas@110269]$ watch java.lang.System load
Affect(class count: 0 , method count: 0) cost in 31 ms, listenerId: 1
No class or method is affected, try:
1. Execute `sm CLASS_NAME METHOD_NAME` to make sure the method you are tracing actually exists (it might be in your parent class).
2. Execute `options unsafe true`, if you want to enhance the classes under the `java.*` package.
3. Execute `reset CLASS_NAME` and try again, your method body might be too large.
按照工具的第二条提示，设置了，也还是报错，反正，当时这条路是没有走下去。
当时也试了去watch当前类的loadSO方法，不知道为啥，也是没观察到东西，我们用的jdk1.7，不清楚有没有影响。
覆盖框架类，增加日志
上面报错这个类，在我们的TBASClientJNI-2.2.0.jar中，我想着还是覆盖框架类，加点日志试试吧，于是在应用中，新增了一个包名类名都一致的类：com.thinkive.tbascli.TBASCli，修改了其中的代码：
我们的应用，打出来的jar是在test-web.jar中，最终部署的时候，应用jar和依赖的框架jar是在同一个文件夹下，在同一个文件夹下的话，类加载的顺序是没法保证的，所以，我当时在开发环境验证了下，发现日志能看到，结果等我把改后的jar放到测试环境时，发现完全没生效，看不到日志，应该就是优先加载了旧的class。
当时也看了下，类加载的一个情况，利用arthas查看类来自哪个jar的哪个文件（以下截图来自开发环境，当时没截图）:
这里也扩展下，其他类加载相关的命令：
-
查看类加载器及hash
classloader -l
-
查看类加载器的加载路径
classloader -c 3bd3ac38
比较原机器和克隆机器文件差异
然后暂时也没啥好办法，看看是不是两边是不是漏复制了啥，或者不小心改到什么地方了。把两边的几个文件夹仔细对比了下，没发现啥问题。
也对比了一些环境变量，比如linux默认会
lsof立功
后面在两台机器上各种排查，命令一顿敲，后面发现，在原机器上执行lsof -p pid，查看进程打开的so文件时，发现两边不太一样。
这里还要补充解释下，前面大家以为我们只是一个so文件，其实是两个，如下，其中一个是xxxJNI.so，我们代码里也是去加载这个，而不带JNI的这个so，是xxxJNI.so的内部依赖的so。
[root@xxx-access ~]# ll /test-web/WebRoot/WEB-INF/classes |grep TBA
-rw-r--r-- 1 root root 20704 Feb 20 13:19 libTBASClientJNI.so
-rw-r--r-- 1 root root 103904 Feb 20 13:19 libTBASClient.so
所以，实际上来说，我们的jdk必须加载了这两个so，请求才能正常处理。
我在原机器上执行lsof的结果是：
[root@server172 ~]# lsof -p 28644|grep TBA
java 28644 root mem REG 253,1 103904 101004125 /usr/lib64/libTBASClient.so
java 28644 root mem REG 253,0 20704 21663079 /test-web/WebRoot/WEB-INF/classes/libTBASClientJNI.so
而在新机器执行的结果是：
[root@xxx-access ~]# lsof -p 110269|grep \\.so |grep TBA
java 110269 root mem REG 253,0 20704 34821647 /test_web/WebRoot/WEB-INF/classes/libTBASClientJNI.so
可以发现，原来的机器虽然正常运行，但是，加载的so竟然在不同文件夹下，带JNI的这个libTBASClientJNI.so，确实用的是项目路径下的；而那个libTBASClient.so，居然是/usr/lib64下的，我们确实没拷贝/usr/lib64下的那个so到新机器，估计就是这个原因了。
新机器上呢，只加载了一个so，少了一个so，估计这也就是问题原因了。
我在新机器上，试了两种改法，都有效果：
-
在/usr/lib64下放上那个libTBASClient.so
-
修改/etc/profile，设置：
export LD_LIBRARY_PATH=/test-web/WEB-INF/classes/:$LD_LIBRARY_PATH
为啥改了有效果呢，下面看看原理。
加载第一层so的原理剖析
回到报错的那行代码：
System.loadLibrary("TBASClientJNI");
了解它的最好的办法，还是在本地debug。
java.lang.System#loadLibrary
public static void loadLibrary(String libname) {
Runtime.getRuntime().loadLibrary0(Reflection.getCallerClass(), libname);
}
java.lang.Runtime#loadLibrary0
synchronized void loadLibrary0(Class fromClass, String libname) {
ClassLoader.loadLibrary(fromClass, libname, false);
}
内部实现如下：
static void loadLibrary(Class fromClass, String name,
boolean isAbsolute) {
// 1 获取classloader
ClassLoader loader =
(fromClass == null) ? null : fromClass.getClassLoader();
// 2 用系统property的值来初始化field：usr_paths/sys_paths
if (sys_paths == null) {
usr_paths = initializePath("java.library.path");
sys_paths = initializePath("sun.boot.library.path");
}
// 3 外部传参为false，进不去本分支，不管
if (isAbsolute) {
if (loadLibrary0(fromClass, new File(name))) {
return;
}
throw new UnsatisfiedLinkError("Can't load library: " + name);
}
if (loader != null) {
// 4 由调用本方法的类的classloader来负责查找library，由具体classloader覆写
String libfilename = loader.findLibrary(name);
if (libfilename != null) {
File libfile = new File(libfilename);
if (!libfile.isAbsolute()) {
throw new UnsatisfiedLinkError(
"ClassLoader.findLibrary failed to return an absolute path: " + libfilename);
}
if (loadLibrary0(fromClass, libfile)) {
return;
}
throw new UnsatisfiedLinkError("Can't load " + libfilename);
}
}
// 5 根据上文初始化处，这里即是从sun.boot.library.path 这个变量中加载
for (int i = 0 ; i < sys_paths.length ; i++) {
File libfile = new File(sys_paths[i], System.mapLibraryName(name));
if (loadLibrary0(fromClass, libfile)) {
return;
}
}
// 6 根据上文初始化处，这里即是从java.library.path 这个变量中加载
if (loader != null) {
for (int i = 0 ; i < usr_paths.length ; i++) {
File libfile = new File(usr_paths[i],
System.mapLibraryName(name));
if (loadLibrary0(fromClass, libfile)) {
return;
}
}
}
// Oops, it failed
throw new UnsatisfiedLinkError("no " + name + " in java.library.path");
}
可以看到上面注释，加载也就是从3个地方加载；
-
4处，首先从classloader加载
[arthas@110269]$ classloader -c 3bd3ac38 file:/test-web/WebRoot/WEB-INF/classes/ ... -
5处，从sun.boot.library.path加载
[arthas@110269]$ sysprop sun.boot.library.path KEY VALUE sun.boot.library.path /usr/local/java/jdk1.7.0_80/jre/lib/amd64 -
6处，从java.library.path加载
sysprop java.library.path
所以，我们就能解释如下的结果了：
[root@xxx-access ~]# lsof -p 110269|grep \\.so |grep TBA
java 110269 root mem REG 253,0 20704 34821647 /test_web/WebRoot/WEB-INF/classes/libTBASClientJNI.so
应该就是走了4处的逻辑，才加载到这个JNI的so。
那么，为啥又没加载到libTBASClient.so呢，我在网上看到的解释是，so内部加载其他依赖的so，这时候，内部已经不是java代码了，不可能走这段java.lang.ClassLoader#loadLibrary逻辑，所以，此时，就不是这段逻辑了。
加载so中依赖的so的加载逻辑
那么，对于libTBASClientJNI.so依赖的so，又是去哪里加载呢，这块呢，我的理解不是很深入，我的理解是，在windos机器，会去PATH环境变量中加载；在linux，会去环境变量LD_LIBRARY_PATH中指定的路径加载。
但根据我这边的现象看，比如最终是在/usr/lib64中找到了libTBASClientJNI.so，但我的LD_LIBRARY_PATH并没有设置/usr/lib64，所以，jvm的实现中估计还会根据java.library.path这个属性中的路径去查找。因为我程序中，查看arthas的sysprop，只有它下面有/usr/lib64这个路径。
java.lirary.path的初始值来自哪里
arthas查看
sysprop java.library.path即可看到。
cmd下查看（windows）
java -XshowSettings:properties
在windows下，java.library.path初始值来自PATH环境变量。
linux下java命令
linux下，有默认值，如上面这几个路径；另外，如果有设置LD_LIBRARY_PATH环境变量，那么java.library.path的值就等于默认的几个路径（/usr/lib64、/lib64、/lib、/usr/lib） + LD_LIBRARY_PATH的值。
总结
java加载第一层的so，主要是根据classloader去加载、其次是 sun.boot.library.path 、再其次是java.library.path。
加载第一层so依赖的so，在jdk中貌似也是根据java.library.path；如果是非jdk，应该是根据LD_LIBRARY_PATH环境变量。
而java.library.path的默认值（不显示设置的情况下），在windows下就是来源于PATH，在linux下来源于LD_LIBRARY_PATH和几个默认路径（/usr/lib64、/lib64、/lib、/usr/lib），具体可以执行java -XshowSettings:properties查看。
参考：
https://stackoverflow.com/questions/29968292/what-is-java-library-path-set-to-by-default
https://stackoverflow.com/questions/20038789/default-java-library-path
https://stackoverflow.com/questions/16227045/how-to-add-so-file-to-the-java-library-path-in-linux
通过arthas的vmtool查看内存对象
