gpt4 book ai didi

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

转载 作者:我是一只小鸟 更新时间:2023-08-12 22:31:33 25 4
gpt4 key购买 nike

前言

本周协助测试同事对一套测试环境进行扩容,我们扩容很原始,就是新申请一台机器,直接把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 。

最后此篇关于JDK中动态库加载路径问题,一文讲清的文章就讲到这里了,如果你想了解更多关于JDK中动态库加载路径问题,一文讲清的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com