- 通过全类名获取定义此类的二进制字节流
- 将字节流所代表的静态存储结构转换为方法区的运行时数据结构
- 在内存中生成一个代表该类的 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加载自身类库,防止被覆盖 ③热部署
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)