jvm中的类加载器

文章目录
类加载器
类加载器分类
分类图
虚拟机自带的加载器
1.启动类加载器（Bootstrap CLassLoader）
2.扩展类加载器(Extension ClassLoader)
3.应用程序类加载器（系统类加载器，AppclassLoader)/system ClassLoader
代码实现
查看启动类加载器的路径
查看扩展类加载器的路径
用户自定义的类加载器
使用自定义类加载器场景
如何自定义类加载器
类加载器
与servlet类似，都是通过多层继承了某一个初始类来实现功能，而且最下面一层都是用户自定义的类

类加载器分类
jvm中类加载器只有两种类型，分别为引导类加载器（Bootstrap CLassLoader）和自定义类加载器（User-Defined CLassLoader)

除了CLassLoader抽象类外，所有从它派生出来的类加载器都划分为自定义类加载器。

分类图
这里四者之间的关系是包含关系，并不是上下层关系和继承关系，可以看做引导类目录下包含着扩展类加载器目录

我们用户手动获取类加载器时，最高只能获取到extension级别的类加载器，获取不到引导类加载器；因为引导类加载器是用c语言编写的

对于用户自定义类来说，默认使用系统类加载器加载

对于Java的核心类库都是使用引导类加载器进行加载的，所以我们找不到它的类加载器

虚拟机自带的加载器 1.启动类加载器（Bootstrap CLassLoader）
这个类加载使用c/c++语言实现的，嵌套在JVM内部。
它用来加载Java的核心库（JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容），用于提供JVM自身需要的类
并不继承自java.lang.classLoader，没有父加载器。加载扩展类和应用程序类加载器，并指定为他们的父类加载器。
出于安全考虑，Bootstrap启动类加载器只加载包名为java、 javax、sun等开头的类
2.扩展类加载器(Extension ClassLoader)
Java语言编写，由sun.misc.Launcher$ExtClassLoader实现。派生于classLoader类父类加载器为启动类加载器从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录（扩展目录）下加载类库。如果用户创建的JAR放在此目录下，也会自动由扩展类加载器加教。3.应用程序类加载器（系统类加载器，AppclassLoader)/systemClassLoaderjava语言编写，由sun.misc.Launcher$AppclassLoader实现派生于classLoader类
父类加载器为扩展类加载器
它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载
通过classLoader#getSystemClassLoader ()方法可以获取到该类加载器
代码实现 查看启动类加载器的路径
虽然查看启动类加载器是null，但是可以得出其加载的路径

在上述路径下解压一个class文件并查看其加载器，可以得出是null也就是类加载器

查看扩展类加载器的路径
用户自定义的类加载器
在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。

使用自定义类加载器场景
隔离加载类

修改类加载的方式

扩展加载源

防止源码泄漏

如何自定义类加载器
开发人员可以通过继承抽象类java.lang.classLoader类的方式，实现自己的类加载器，以满足一些特殊的需求
在JDK1.2之前，在自定义类加载器时，总会去继承classLoader类并重写loadclass ()方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖loadclass ()方法，而是建议把自定义的类加载逻辑写在findclass ()方法中
在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己去编写findclass ()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

文章转自：jvm中的类加载器_Java-答学网

作者：答学网，转载请注明原文链接：http://www.dxzl8.com/