首页 > 其他分享 >JDK中动态库加载路径问题，一文讲清

JDK中动态库加载路径问题，一文讲清

时间：2023-08-12 15:45:59浏览次数：51  
标签：java JDK library 讲清 so usr path 加载

前言

本周协助测试同事对一套测试环境进行扩容，我们扩容很原始，就是新申请一台机器，直接把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，修改了其中的代码：

image-20230812133005715

我们的应用，打出来的jar是在test-web.jar中，最终部署的时候，应用jar和依赖的框架jar是在同一个文件夹下，在同一个文件夹下的话，类加载的顺序是没法保证的，所以，我当时在开发环境验证了下，发现日志能看到，结果等我把改后的jar放到测试环境时，发现完全没生效，看不到日志，应该就是优先加载了旧的class。

当时也看了下，类加载的一个情况，利用arthas查看类来自哪个jar的哪个文件（以下截图来自开发环境，当时没截图）:

image-20230812133942732

这里也扩展下，其他类加载相关的命令：

  • 查看类加载器及hash

    classloader -l

    image-20230812133603554

  • 查看类加载器的加载路径

    classloader -c 3bd3ac38

    image-20230812134258446

比较原机器和克隆机器文件差异

然后暂时也没啥好办法，看看是不是两边是不是漏复制了啥，或者不小心改到什么地方了。把两边的几个文件夹仔细对比了下，没发现啥问题。

也对比了一些环境变量，比如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，估计这也就是问题原因了。

我在新机器上，试了两种改法，都有效果：

  1. 在/usr/lib64下放上那个libTBASClient.so

  2. 修改/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

    image-20230812144226302

所以，我们就能解释如下的结果了：

[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这个路径。

image-20230812144226302

java.lirary.path的初始值来自哪里

arthas查看

sysprop java.library.path即可看到。

cmd下查看（windows）

java -XshowSettings:properties

image-20230812151126871

在windows下，java.library.path初始值来自PATH环境变量。

linux下java命令

image-20230812151254735

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

标签：java,JDK,library,讲清,so,usr,path,加载
From： https://www.cnblogs.com/grey-wolf/p/17624892.html

相关文章

  • Flutter中的加载指示器
    Flutter提供了多种加载指示器样式供选择。你可以使用CircularProgressIndicator以外的其他加载指示器样式来替换原有的加载指示器。以下是一些常见的加载指示器样式，你可以根据自己的需要选择其中之一：一、LinearProgressIndicator：线性进度指示器，呈现为水平进度条。LinearProgressInd......
  • Devexpress xtraTabControl1实现多标签页选项卡，关闭选项卡，刷新重新加载
    //选项卡Dictionary<string,XtraTabPage>dictXtraTabPage=newDictionary<string,XtraTabPage>();Dictionary<string,Form>dictXtraForm=newDictionary<string,Form>();publicvoidShowMDIForm(string......
  • Vue 路由懒加载
    1路由懒加载的原理路由懒加载是一种优化技术，用于延迟加载应用程序中的路由组件。它可以提高初始加载速度并减少资源消耗，特别适用于大型单页应用。1.1为什么要使用路由懒加载当应用程序包含多个页面和路由时，如果在初始加载时将所有路由组件都打包到一个文件中，会导致初始加载时......
  • 传奇架设服务端传奇GOM引擎不加载插件，写入了不加载的解决方法
    vsftpd（verysecureFTPdaemon）是Linux下的一款小巧轻快、安全易用的FTP服务器软件。本教程介绍如何在Linux实例上安装并配置vsftpd。前提条件已创建ECS实例并为实例分配了公网IP地址。背景信息FTP（FileTransferProtocol）是一种文件传输协议，基于客户端/服务器架构，支持以下两种工作模......
  • 传奇架设服务端传奇GOM引擎不加载插件，写入了不加载的解决方法
    MirServer\Mir200下面的PlugList.txt文件里写入了插件dll名称，但是启动服务端时还是不加载，主要是因为是因为插件目录不正确，以下告诉大家解决方法。首先关掉M2，然后打开“D:\MirServer\Mir200\!Setup.txt”文件搜索该文件，搜索关键字是“Plugdir”把搜索到的那一行全部删除就可以了，如......
  • JDK和Spring版本兼容性
      SpringVersionJavaVersion5.xJDK8,9,10,11,12,134.3.xJDK6,7,84.2.xJDK6,7,84.1.xJDK6,7,84.0.xJDK6,7,83.2.xJDK6,73.1.xJDK5,6,73.0.xJDK5,6......
  • JAVA | 如何安装JDK并配置
    安装JDK首先去Oracle官网。（网址随时会变，自行百度其官网就可以）点击产品->java。点击DownloadJavanow.我们可以下载JDK20、JDK17、下面还可以下载JDK8和JDK11.我们点击自己对应的操作系统下载，下载的时候需要一个Oracle账户，自己注册一下即可。下载完毕：双击安装：下一步。......
  • mac 进入虚拟环境并加载本地模块到虚拟环境下
    1.cd到虚拟环境目录1769cdbossjob-recruiter1770ls1771cdbin1775./activate1776sourceactivate激活虚拟环境2.进入当前目录下下载本地模块1787cdbossjob-auth-lib1788ls1789pythonsetup.pyinstall或pipinstall-e.只针对把公共代......
  • 初学者Java应该学jdk什么版本？
    Java的多个版本在历史上都有其重要性，但对于初学者而言，选择合适的版本来学习非常关键。以下是对于初学者来说选择JDK版本的一些建议：1.考虑最新稳定版本最新版本：目前JDK17是最新的长期支持版本（LTS）。选择最新的LTS版本作为学习起点是个不错的选择，因为它结合了稳定性和较新的特性。2.......
  • 利用pytorch自定义CNN网络（五）：保存、加载自定义模型【转载】
    本文转载自：PyTorch|保存和加载模型1.简介本文主要介绍如何加载和保存PyTorch的模型。这里主要有三个核心函数：torch.save：把序列化的对象保存到硬盘。它利用了Python的pickle来实现序列化。模型、张量以及字典都可以用该函数进行保存；torch.load：采用pickle将反序列......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99