从commons-dbcp源码学习设计思路

由于整个连接池的性能是由commons-pool决定的,有空再讲解一下commons-pool的实现,特别是1.x和2.x的区别。
此次分析的是commons-dbcp 1.x源码,对应commons-pool 1.x版本。

commons-dbcp怎样与commons-pool集成?

commons-dbcp怎样与commons-pool集成

如上图所示,集成commons-dbcp的时候采用BasicDataSource这个实现类,它的实际功能是交给PoolingDataSource的(内部是通过commons-pool来管理连接对象)。
不过,我不是很理解为什么要这么设计?

commons-dbcp的连接有什么特别?

commons-dbcp的连接有什么特别

连接这种对象有点特殊的,所以commons-dbcp提供了一些connection方面的增强特性。例如:

  • PoolGuardConnectionWrapper是最终客户端拿到的对象,能够防止多次关闭等误操作
  • PoolableConnection是PoolGuardConnectionWrapper内部的对象,可以结合pool进行管理,最大的优势就是可以保留客户端代码无需任何改动。实际上,很多自带生命周期api的对象,一旦池化之后都会考虑这么设计。
  • PoolingConnection是开启statement pool的时候PoolableConnection的内部对象,内部采用一个KeyedObjectPool进行管理(key主要是通过执行的sql语句来生成的)。不过这种对象一般不需要池化

如何优化Connection、Statement、ResultSet的生命周期管理?

jdbc的api有个非常烦人的地方,就是每个Connection、Statement、ResultSet对象都是需要关闭。所以写起来代码繁琐的,很多人就跳过这些健壮性代码。
我研究了一下dbcp的实现,发现它能够发现未关闭的Statement、ResultSet对象,并在适当的时候进行关闭。

如何优化生命周期管理

具体实现思路是这样的:

  • 需要实现生命周期管理的对象需要继承AbandonedTrace,这包括了DelegatingStatement、DelegatingResultSet、DelegatingConnection等
  • 通过DelegatingConnection生成的statement、resultset等都是带Delegating的,也就是带trace特性的。
  • 对于上图,有个特别的是DelegatingConnection的trace可能包括ResultSet,这个主要由DelegatingDatabaseMetaData产生的。因为metadata的查询不需要先有statement。
  • 处理流程调用connection.close(), 会返回到池中(见PoolableConnection), 触发PoolableConnectionFactory的passivateObject(commons-pool的内置回调),最后触发DelegatingConnection的passivate,在这里会递归检查所有的trace。
  • 注意的是,DelegatingConnection的close方法除了触发trace对象的关闭,还会关闭底层的连接对象。

AES256算法遇到 Illegal key size or default parameters的解决办法

java.security.InvalidKeyException: Illegal key size or default parameters
	at javax.crypto.Cipher.a(DashoA13*..)
	at javax.crypto.Cipher.a(DashoA13*..)
	at javax.crypto.Cipher.a(DashoA13*..)
	at javax.crypto.Cipher.init(DashoA13*..)
	at javax.crypto.Cipher.init(DashoA13*..)
	at com.xxx.AESWithFileKey.encrypt(AESWithFileKey.java:81)
	at com.xxx.AESWithFileKey.main(AESWithFileKey.java:148)

Google到问题原因,链接地址如下:http://stackoverflow.com/questions/6481627/java-security-illegal-key-size-or-default-parameters

根据回答找到下载新jar包链接地址如下:http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html
把里面的两个jar包:local_policy.jar 和 US_export_policy.jar 替换掉原来安装目录C:\Program Files\Java\jre6\lib\security 下的两个jar包就可以了

上面是在oracle的jdk出现的。 如果是IBM的jdk出现问题,参考调整 Version 7.0 应用程序的 Web Services Security

关于android ndk的jni总结

开发工具支持

主要要点如下,更详细的应该参考官方文档:

  1. 需要下载android ndk,并设置ANDROID_NDK_HOME并设置PATH, 在eclipse中顺便也设置一下。
  2. eclipse支持android ndk开发,只需要在项目中右键添加Android Tools > Add Native Support即可。

配置文件

主要配置文件有2个: Android.mk,Application.mk,详细配置还是应该阅读官方文档。下面说一下常用配置。

Application.mk

详细配置参考https://developer.android.com/intl/zh-cn/ndk/guides/application_mk.html

  • APP_STL := stlport_static 设置是否依赖的C++标准库特性,非常重要,详细参数参考https://developer.android.com/intl/zh-cn/ndk/guides/cpp-support.html#runtimes
  • APP_ABI := armeabi armeabi-v7a 设置需要生成so的平台,可以指定或者用all
  • APP_OPTIM := release 生成debug还是relase版本,默认就是release

Android.mk

详细配置参考https://developer.android.com/intl/zh-cn/ndk/guides/android_mk.html
这个配置是可以一次性生成多个so文档的,只需要区分不同的LOCAL_MODULE、LOCAL_SRC_FILES即可。

发现ndk好像默认不支持c/c++混编,所以最好统一成cpp后缀。又或者是我不清楚实际是可以的

  • LOCAL_LDLIBS += -L$(SYSROOT)/usr/lib -lz -llog -landroid 依赖的库,这个例子表示依赖zlib、android log模块及android运行库
  • LOCAL_MODULE := protect 生成的模块名
  • LOCAL_SRC_FILES := NativeApplication.cpp NativeHelper.cpp arcfour.cpp MultiDex.cpp 就是把so需要的相关源文件列出来

jni编程

剩下的内容和Android都没特别关系了,都是java jni的知识。 对于android中jni的各种限制,可以参考官方文档: http://developer.android.com/intl/zh-cn/training/articles/perf-jni.html

生成native方法的头文件

和普通java的没区别,用javah就可以了,就是需要在classpath中添加android的jar即可。举例:

cd native
javah -cp ./bin/classes;D:\05programs\Android\android-windows\platforms\android-19\android.jar -d ./jni com.huawei.g3.proxy.NativeApplication

默认生成的方法名是有特殊命名规则的(具体规则请自行查阅资料),如果需要不同名字,可以在JNI_OnLoad中进行动态注册,参考如下:

void load(JNIEnv * env, jclass clz, jobject obj);
void run(JNIEnv * env, jclass clz, jobject obj);
static JNINativeMethod methods[] = { { "load", "(Landroid/app/Application;)V", (void*) load }, { "run", "(Landroid/app/Application;)V",
        (void*) run } };

jint JNI_OnLoad(JavaVM* vm, void* reserved) {
    JNIEnv* env;
    if (vm->GetEnv(reinterpret_cast<void**>(&env), JNI_VERSION_1_6) != JNI_OK) {
        return JNI_ERR;
    }

    // Register methods with env->RegisterNatives.
    int len = sizeof(methods) / sizeof(methods[0]);
    jclass native = env->FindClass("com/huawei/g3/proxy/NativeApplication");
    if (env->RegisterNatives(native, methods, len) < 0) {
        return JNI_ERR;
    }
    return JNI_VERSION_1_6;
}

调用java对象、方法、属性

当需要和java进行交互的时候,需要通过特定的api进行调用(类似java的反射,比较麻烦),这种方式是绕过java安全检查机制的。

首先,需要了解jni中的类型表示法(基本就是java字节码那套表示法),特别注意的是内部类的写法

Type Signature Java Type 备注
Z boolean  
B byte  
C char  
S short  
I int  
J long  
F float  
D double  
L fully-qualified-class ; fully-qualified-class Ljava/lang/String; 或内部类Lcom/test/A$B;
[ type type[] [I 或 [Ljava/lang/String;
( arg-types ) ret-type method type ()V 或 (Ljava/lang/String;I)Z
V void  

看懂上面一套表示法,下面的代码也比较容易理解了:

jclass contextClass = env->FindClass("android/content/Context");
jfieldID fieldID = env->GetStaticFieldID(contextClass, "MODE_PRIVATE", "I");
jint mpFv = (jint) env->GetStaticIntField(contextClass, fieldID);

jstring _payload_dex = env->NewStringUTF("payload_dex");

jclass appClass = env->FindClass("android/app/Application");
jmethodID methodID = env->GetMethodID(appClass, "getDir", "(Ljava/lang/String;I)Ljava/io/File;");
jobject dex = env->CallObjectMethod(obj, dirMd, _payload_dex, mpFv); //obj是Application对象,传进来的

需要注意的时候,FindClass参数中类名是不以L开头,不以;结束的

上面的代码,其实就完成了下面一句java代码:

File dex = obj.getDir("payload_dex", Context.MODE_PRIVATE);

基本套路都是一样的: 找到类、找到方法或属性、调用方法或调用属性,对应的是jclass、jmethodID、jfieldID几种类型。
详细的方法应该参考jni的官方文档,也很好理解。

* CallStatic<type>Method
* Call<type>Method
* SetStatic<type>Field
* Set<type>Field
* GetStatic<type>Field
* Get<type>Field

这里主要讲一下注意点:

  • 不带后缀、带V、带A的方法名有什么区别

以CallObjectMethod为例,会存在三个方法: CallObjectMethod, CallObjectMethodV, CallObjectMethodA 这个方法都是返回Object对象(jobject)的,效果是没什么区别的,只在于参数传递机制上存在区别。

  • 类型能不完全匹配么?

像java反射那样,获取方法是可以不指定参数类型的。但是jni的类型是必须完全匹配的, 例如找方法void get(HashMap map)的时候,需要使用”(Ljava/util/HashMap;)V”, 而不能使用”(Ljava/util/Map;)V”。

这种问题在处理api兼容性的时候就特别突出。例如下面的代码:

    if (version < 19) {
        //using hashmap
        ft1 = "Ljava/util/HashMap;";
        ft2 = "java/util/HashMap";
    } else {
        //using arraymap
        ft1 = "Landroid/util/ArrayMap;";
        ft2 = "android/util/ArrayMap";
    }

    jobject mPackages = _getField(env, currentActivityThread, "mPackages", ft1);
    ...    
    jmethodID methodID = _getMethod(env, ft2, "get", "(Ljava/lang/Object;)Ljava/lang/Object;");
    jobject wr = env->CallObjectMethod(mPackages, methodID, (jobject) pk);

在java中就可以不用那么烦躁,获取mPackages对象,强制转换成两个类的共同接口Map即可,省事很多。

  • 关于引用、字符串、异常处理

在jni中主要有LocalRef、GlobalRef两种。正常产生的jobject对象,是属于LocalRef的,它的生命周期在当前线程的当前方法有效,类似于c/c++在栈分配的对象。
官方tips也提到了,即使这个对象本身在本地方法返回之后仍然存在,这个引用也是无效的。而实际上只预留了16个LocalRef空间

所以在使用上需要特别注意:

  1. 不要过度分配LocalRef,及时通过DeleteLocalRef方法进行删除。或者通过EnsureLocalCapacity/PushLocalFrame预留更多,不过貌似很少需要。
  2. 如果需要在多次调用中保留,应该采用GlobalRef。通过NewGlobalRef/DeleteGlobalRef手动维护引用。
  3. 和反射一样,查找类、获取方法、获取属性都是有消耗的,在频繁调用的jni方法中,应该通过GlobalRef预先保留相关对象。
  4. 对于stirng类,如果和原生c字符串进行转换操作的时候,需要注意释放内存。
  5. 虽然C++本身也有异常处理,但是切记空指针异常不同于java,需要注意可能为NULL的代码。
  6. 不像java传参是传值(对象是隐含指针传递),在c++中要注意区分传值、传指针、传引用。

通过GlobalRef优化jni的例子

注意: jint等基本类型、jmethodID、jfieldID都不是jobject,不需要管理引用。

static jobject decryptCipher;

jint JNI_OnLoad(JavaVM* vm, void* reserved) {
        ...
	jobject localDecryptCipher = env->CallStaticObjectMethod(cipher, mid,
			desbuf);
	decryptCipher = (jobject) env->NewGlobalRef(localDecryptCipher);
	env->DeleteLocalRef(localDecryptCipher);
}

void JNI_OnUnload(JavaVM *vm, void *reserved) {
        ...
	if (decryptCipher != NULL) {
		env->DeleteGlobalRef(decryptCipher);
	}
	if (encryptCipher != NULL) {
		env->DeleteGlobalRef(encryptCipher);
	}
}

操作java字符串、c字符串的例子

    const char *c_msg2 = env->GetStringUTFChars(dataDir, NULL);  // dateDir是jstring对象
    string libPath(c_msg2);
    env->ReleaseStringUTFChars(dataDir, c_msg2); // 和GetStringChars不同,GetStringUTFChars方法会分配内存并进行拷贝到c字符串,所以需要手动释放
    libPath.append("/lib");
    LOGI("lib path is %s", libPath.c_str());
    jstring libDir = env->NewStringUTF(libPath.c_str()); // 重新转换成jstring

weblogic 11g类加载问题总结

本人在此之前甚少接触weblogic,家里的weblogic也是第一次安装的。如果发现错误,敬请指正。

问题描述

XX局点升级weblogic为11g,重新发包出错。现在记录一下处理的各种问题总结。

错误1: apache commons某些包的方法没有找到

这是最早出现的问题,会出现类似下面的错误信息。

<2015-10-14 下午05时57分30秒 CST> <Error> <HTTP> <BEA-101017> <[ServletContext@1385406679[app:XXService module:XXService path:/XXService spec-version:2.5]] Root cause of ServletException.
java.lang.NoSuchMethodError: org.apache.commons.io.FileUtils.copyInputStreamToFile(Ljava/io/InputStream;Ljava/io/File;)V
  • 原因分析

这是weblogic部署最常见的问题,因为weblogic会自带I一些commons-*的包,这些包的版本还比较旧。具体可以见WEBLOGIC_HOME/modules目录的jar包。

  • 此次采用的处理方式

添加weblogic.xml并设置prefer-web-inf-classes,即优先加载web应用下的类

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app>
	<container-descriptor>
		<prefer-web-inf-classes>true</prefer-web-inf-classes>
	</container-descriptor>
</weblogic-web-app>

错误2: jsp使用jstl时出现SAXParserFactory的ClassCastException

这是使用prefer-web-inf-classes为true之后出现的问题,会出现类似下面的错误信息。

The validator class: "org.apache.taglibs.standard.tlv.JstlCoreTLV" has failed with the following exception: "java.lang.ClassCastException: weblogic.xml.jaxp.RegistrySAXParserFactory cannot be cast to javax.xml.parsers.SAXParserFactory".
  • 原因分析

这是weblogic部署很常见的问题,jstl会调用sax,sax是通过spi机制加载实现,获取是weblogic的实现,但它使用的是jdk自带的javax.xml.parsers.SAXParserFactory接口。 刚好web应用下也带了jar包xml-apis-1.x.jar,它也有javax.xml.parsers.SAXParserFactory这个接口。根据prefer-web-inf-classes的设置,jstl代码中用的是这个接口。 由此可知,使用classloader并不一样,无法转换。

  • 此次采用的处理方式

删除WEB-INF/lib/xml-apis-1.x.jar后本地测试该问题恢复。

错误3: 出现QName的LinkageError

这是错误2解决后,继续解析spring时出现的问题。

  • 原因分析

这个问题和上面的差不多,太细就不深究了。

  • 此次采用的处理方式

这种情况下,如果使用prefer-web-inf-classes为true,则需要排除存在QName的jar包并删除,但最后没有采用(改动太大,得不偿失)。
所以这次重新设置了prefer-web-inf-classes为false,但仍然优先加载commons,如下:

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app>
	<container-descriptor>
		<prefer-web-inf-classes>false</prefer-web-inf-classes>
    <prefer-application-packages>  
        <package-name>org.apache.commons.*</package-name>
    </prefer-application-packages> 
	</container-descriptor>
</weblogic-web-app>

修改后本地测试ok,但发布到生产仍然失败。

错误4: MemCachedClient获取key失败(序列化问题)

错误3处理后,发布到生产仍然出错,报错信息如下:

18:44:57.337 [[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] ERROR com.danga.MemCached.MemCachedClient - ++++ exception thrown while trying to get object from cache for key: init_error_key_0098
18:44:57.351 [[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] ERROR com.danga.MemCached.MemCachedClient - com.xxx.hnxx.mybatis.entity.PlaterrorCodeBean
java.io.IOException: com.xxx.hnxx.mybatis.entity.PlaterrorCodeBean
	at com.schooner.MemCached.ObjectTransCoder.decode(Unknown Source) ~[MemCached-2.6.6.jar:na]
	at com.schooner.MemCached.AscIIClient.get(Unknown Source) [MemCached-2.6.6.jar:na]
	at com.schooner.MemCached.AscIIClient.get(Unknown Source) [MemCached-2.6.6.jar:na]
	at com.schooner.MemCached.AscIIClient.get(Unknown Source) [MemCached-2.6.6.jar:na]
	at com.danga.MemCached.MemCachedClient.get(Unknown Source) [MemCached-2.6.6.jar:na]
	at com.xxx.hnxx.cache.mencached.MemcacheManagerClient.get(MemcacheManagerClient.java:162) [MemcacheManagerClient.class:na]

上面的错误信息表示获取init_error_key_0098这个可以的时候失败,实际上这个key是在应用启动的时候就塞进去的。

  • 原因分析

这里有很多意想不到的事情,所以详细解释一下。

首先,这个出现了IOException让人联想到是否memcached服务器连接的问题。
实际上是因为库在实现java对象放入memcached的时候,有一个序列化/反序列化的过程(就是java自带的那个),在反序列化的时候找不到类会出现ClassNotFoundException,然后库将错误信息(就是一个类名)取出重新包装为IOException。
所以,这实际上是一个类找不到的问题。

再者,这个问题一开始在家里的weblogic没法重现。后来我重新检查了生产上weblogic的启动日志才发现了一些差异。
关键信息如下所示,生产上的weblogic在domain的lib目录也是有jar包的,而家里的是没有的。尝试修改把jar包也拷贝一份,果然重现。

<2015-10-14 下午06时44分36秒 CST> <Notice> <WebLogicServer> <BEA-000395> <Following extensions directory contents added to the end of the classpath:/weblogic/bea/user_projects/domains/PLATFORM_DOM/lib/MemCached-2.6.6.jar:/weblogic/bea/user_projects/domains/PLATFORM_DOM/lib/MyXMLSerializer-1.0.0.jar...

最后,这个问题就好解释多了。

  1. 需要序列化/反序列化的类是在com.huawei下面的,这部分类指在web应用中存在。在system classloader是找不到的。
  2. 序列化/反序列化时候,都是由web应用中的类,调用memcached库去实现的(虽然web应用中也有,但是根据prefer-web-inf-classes设置,加载的是domain中lib目录的)
  3. 序列化只是没什么特别。但是反序列化需要加载类,很明显system classloader(memcached库的classloader)是加载不到web应用中的类的。
  • 此次采用的处理方式

有好几种方式,都列举一下:

  1. 删除domain中的jar包,这样就会加载到web应用中的类,让库和需要序列化的类都有web classloader加载
  2. 让库也由web优先加载,如下所示 ```xml
false org.apache.commons.* com.danga.* com.schooner.*
3. 指定memcached库进行反序列化时的classloader,如下所示:
```java
        ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
        // MemCachedClient实例化时,会持有SockIOPool.getInstance()单利的引用
        cachedClient = new MemCachedClient((String)null, true, false, classLoader, null);

个人推荐的优先级是2 - 3 - 1, 尽量做到容器无关,并少动全局的东西。由于目前生产上的weblogic版本已经回退,待后续上生产验证。

weblogic的类加载器介绍

  • 整体的类加载器层次如下(只关注war部分),并采用标准的双亲委托加载机制
    WebLogic Server System classloader (classpath、<domain>/lib)
    Filtering classloader (空)
    Application classloader (EJB JARs、APP-INF/lib、APP-INF/classes、Manifest Class-Path in EJB JARs)
    Web application classloader (WAR、Manifest Class-Path in WAR)
    
  • Web application classloader可以通过weblogic.xml中的prefer-web-inf-classes优先加载war中的类,找不到才向上请求
  • Filtering classloader并不会加载任何类,而是起到控制类加载优先级的作用。通过配置可以限制对于指定的类不再向上请求,也就是限制范围内加载
  • 配置prefer-application-packages/prefer-application-resources的话,prefer-web-inf-classes必须配置为false
  • 资源(resource)的加载顺序,在开启Filtering之后,顺序为App - Web - System(App、Web仍然是符合双亲委托的)

参考材料

  • http://docs.oracle.com/cd/E23943_01/web.1111/e13712/weblogic_xml.htm#WBAPP599
  • http://docs.oracle.com/cd/E12839_01/web.1111/e13706/classloading.htm#WLPRG284
  • http://tobato.iteye.com/blog/1845969
  • http://tobato.iteye.com/blog/1483020

Websphere共享库加载顺序问题

问题描述

昨天收到有个童鞋发来的一个问题咨询,如下图所示。

问题截图

提到几个疑问:

  1. 配置如图所示,然后共享库和项目自身lib下都有一个“xxxx-common.jar”,如果项目用到jar包里面的一个类,将会是共享库的还是自身lib的呢?发现是用的lib里边的。
  2. 现网情况也是xxlib和lib下都有那jar包,但是根据日志来看,是用共享库的。

我的疑惑

现网的配置如何,暂时没查明。不过就开发环境的配置来看,我一直认为Parent First应该会走共享库的,目前的现象和我掌握的知识不匹配。

于是,我上网搜索了一下Websphere关于共享库的资料,主要的链接如下:

  • http://www.ibm.com/developerworks/cn/websphere/library/techarticles/haoaili/0512/
  • http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/tcws_sharedlib_nativelib.html?lang=zh
  • https://10.132.10.69:9043/ibm/help/index.jsp?topic=/com.ibm.ws.console.environment/ucws_rsharedlib_inst.html

通过这些链接资料的描述(不得不说,这些中文翻译很隐晦),但的确是可以解释目前的情况的。

关于Websphere共享库的理解

首先,Websphere的共享库和tomcat的共享库差别很大,而我却一直以为是差不多的。
tomcat的共享库是一个独立的类加载器,并且在多个Web应用中共享。好处是明显的,共享加载的类,优化内存使用。

其次,Webshpere的共享库非常灵(fu)活(za),有多种配置组合可以影响结果。具体如下:

共享库是可以选择和服务器关联或者和应用关联的

  • 和服务器关联,参考http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/tcws_sharedlib_server.html?lang=zh
  • 和应用关联,参考http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/tcws_sharedlib_app.html?lang=zh

共享库是可以选择是否使用隔离的类装入器(就是独立的类加载器)

设置参考下图所示:

请对此共享库使用隔离的类装入器

和共享库相关的类加载策略如下:

  • 如果选择和服务器关联,那么将忽略”请对此共享库使用隔离的类装入器”的选项,此时共享库路径将会添加到应用程序服务器(application server)类装入器加载路径上。
  • 如果选择和应用关联,并且没有设置”请对此共享库使用隔离的类装入器”,那么共享库路径将会添加到应用的类加载器加载路径上。此时共享库只有优化管理类库的作用,并不能减少重复加载类造成的内存占用。
  • 如果选择和应用关联,并且设置”请对此共享库使用隔离的类装入器”,那么共享库将作为独立的类加载器,并且各个应用之间共享这个共享库。此时共享库和tomcat的共享库类似,可以减少重复加载类造成的内存占用。

对于第三种情况,它的类加载顺序如下:

如果应用的类载入顺序选择“父类装入器装入的类最先”,即Parent First,那么顺序如下:

  • 检查相关联的库类装入器是否可以装入类。(共享库)
  • 检查它的父代类装入器是否可以装入类。(应用服务器及更高)
  • 检查应用程序或 WAR 模块类装入器是否可以装入类。(应用)

如果应用的类载入顺序选择“本地类装入器装入的类最先”,即Parent Last,那么顺序如下:

  • 检查应用程序或 WAR 模块类装入器是否可以装入类。(应用)
  • 检查相关联的库类装入器是否可以装入类。(共享库)
  • 检查它的父代类装入器是否可以装入类。(应用服务器及更高)

现象解释

  • 开发环境中,共享库和应用关联,并且没有设置”请对此共享库使用隔离的类装入器”,所以共享库路径将会添加到应用的类加载器加载路径上,相当于在一个类加载路径上存在同样的类,所以使用到lib中的是可能的。
  • 生产环境中配置尚未查明,如果共享库和应用关联,并且设置”请对此共享库使用隔离的类装入器”,按同样的载入顺序设置,即Parent First,那么是会加载到共享库的。
  • 如果同样是没有设置”请对此共享库使用隔离的类装入器”,那么情况如开发环境情况,使用到共享库中的也是可能的。
  • 对于同一个类加载路径上存在同样的类,具体会加载哪个是不确定的,所以上述情况都是合理的。所以应该把应用中重复的jar包移除。