浅谈运行环境的类加载

   在我们搭建运行环境时,有时候会碰到各种各样的问题,比较常见的是ClassNotFoundException和NoClassDefFoundException,这样的问题还是比较简单的，一般我们只要查看一下缺少的类，将类包放进加载目录就可以的。有的问题就比较奇怪了，譬如说，在启动的时候，一点错误也没有，但是起来之后却提示404，无法访问；再就是，启动的时候每条日志都会重复打印，而且起来之后怎么也登录不进去等等。其实只要了解了java和Web 应用服务器的类加载机制之后，套用神探狄仁杰的一句话说“这些看似不可思议的问题背后，其实都有一个合理的原因”。那么接下来，我来介绍一下我所了解的java及Web 应用服务器的类加载机制。
    Java 中的系统提供的类加载器主要有下面三个：
引导类加载器（bootstrap class loader）：它用来加载 Java 的核心库，是用原生代码来实现的，并不继承自 java.lang.ClassLoader。
扩展类加载器（extensions class loader）：它用来加载 Java 的扩展库。Java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。
系统类加载器（system class loader）：它根据 Java 应用的类路径（CLASSPATH）来加载 Java 类。一般来说，Java 应用的类都是由它来完成加载的。可以通过 ClassLoader.getSystemClassLoader() 来获取它。
除了引导类加载器之外，所有的类加载器都有一个父类加载器。对于系统提供的类加载器来说，系统类加载器的父类加载器是扩展类加载器，而扩展类加载器的父类加载器是引导类加载器；对于开发人员编写的类加载器来说，其父类加载器是加载此类加载器 Java 类的类加载器。因为类加载器 Java 类如同其它的 Java 类一样，也是要由类加载器来加载的。一般来说，开发人员编写的类加载器的父类加载器是系统类加载器。类加载器通过这种方式组织起来，形成树状结构。树的根节点就是引导类加载器。图 1 中给出了一个典型的类加载器树状组织结构示意图，其中的箭头指向的是父类加载器。

    类加载器在尝试自己去查找某个类的字节代码并定义它时，会先代理给其父类加载器，由父类加载器先去尝试加载这个类，依次类推。那么Java 虚拟机是如何判定两个 Java 类是相同的。Java 虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。只有两者都相同的情况，才认为两个类是相同的。即便是同样的字节代码，被不同的类加载器加载之后所得到的类，也是不同的。
    对于运行在 Java EE 容器中的 Web 应用来说，类加载器的实现方式与一般的 Java 应用有所不同。不同的 Web 容器的实现方式也会有所不同。以 Apache Tomcat 来说，每个 Web 应用都有一个对应的类加载器实例。该类加载器也使用代理模式，所不同的是它是首先尝试去加载某个类，如果找不到再代理给父类加载器。这与一般类加载器的顺序是相反的。这是 Java Servlet 规范中的推荐做法，其目的是使得 Web 应用自己的类的优先级高于 Web 容器提供的类。这种代理模式的一个例外是：Java 核心库的类是不在查找范围之内的。这也是为了保证 Java 核心库的类型安全。
    绝大多数情况下，Web 应用的开发人员不需要考虑与类加载器相关的细节。下面给出几条简单的原则：
每个 Web 应用自己的 Java 类文件和使用的库的 jar 包，分别放在 WEB-INF/classes 和 WEB-INF/lib 目录下面。
多个应用共享的 Java 类文件和 jar 包，分别放在 Web 容器指定的由所有 Web 应用共享的目录下面。
    看到这里，有的同事可能就会问了，等等等等，类存放还要分共享和私有，太麻烦了，能不能放到一个路径下，譬如说全部放到WEB-INF/lib下或者全部放到共享目录下。听起来好像也没有什么问题，反正都是能够被系统加载的，只要放全了，放哪不行啊。那么真的可行吗？
    其实对于单个web应用，确实放哪都可以，因为对于单个web应用是没有共享和私有的区分的，只要把该放的类放全了，那么类就可以被正确的加载和使用。但是当一个web服务下存在多个应用时，问题就来啦。首先假如把类全部放在共享的classPath下，那么就会出现我们开头所提到的“在启动的时候，一点错误也没有，但是起来之后却提示404”的问题，为什么？因为我们的web服务在加载的时候只加载了一份webwork相关的类，这导致了这些类在初始化的时候，只初始化了一个web应用的action配置，当我们要访问web服务中的另外一个应用时，系统只好告诉你“Could not execute action”了，因为他根本不知道这个世界上还有另外一个应用存在。那么反过来，我们把全部的类都放到WEB-INF/lib下总万事大吉了吧，我用我的全部类，你用你的全部类，无非是容器累一点，多加载一份类而已。OK，真的能够如愿以偿吗。不是的，举个简单的例子，在我们zjport一期的单点登录中使用了globalSession,这是保存在web容器的单个共享实例中的，假如我们人为的将这些共享类放到私有的加载路径下，这就会导致“启动的时候每条日志都会重复打印，而且起来之后怎么也登录不进去”，因为globalSession不共享了，所以当我们登录到zjport之后，由于我们的菜单配置有个默认显示页面，这个页面可能不是zjport本身这个应用的，这时候单点登录就会校验不通过，马上就跳到起始的登录页面。
    本文的理论部分参考：http://www.ibm.com/developerworks/cn/java/j-lo-classloader/?ca=drs-tp4608#download