tomcat哪里打破了 Java 的类加载机制？

通常 java类加载器有以下几种

Bootstrap ClassLoader
这是加载器中的根，任何类的加载行为，都要通过他。它的作用是加载核心类库，也就是 rt.jar、resources.jar、charsets.jar 等。当然这些 jar 包的路径是可以指定的，-Xbootclasspath 参数可以完成指定操作。随着 JVM 启动。

Extention ClassLoader
扩展类加载器，主要用于加载 lib/ext 目录下的 jar 包和 .class 文件。同样的，通过系统变量 java.ext.dirs 可以指定这个目录。

这个加载器是个 Java 类，继承自 URLClassLoader。

App ClassLoader
这是我们写的 Java 类的默认加载器，有时候也叫作 System ClassLoader。一般用来加载 classpath 下的其他所有 jar 包和 .class 文件，我们写的代码，会首先尝试使用这个类加载器进行加载。

Custom ClassLoader
自定义加载器，支持一些个性化的扩展功能。

双亲委派模式：Bootstrap->Extention->App->Custom ,按照这个顺序，除了顶层的启动类加载器以外，其余的类加载器，在加载之前，都会委派给它的父加载器进行加载。这样一层层向上传递，直到祖先们都无法胜任，它才会真正的加载。，其实只有单亲，双亲委派是翻译问题。

Tomcat其实违反了双亲委派机制原则的，除了Bootstrap ClassLoader、Extention ClassLoader、App ClassLoader之外，tomcat还有CommonClassLoader，用于加载通用类。再下一层还有Catalina ClassLoader（启动类）和SharedClassLoader。

SharedClassLoader之下还有WebAppClassLoader和JSPClassLoader，这两个加载器加载web-inf/classes和web-inf/lib下面的文件，并不会交给父加载器，但是可以使用SharedClassLoader加载的类。这就打破了双亲委派模式。

 

其他打破双亲委派模式的情况还有SPI，OSGI，还没有研究，就不展开了