websphere调整类加载顺序的真正效果

问题很小，但是也很容易忽略。正如之前反反复复在websphere里设置应用的类加载顺序的时候，从来没去想这个调整真正改变了什么。

 

1. java的类加载器：

JAVA类加载器分为3层——引导加载器、扩展加载器、应用程序加载器，类加载遵循"父委托模式".

引导加载器(Bootstrap):  加载/jre/lib 下的vm.jar，core.jar等核心

扩展加载器(Extensions):   加载<JAVA_HOME>/jre/lib/ext  或者通过java.ext.dirs 这个系统属性指定的路径下的代码

应用程序加载器(Application):  加载java.class.path下的代码(就是我们程序及程序依赖的第三方类) 

 

2. websphere类加载模型

 JVM ClassLoader层（包含上述的JAVA 3个层次的类加载器）——>WebSphere Extensions Classloader——>WebSphere "server" Class loader——>Application Classloader(包含有Application Module Classloader和Web Module ClassLoader.这2个类加载器上可以设置类加载顺序)

 

3.默认类加载顺序(父类优先)

Websphere采用的是父类优先的类加载顺序。通过websphere控制台——故障诊断——类装入器查看器 我们可以看到一个应用在websphere上部署完成启动后真正形成的类加载层次：

 如图，类加载层次是：

JDK扩展装入器(也就是java类加载器中的扩展加载器(Extensions))——应用程序装入器应用程序加载器(Application)——OSGI(was6.1新特性)装入、引导程序、类保护器——组合类装入器——组合类装入器

 

4.改变类加载顺序（应用程序优先）

这里是关键。我一直认为改变WAS中的类加载顺序，调整的是WAS扩展出来的那些类加载层次：也就是上面的“OSGI(was6.1新特性)装入、引导程序、类保护器——组合类装入器——组合类装入器”顺序的改变。

实际情况是：

 可以看到，事实上的情况是，改变了类加载顺序之后，最低级的2个类加载器竟然排到了扩展加载器(Extensions)之上，仅在引导加载器(Bootstrap)之后，也就是说：

 

“应用程序优先”的类加载顺序的结果是：

引导加载器(Bootstrap)——原来最低级的web和module加载器——扩展加载器(Extensions)——应用程序加载器(Application)——was扩展classloader、WAS应用程序类加载器

 

5.额外的：

websphere能把类加载器提高到这么高的层次，不知道是否是因为websphere6.1使用的JDK是IBM自己实现的而不是使用sun的JDK呢？