日期:2014-05-16 浏览次数:20894 次
?在java调用jni或者JNA时候,报
????? error while loading shared libraries: libprint.so: cannot open shared object file: No such file or directory。这便是典型的找不到动态库的错误.
?
具体说来,动态链接器ld.so按照下面的顺序来搜索需要的动态共享库:
1.ELF可执行文件中动态段中DT_RPATH所指定的路径。这实际上是通过一种不算很常用,却比较实用的方法所设置的:编译目标代码时,可以对gcc加入链接参数“-Wl,-rpath”指定动态库搜索路径;
2.环境变量LD_LIBRARY_PATH指定的动态库搜索路径;
3./etc/ld.so.cache中所缓存的动态库路径(如果支持ld.so.cache的话)。这可以通过修改配置文件/etc/ld.so.conf中指定的动态库搜索路径来改变;
4.默认的动态库搜索路径/lib;
5.默认的动态库搜索路径/usr/lib。
在嵌入式Linux系统的实际应用中,1和2被经常使用,也有一些相对简单的的嵌入式系统会采用4或5的路径来规范动态库。3在嵌入式系统中使用的比较少,因为有很多系统根本就不支持ld.so.cache。
4和5的方式非常简单,只要将所需要的库放到/lib或/usr/lib就可以解决找不到库的问题,不过对于大一些的系统来说,不太方便管理。1和2的方式要稍微复杂一些。
?
?
???????? 项目中使用到JNI来加载本地库,项目自身(web使用)和对外接口(不是web使用)都用到相同的DLL,当web使用访问正常时,接口访问就报错;相反当接口访问正常时,web使用也会报错。错误信息:java.lang.UnsatisfiedLinkError: Native Library XX.dll already loaded in another。
?
分析:这种错误在我们使用热启动方式发布某个使用了JNI技术的Web应用时,并将调用年native方法的jar包独立部署在该应用下面,当我们的Web应用有了更新以后,在调用到该jar包封装的native方法时,会抛出该错误。(以上OS为Windows,若是Linux或Unix,应该是xxx.so 报错) 这是因为Web服务器已经在第一次加载该应用时,已经load了该dll,当该应用被再次热启动时,该dll将重新被加载,于是报错。解决方案: 一、将含有JNI调用的jar包部署在Web服务器的公用lib库中。Web应用再发布时可以不用加载;二、jar包部署不变,在该Web中实现一个listener,监听是否第一次启动,若不是第一次启动,屏蔽掉该jar包所含dll的加载。
?
1、原因 ??????? 查询资料后才得知:Java虚拟机为了在JNI本地库中确保基于classloader的命名空间隔离,因而不允许一个JNI本地库被两个不同的classloader加载。而JBoss中web应用的classloader是独立的,也就是说每个web应用都有一个专属的classloader,这样就出现两个classloader加载同一JNI本地库的情况。
?
?
?
2、解决方法
???????? 解决这个问题其实很简单,将访问到jni的代码单独提取出来,并不直接让项目自身的classLoader加载,则是让其由systemLoader加载 即可。一种方法就是将这部分代码,单独封装成一个jar,放到java的systemLoader可以加载的地方,如lib/ext目录下。然后,项目中 仍然去调用此代码。由于访问dll的代码由systemLoader加载,因此,多个项目同时访问同一个dll时,即可避免再次加载了。因为,第二个项目 在访问时,寻找到的类,已经被systemLoader加载过了,因此项目本身的classLoader就不会再去加载这个类了。
??????? 在Weblogic中,虽然不同的web应用使用不同的classloader,但是web应用classloader的父classloader是相同的,这样根据双亲委托模型只要让父classloader加载JNI本地库就可以避免被多个classloader加载。将so放在共享目录(System.getProperty("java.library.path"))的lib目录的并采用System.loadLibrary(libName)即可。
重新Weblogic问题就可以解决。
?