?在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问题就可以解决。

?