这篇文章说到tomcat类加载机制，就不得不说一下翻译和学习tomcat的初衷。
之前实习的时候研究过javaMelody的源码，但是它是一个Maven项目，和我们自己的web项目集成后不能直接断点调试。后来有同事指导，说直接把java类复制到src就可以了。我很困惑...为什么先加载src下的java文件（编译好的类）而不是jar包中的类？
现在我们了解了tomcat的类加载机制，原来一切就是这么简单。
类加载
在JVM中，所有文件并不是一次性加载的，而是根据需要逐步加载的。
例如，当JVM启动时，会通过不同的类加载器来加载不同的类。当用户自己的代码中需要一些额外的类时，通过加载机制将其加载到JVM中，并存储一段时间以供频繁使用。
所以使用哪个类加载器，在哪里加载类都是JVM中重要的知识。
JVM类加载
JVM类加载采用父类委托机制，如下图：
JVM 中包含的集中式类加载器：
1 BootStrapClassLoader 引导类加载器
2 ExtClassLoader 扩展类加载器
3 AppClassLoader 应用程序类加载器
4 CustomClassLoader 用户定义的类加载器
他们的区别上面也有解释。需要注意的是，不同的类加载器加载不同的类，因此如果一个类被用户加载器1加载，其他用户将无法使用它。
当用户需要在 JVM 运行时加载某些类时，将遵循以下步骤（父类委托机制）：
1 用户自己的类加载器将加载请求传递给父加载器，父加载器将其传递给其父加载器，一直到加载器树的顶部。 2 顶层类加载器首先加载其特定位置。如果无法加载，则转移到子类中。 3 如果底层类加载完成后才加载底层类，则会抛出异常ClassNotFoundException。 因此，按照这个过程，可以想象，如果CLASSPATH指定的目录和自己的工作目录中存放的是同一个类，那么会先加载CLASSPATH目录下的文件。 tomcat中类的加载略有不同，如下图： tomcat启动时，会创建几个类加载器： 1 Bootstrap引导类加载器 加载JVM启动所需的类，以及标准扩展类（位于jre/lib/ext下） 2 系统系统类加载器 加载tomcat启动的类，如bootstrap.jar，通常在catalina.bat或www.sxzhongrui.com中指定。位于 CATALINA_HOME/bin 下。 3 通用通用类加载器 加载tomcat和应用程序常用的一些类，位于CATALINA_HOME/lib下，如servlet-api.jar 4 webapp 应用程序类加载器 每个应用程序部署后，都会创建一个唯一的类加载器。类加载器将加载位于 WEB-INF/lib 下的 jar 文件中的类 以及位于 WEB-INF/classes 下的类文件 。 当应用程序需要某个类时，该类会按照以下顺序加载： 1 使用 bootstrap 加载 2 使用系统类加载器加载 3 使用应用程序类加载器加载 WEB-INF/classes 中的 4 使用应用程序类加载器加载 WEB-INF/lib 中的 5 使用通用类加载器加载CATALINA_HOME/lib中的 通过上面对tomcat类加载机制的了解，就不难理解了为什么Eclipse中放在src文件夹下的java文件会优先考虑jar包中的类呢？ 这是因为tomcat启动时，Eclipse中src文件夹中的文件java和webContent中的JSP会被编译成class文件并放置在WEB-INF/class中。 中等。 而Eclipse外部引用的jar包相当于放在WEB-INF/lib中。 所以肯定是先加载由java文件或JSP文件编译的类。 这样我们就可以简单地将java文件放在src文件夹中。通过修改和调试java文件，我们可以轻松获知有源代码java文件但未打包成xxx-source的jar包。 此外，开发者也可能因为不小心犯以下错误。 在CATALINA_HOME/lib 和WEB-INF/lib 中，CATALINA_HOME/lib中放置了不同版本的jar包。 这在某些情况下会导致举报。类无法加载错误。 另外，如果多个应用程序使用同一个jar包文件，并且放置了多个副本，则可能会导致多个应用程序之间出现类失败错误。 【1】Tomcat类加载器：http://www.sxzhongrui.com/tomcat-6.0-doc/class-loader-howto.html 【2】Tomcat类加载机制：http://www.sxzhongrui.com/dc_726/article/details/11873343Tomcat类加载
问题延伸
参考
