首页 > 代码库 > tomcat如何避免遭遇ClassNotFoundException
tomcat如何避免遭遇ClassNotFoundException
在Tomcat中为什么创建类加载器后马上就Thread.currentThread().setContextClassLoader(catalinaLoader)？这里主要是为了避免后面加载类时加载失败。下面将举一个典型的例子说明如何利用URLClassLoader加载指定的jar包，并且解析由此引出的加载失败问题。
首先，定义一个提供服务的接口，并且打包成TestInterface.jar。
public interface TestInterface{
public String display();
}
其次，创建一个名为TestClassLoader的类，它实现TestInterface.jar包里面的TestInterface接口，包路径为com.test，该类包含一个display方法，将这个类编译并打包成test.jar包，放在D盘目录下。
public class TestClassLoader implements TestInterface{
public String display(){
return "I can load this class and execute the method.";
}
}
最后，就是利用URLClassLoader加载并运行TestClassLoader类的display方法。创建一个测试类，如下
public class Test{
public static void main(String[] args){
try{
URL url = new URL(“file:D:/test.jar”);
URLClassLoader myClassLoader = new URLClassLoader(new URL[]{url});
Class myClass = myClassLoader.loadClass(“com.test.TestClassLoader”);
TestInterface testClassLoader = (TestInterface)myClass.newInstance();
System.out.println(testClassLoader.display());
}catch(Exception e){
e.printStackTrace();
}
}
}
测试类的main方法中首先用URLClassLoader指定加载test.jar，然后再将com.test.TestClassLoader类加载到内存，最后用newInstance方法生成一个TestClassLoader实例，即可调用它的display方法。运行这个测试类，能够达到预期效果输出I can load this class and execute the method.语句。看起来一切来得都是那么的顺其自然，当你兴致冲冲地把自己的写好的TestInterface.jar包移植到web应用中时，现实无情地给你泼了一盆冷水，抛出java.lang.ClassNotFoundException:com. test.TestInterface异常，报错的位置正是代码中加粗的语句，可能你在想明明我添加了这个类啊，怎么会抛出找不到这个类呢？要明白为什么会报这样的错，需要搞清楚以下几点：
① 在Java中，我们用完全匹配类名来标识一个类，即用包名和类名。而在JVM中，一个类由完全匹配类名和一个类加载器的实例ID作为唯一标识。即是说同一个虚拟机可以有两个包名、类名都相同的类，只要他们由两个不同类加载器加载，而在各自类加载器中的类实例也是不同的，并且不能互相转换。
② 在类加载器加载某个类时，一般会在类中引用、继承、扩展其他的类，那么类加载器查找这些引用类也是一层一层往父类加载器上查找的，最后查看自己，如果都找不到将会报出找不到此类的错误。也就是说只会向上查找引用类，而不会往下从子类加载器上查找。
③ 每个运行中的线程都有一个成员contextClassLoader，用来在运行时动态地载入其它类。在没有显式声明由哪个类加载器加载的类（例如在程序中直接new一个类）时，将默认由当前线程类加载器加载，即线程运行到需要加载新类时，用自己的类加载器对其进行加载。系统默认的contextClassLoader是systemClassLoader，所以一般而言java程序在执行时可以使用JVM自带的类、$JAVA_HOME/jre/lib/ext/中的类和$CLASSPATH/中的类。当前线程类加载器的工作原理参考图3-1-6-1。随着线程的执行，class1直接由ContextClassLoader加载；接着线程创建了一个用户自定义类加载器MyClassLoader加载class2，所以class2由MyClassLoader加载；最后线程通过Thread.currentThread().setContextClassLoader(MyClassLoader)将当前线程类加载器设置为MyClassLoader，class3也就由MyClassLoader加载。
图3-1-6-1 当前线程类加载器
了解了以上三点，再对前面加载时抛出找不到类的错误进行分析：
(1) 当测试类运行在命令行时，之所以能正常运行是因为，运行时当前线程类加载器是SystemClassLoader, TestInterface接口类自然由它加载，URLClassLoader的默认父类加载器也是SystemClassLoader，由双亲委派机制得知，最后TestClassLoader由SystemClassLoader加载，那么接口跟类都由同一个类加载器加载，自然也就能找到类跟接口并且进行转化。
(2) 当测试类移到web项目中时，假如将代码移到servlet里面，将直接报错无法运行。运行时当前线程类加载器是web应用类加载器WebAppClassLoader,而WebAppClassLoader跟一般的类加载器不同，它不会遵守双亲委派模型，它会先试图自己载入类，当自己无法载入时才交给父类加载器，所以TestInterface接口类由WebAppClassLoader加载。同样，URLClassLoader的父类加载器为SystemClassLoader，它负责加载TestClassLoader类。好了，问题来了，两个不同的类加载器分别加载两个类，而且WebAppClassLoader又是SystemClassLoader的子孙类加载器，由于TestClassLoader类扩展了TestInterface接口，所以当URLClassLoader加载TestClassLoader时找不到WebAppClassLoader中的TestInterface接口类，即抛出java.lang.ClassNotFoundException:com.test.TestInterface异常。
针对以上错误，有两种解决方法：
① 竟然是因为两个类被两个类加载器加载而导致找不到类，那么最简单的解决方法就是把这两个类统一由一个类加载器来加载，即是加载testclassloader.jar时用当前线程类加载器加载，只需稍微改下代码，
URLClassLoader myClassLoader = new URLClassLoader(
new URL[] { url }, Thread.currentThread().getContextClassLoader());
重点在加粗部分，即在创建URLClassLoader对象时将当前类加载器作为父类加载器传入，web应用当前线程类加载器是WebAppClassLoader，那么当加载testclassloader.jar时将优先交给WebAppClassLoader加载，这样就保证了两个类都在同一个类加载器中，不会再报找不到类异常。
② URLClassLoader如果不设置父类加载器，它的默认父类加载器为SystemClassLoader，那么testclassloader.jar将由SystemClassLoader加载，为了能在SystemClassLoader中找到TestInterface接口类，必须让TestInterface接口类让SystemClassLoader父类加载器以上的类加载器加载，从图3-1-6-1中可知只有两个类加载器符合条件——BootstrapClassLoader跟ExtensionClassLoader。由于BootstrapClassLoader作为祖先类，负责加载java核心类，一般不让它加载用户类，所以把目光转向ExtensionClassLoader，它负责加载java扩展类，$JAVA_HOME/jre/lib/ext目录，那么我们把testclassloader.jar拷贝到此目录下，保证了由URLClassLoader加载的类的引用类能从ExtensionClassLoader中找到，问题同样得到解决。
讨论了这么多，回归到tomcat中Thread.currentThread().setContextClassLoader(catalinaLoader)，上面讨论的典型类加载器错误在Tomcat中同样存在，因此tomcat正是通过设置线程上下文类加载器来解决的。在tomcat中类加载器存在以下三个状况：1、tomcat7默认是由commonLoader类加载器加载。2、commonLoader的父类加载器是systemLoader。3、当前线程类加载器是systemLoader。如图3-1-6-2中，先看默认情况，ContextClassLoader被赋为SystemLoader，SystemLoader看不见CommonLoader加载的类，即如果过程中引用就会报找不到类的错误，所以启动tomcat过程肯定报错。接着看看第二种改造的情况，把ContextClassLoader赋为CommonLoader，此时，tomcat启动过程中如果用到$CATALINA_BASE/lib或$CATALINA_HOME/lib中的类就不会报错了，它能看到SystemLoader及其父类加载器所有加载的类。简单地说，解决方法就是把CommonLoader设置为线程上下文类加载器。
图3-1-6-2 tomcat中类加载器
为避免类加载错误，应该尽早设置线程上下文类加载器，所以在tomcat中启动类一初始化就马上设置，即Bootstrap类的init方法中通过Thread.currentThread().setContextClassLoader(catalinaLoader)设置，其中catalinaLoader跟CommonLoader是同一个对象。此后此线程运行时默认由CommonLoader类加载器载入类。
首先，定义一个提供服务的接口，并且打包成TestInterface.jar。
public interface TestInterface{
public String display();
}
其次，创建一个名为TestClassLoader的类，它实现TestInterface.jar包里面的TestInterface接口，包路径为com.test，该类包含一个display方法，将这个类编译并打包成test.jar包，放在D盘目录下。
public class TestClassLoader implements TestInterface{
public String display(){
return "I can load this class and execute the method.";
}
}
最后，就是利用URLClassLoader加载并运行TestClassLoader类的display方法。创建一个测试类，如下
public class Test{
public static void main(String[] args){
try{
URL url = new URL(“file:D:/test.jar”);
URLClassLoader myClassLoader = new URLClassLoader(new URL[]{url});
Class myClass = myClassLoader.loadClass(“com.test.TestClassLoader”);
TestInterface testClassLoader = (TestInterface)myClass.newInstance();
System.out.println(testClassLoader.display());
}catch(Exception e){
e.printStackTrace();
}
}
}
测试类的main方法中首先用URLClassLoader指定加载test.jar，然后再将com.test.TestClassLoader类加载到内存，最后用newInstance方法生成一个TestClassLoader实例，即可调用它的display方法。运行这个测试类，能够达到预期效果输出I can load this class and execute the method.语句。看起来一切来得都是那么的顺其自然，当你兴致冲冲地把自己的写好的TestInterface.jar包移植到web应用中时，现实无情地给你泼了一盆冷水，抛出java.lang.ClassNotFoundException:com. test.TestInterface异常，报错的位置正是代码中加粗的语句，可能你在想明明我添加了这个类啊，怎么会抛出找不到这个类呢？要明白为什么会报这样的错，需要搞清楚以下几点：
① 在Java中，我们用完全匹配类名来标识一个类，即用包名和类名。而在JVM中，一个类由完全匹配类名和一个类加载器的实例ID作为唯一标识。即是说同一个虚拟机可以有两个包名、类名都相同的类，只要他们由两个不同类加载器加载，而在各自类加载器中的类实例也是不同的，并且不能互相转换。
② 在类加载器加载某个类时，一般会在类中引用、继承、扩展其他的类，那么类加载器查找这些引用类也是一层一层往父类加载器上查找的，最后查看自己，如果都找不到将会报出找不到此类的错误。也就是说只会向上查找引用类，而不会往下从子类加载器上查找。
③ 每个运行中的线程都有一个成员contextClassLoader，用来在运行时动态地载入其它类。在没有显式声明由哪个类加载器加载的类（例如在程序中直接new一个类）时，将默认由当前线程类加载器加载，即线程运行到需要加载新类时，用自己的类加载器对其进行加载。系统默认的contextClassLoader是systemClassLoader，所以一般而言java程序在执行时可以使用JVM自带的类、$JAVA_HOME/jre/lib/ext/中的类和$CLASSPATH/中的类。当前线程类加载器的工作原理参考图3-1-6-1。随着线程的执行，class1直接由ContextClassLoader加载；接着线程创建了一个用户自定义类加载器MyClassLoader加载class2，所以class2由MyClassLoader加载；最后线程通过Thread.currentThread().setContextClassLoader(MyClassLoader)将当前线程类加载器设置为MyClassLoader，class3也就由MyClassLoader加载。
图3-1-6-1 当前线程类加载器
了解了以上三点，再对前面加载时抛出找不到类的错误进行分析：
(1) 当测试类运行在命令行时，之所以能正常运行是因为，运行时当前线程类加载器是SystemClassLoader, TestInterface接口类自然由它加载，URLClassLoader的默认父类加载器也是SystemClassLoader，由双亲委派机制得知，最后TestClassLoader由SystemClassLoader加载，那么接口跟类都由同一个类加载器加载，自然也就能找到类跟接口并且进行转化。
(2) 当测试类移到web项目中时，假如将代码移到servlet里面，将直接报错无法运行。运行时当前线程类加载器是web应用类加载器WebAppClassLoader,而WebAppClassLoader跟一般的类加载器不同，它不会遵守双亲委派模型，它会先试图自己载入类，当自己无法载入时才交给父类加载器，所以TestInterface接口类由WebAppClassLoader加载。同样，URLClassLoader的父类加载器为SystemClassLoader，它负责加载TestClassLoader类。好了，问题来了，两个不同的类加载器分别加载两个类，而且WebAppClassLoader又是SystemClassLoader的子孙类加载器，由于TestClassLoader类扩展了TestInterface接口，所以当URLClassLoader加载TestClassLoader时找不到WebAppClassLoader中的TestInterface接口类，即抛出java.lang.ClassNotFoundException:com.test.TestInterface异常。
针对以上错误，有两种解决方法：
① 竟然是因为两个类被两个类加载器加载而导致找不到类，那么最简单的解决方法就是把这两个类统一由一个类加载器来加载，即是加载testclassloader.jar时用当前线程类加载器加载，只需稍微改下代码，
URLClassLoader myClassLoader = new URLClassLoader(
new URL[] { url }, Thread.currentThread().getContextClassLoader());
重点在加粗部分，即在创建URLClassLoader对象时将当前类加载器作为父类加载器传入，web应用当前线程类加载器是WebAppClassLoader，那么当加载testclassloader.jar时将优先交给WebAppClassLoader加载，这样就保证了两个类都在同一个类加载器中，不会再报找不到类异常。
② URLClassLoader如果不设置父类加载器，它的默认父类加载器为SystemClassLoader，那么testclassloader.jar将由SystemClassLoader加载，为了能在SystemClassLoader中找到TestInterface接口类，必须让TestInterface接口类让SystemClassLoader父类加载器以上的类加载器加载，从图3-1-6-1中可知只有两个类加载器符合条件——BootstrapClassLoader跟ExtensionClassLoader。由于BootstrapClassLoader作为祖先类，负责加载java核心类，一般不让它加载用户类，所以把目光转向ExtensionClassLoader，它负责加载java扩展类，$JAVA_HOME/jre/lib/ext目录，那么我们把testclassloader.jar拷贝到此目录下，保证了由URLClassLoader加载的类的引用类能从ExtensionClassLoader中找到，问题同样得到解决。
讨论了这么多，回归到tomcat中Thread.currentThread().setContextClassLoader(catalinaLoader)，上面讨论的典型类加载器错误在Tomcat中同样存在，因此tomcat正是通过设置线程上下文类加载器来解决的。在tomcat中类加载器存在以下三个状况：1、tomcat7默认是由commonLoader类加载器加载。2、commonLoader的父类加载器是systemLoader。3、当前线程类加载器是systemLoader。如图3-1-6-2中，先看默认情况，ContextClassLoader被赋为SystemLoader，SystemLoader看不见CommonLoader加载的类，即如果过程中引用就会报找不到类的错误，所以启动tomcat过程肯定报错。接着看看第二种改造的情况，把ContextClassLoader赋为CommonLoader，此时，tomcat启动过程中如果用到$CATALINA_BASE/lib或$CATALINA_HOME/lib中的类就不会报错了，它能看到SystemLoader及其父类加载器所有加载的类。简单地说，解决方法就是把CommonLoader设置为线程上下文类加载器。
图3-1-6-2 tomcat中类加载器
为避免类加载错误，应该尽早设置线程上下文类加载器，所以在tomcat中启动类一初始化就马上设置，即Bootstrap类的init方法中通过Thread.currentThread().setContextClassLoader(catalinaLoader)设置，其中catalinaLoader跟CommonLoader是同一个对象。此后此线程运行时默认由CommonLoader类加载器载入类。
tomcat如何避免遭遇ClassNotFoundException
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。