websphere调整类加载顺序的真正效果
问题很小，但是也很容易忽略。正如之前反反复复在websphere里设置应用的类加载顺序的时候，从来没去想这个调整真正改变了什么。
?
1. java的类加载器：
JAVA类加载器分为3层——引导加载器、扩展加载器、应用程序加载器，类加载遵循"父委托模式".
引导加载器(Bootstrap): ?加载<JAVA_HOME>/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呢？
