- 通过全类名获取定义此类的二进制字节流
- 将字节流所代表的静态存储结构转换为方法区的运行时数据结构
- 在内存中生成一个代表该类的 Class 对象，作为方法区这些数据的访问入口
- BootstrapClassLoader(启动类加载器) ：最顶层的加载类，由 C++实现，负责加载 %JAVA_HOME%/lib 目录下的 jar 包和类或者被 -Xbootclasspath参数指定的路径中的所有类。
- ExtensionClassLoader(扩展类加载器) ：主要负责加载 %JRE_HOME%/lib/ext 目录下的 jar 包和类，或被 java.ext.dirs 系统变量所指定的路径下的 jar 包。
- AppClassLoader(应用程序类加载器) ：面向我们用户的加载器，负责加载当前应用 classpath 下的所有 jar 包和类
除了BootstrapClassLoader其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader
双亲委派模型
在类加载的时候，系统会首先判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。加载的时候，首先会把该请求委派给父类加载器的 loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader 中。当父类加载器无法处理时，才由自己来处理。
双亲（parent）这一翻译容易误解强调“双”，其实原意是表达类似父辈的概念。而且，类加载器之间的父子关系也并非通过继承实现，而是使用优先级来控制的。
好处：
1.避免类的重复加载（Java通过 类名+类加载器 来区分类，即同一个class文件被不同的classLoader加载，产生的是两个不同的类）
2.防止Java核心API被覆盖（即使手动编写一个java.lang.Object的类，只会由BootstrapClassLoader加载jre.jar包中的java.lang.Object）
Tomcat破坏了双亲委派模型，自定义加载规则，主要是为了①不同webapp需要共享lib ②使用单独的classloader加载自身类库，防止被覆盖 ③热部署
