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查看内存对象
https://arthas.aliyun.com/doc/vmtool.html
https://blog.csdn.net/qq_40911404/article/details/121741268
JDK中动态库加载路径问题,一文讲清的更多相关文章
- linux和windows动态库加载路径区别
# linux和windows动态库加载路径区别 ### 简介------------------------------ linux加载动态库的路径是系统目录/lib和/usr/lib.- wind ...
- linux 动态库加载路径修改
1.在 /etc/ld.so.conf 文件中添加搜索路径,重启或者 ldconfig 生效: 2.在 /etc/ld.so.conf.d 目录下添加 *.conf 文件,其中可以添加搜索路径,重启获 ...
- linux动态库加载路径修改
1.在 /etc/ld.so.conf 文件中添加搜索路径,重启或者 ldconfig 生效: 2.在 /etc/ld.so.conf.d 目录下添加 *.conf 文件,其中可以添加搜索路径,重启获 ...
- linux动态库加载RPATH, RUNPATH
摘自http://gotowqj.iteye.com/blog/1926771 linux动态库加载RPATH, RUNPATH 链接动态库 如何程序在连接时使用了共享库,就必须在运行的时候能够找到共 ...
- Linux 动态库加载
动态库运行时搜索顺序 1.LD_PRELOAD LD_PRELOAD是一个环境变量,用于动态库加载,动态库加载的优先级最高: 2.-wl,-rpath 编译目标代码时指定的动态库搜索路径(指的是用-w ...
- libdl.so 动态库加载、查找
使用libdl.so库 动态库加载原理 动态库中函数的查找已经封装成 libdl.so,有4个函数: dlopen : 打开一个动态库 dlsym : 在打开的动态库里找一个函数 dlclo ...
- linux下添加动态链接库路径、动态库加载等方法
linux下添加动态链接库路径的方法 2017年01月20日 10:08:17 阅读数:5596 Linux共享库路径配置 Linux下找不到共享库文件的典型现象为明明已经安装某个软包(如libn ...
- linux动态库加载时搜索路径
摘自http://gotowqj.iteye.com/blog/1926613 对动态库的实际应用还不太熟悉的读者可能曾经遇到过类似“error while loading shared librar ...
- Vue 动态图片加载路径问题和解决方法
最近在做一个树形结构的组件,使用了Vue和element UI中el-tree组件.因为树中每个节点都需要显示一个图标图片,并且需要根据后台传入的数据类型动态地显示,所以图片的路径需要动态地加载.下面 ...
- linux动态库加载的秘密
摘自http://gotowqj.iteye.com/blog/1926734 摘自http://www.360doc.com/content/14/0313/13/12747488_36024641 ...
随机推荐
- 2021-11-06:3的幂。给定一个整数,写一个函数来判断它是否是 3 的幂次方。如果是,返回 true ;否则,返回 false 。整数 n 是 3 的幂次方需满足:存在整数 x 使得 n ==
2021-11-06:3的幂.给定一个整数,写一个函数来判断它是否是 3 的幂次方.如果是,返回 true :否则,返回 false .整数 n 是 3 的幂次方需满足:存在整数 x 使得 n == ...
- Structured Streaming 的异常处理 【Concurrent update to the log. Multiple streaming jobs detected】
目录 异常信息 一.异常表象原因 1.异常源码: 2.打个断点 二.解决方案 1.可以通过代码指定各分区的开始offset 2.不删除而是更改checkpoint offset下的批次文件 三.异常背 ...
- dnu
背景 作为一个喜欢搬运 YouTube 视频的网友,我发现将视频下载下来再上传到 B 站十分繁琐,因此我决定开发一个小工具,能够方便快捷地将 YouTube 视频下载并上传至 B 站,以节省我的时间和 ...
- 领福利 | 腾讯千帆HR数字化专场,教你数字时代的技术招聘秘笈
HR难,做技术招聘的HR难上加难 技术部门急需用人,收到的简历却寥寥无几? 推了简历,却被用人部门告知完全不合适? 候选人过了面试,却鸽了offer? 桥豆麻袋! 腾讯千帆联合ShowMeBug举办 ...
- 手把手实践丨基于STM32+华为云设计的智慧烟感系统
摘要:当前基于STM32和华为云,设计了一种智慧烟感系统,该系统可以检测烟雾,同时将检测到的数据上传到云端进行处理和分析. 本文分享自华为云社区<基于STM32+华为云设计的智慧烟感系统> ...
- 远程挂载 NFS 共享目录引发死机问题
集群的存储空间有限,把一些历史的归档数据放在了公司的另外一台老旧存储服务器上,并使用 NFS 把它挂载到了 log 节点.周末的时候机房空调故障,旧存储服务器挂掉了!周一上班,在集群登陆节点使用df ...
- 【VS Code 与 Qt6】运用事件过滤器批量操作子级组件
如果某个派生自 QObject 的类重写 eventFilter 方法,那它就成了事件过滤器(Event Filter).该方法的声明如下: virtual bool eventFilter(QObj ...
- 这就是艺术,优雅的二维码生成器「GitHub 热点速览」
平时如果没有需要一般那团黑乎乎的二维码,估计路过的人看见第一眼就不会再看第二眼.但是假若,它是个帅哥靓妹,估计就不同了,更别提像是艺术画一样,将编码图案融入到画里的二维码生成器 qrbtf 作者的新作 ...
- python 星号(*) 还能这么用
哈喽大家好,我是咸鱼 今天跟大家介绍一下 python 当中星号(*)的一些用法 首先大家最常见的就是在 python 中 * 是乘法运算符,实现乘法 sum = 5 * 5 # 25 除此之外,还有 ...
- 区块链应用:椭圆曲线数字签名算法ECDSA
1 椭圆曲线密码学 椭圆曲线密码学(Elliptic Curve Cryptography,缩写ECC),是基于椭圆曲线数学理论实现的一种非对称加密算法.椭圆曲线在密码学中的使用是在1985年有Nea ...