湖南做网站 磐石网络引领,肥城网站设计公司,上海app开发费用,商务网站建设实训报告1600字文章目录 1.类与类加载器2.类加载器加载规则3.JVM 中内置的三个重要类加载器为什么 获取到 ClassLoader 为null就是 BootstrapClassLoader 加载的呢#xff1f; 4.自定义类加载器什么时候需要自定义类加载器代码示例 5.双亲委派模式类与类加载器双亲委派模型双亲委派模型的执行… 文章目录 1.类与类加载器2.类加载器加载规则3.JVM 中内置的三个重要类加载器为什么 获取到 ClassLoader 为null就是 BootstrapClassLoader 加载的呢 4.自定义类加载器什么时候需要自定义类加载器代码示例 5.双亲委派模式类与类加载器双亲委派模型双亲委派模型的执行流程双亲委派模型的好处打破双亲委派模型方法 6.线程上下文类加载器 1.类与类加载器 类加载器虽然只用于实现类的加载动作但它在Java程序中起到的作用却远超类加载阶段。 对于任意一个类都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性一个类加载器都拥有一个独立的类名称空间。 这句话可以表达得更通俗一些比较两个类是否“相等”只有在这两个类是由同一个类加载器加载的前提下才有意义否则即使这两个类来源于同一个Class文件被同一个Java虚拟机加载只要加载它们的类加载器不同那这两个类就必定不相等。 这里所指的“相等”包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果也包括了使用instanceof关键字做对象所属关系判定等各种情况。 官方 API 文档的介绍 类加载器是一个负责加载类的对象。ClassLoader 是一个抽象类。给定类的二进制名称类加载器应尝试定位或生成构成类定义的数据。典型的策略是将名称转换为文件名然后从文件系统中读取该名称的“类文件”。 每个 Java 类都有一个引用指向加载它的 ClassLoader。不过数组类不是通过 ClassLoader 创建的而是 JVM 在需要的时候自动创建的数组类通过getClassLoader()方法获取 ClassLoader 的时候和该数组的元素类型的 ClassLoader 是一致的。 从上面的介绍可以看出: 类加载器是一个负责加载类的对象用于实现类加载过程中的加载这一步。每个 Java 类都有一个引用指向加载它的 ClassLoader。数组类不是通过 ClassLoader 创建的数组类没有对应的二进制字节流是由 JVM 直接生成的。 简单来说类加载器的主要作用就是动态加载 Java 类的字节码 .class 文件到 JVM 中在内存中生成一个代表该类的 Class 对象。 字节码可以是 Java 源程序.java文件经过 javac 编译得来也可以是通过工具动态生成或者通过网络下载得来。 其实除了加载类之外类加载器还可以加载 Java 应用所需的资源如文本、图像、配置文件、视频等等文件资源。 2.类加载器加载规则 JVM 启动的时候并不会一次性加载所有的类而是根据需要去动态加载。也就是说大部分类在具体用到的时候才会去加载这样对内存更加友好。 对于已经加载的类会被放在 ClassLoader 中。在类加载的时候系统会首先判断当前类是否被加载过。已经被加载的类会直接返回否则才会尝试加载。也就是说对于一个类加载器来说相同二进制名称的类只会被加载一次。 public abstract class ClassLoader {...private final ClassLoader parent;// 由这个类加载器加载的类。private final VectorClass? classes new Vector();// 由VM调用用此类加载器记录每个已加载类。void addClass(Class? c) {classes.addElement(c);}... }3.JVM 中内置的三个重要类加载器 JVM 中内置了三个重要的 ClassLoader BootstrapClassLoader(启动类加载器)最顶层的加载类由 C实现通常表示为 null并且没有父级主要用来加载 JDK 内部的核心类库 %JAVA_HOME%/lib目录下的 rt.jar、resources.jar、charsets.jar等 jar 包和类以及被 -Xbootclasspath参数指定的路径下的所有类。ExtensionClassLoader(扩展类加载器)主要负责加载 %JRE_HOME%/lib/ext 目录下的 jar 包和类以及被 java.ext.dirs 系统变量所指定的路径下的所有类。AppClassLoader(应用程序类加载器)面向我们用户的加载器负责加载当前应用 classpath 下的所有 jar 包和类。 拓展一下 rt.jarrt 代表“RunTime”rt.jar是 Java 基础类库包含 Java doc 里面看到的所有的类的类文件。也就是说我们常用内置库 java.xxx.*都在里面比如java.util.*、java.io.*、java.nio.*、java.lang.*、java.sql.*、java.math.*。 Java 9 引入了模块系统并且略微更改了上述的类加载器。扩展类加载器被改名为平台类加载器platform class loader。Java SE 中除了少数几个关键模块比如说 java.base 是由启动类加载器加载之外其他的模块均由平台类加载器所加载。 除了这三种类加载器之外用户还可以加入自定义的类加载器来进行拓展以满足自己的特殊需求。就比如说我们可以对 Java 类的字节码 .class 文件进行加密加载时再利用自定义的类加载器对其解密。 除了 BootstrapClassLoader 是 JVM 自身的一部分之外其他所有的类加载器都是在 JVM 外部实现的并且全都继承自 ClassLoader抽象类。这样做的好处是用户可以自定义类加载器以便让应用程序自己决定如何去获取所需的类。 每个 ClassLoader 可以通过getParent()获取其父 ClassLoader如果获取到 ClassLoader 为null的话那么该类是通过 BootstrapClassLoader 加载的。 public abstract class ClassLoader {...// 父加载器private final ClassLoader parent;CallerSensitivepublic final ClassLoader getParent() {//...}... }为什么 获取到 ClassLoader 为null就是 BootstrapClassLoader 加载的呢 这是因为BootstrapClassLoader 由 C 实现由于这个 C 实现的类加载器在 Java 中是没有与之对应的类的所以拿到的结果是 null。 4.自定义类加载器 除了 BootstrapClassLoader 其他类加载器均由 Java 实现且全部继承自java.lang.ClassLoader。如果我们要自定义自己的类加载器很明显需要继承 ClassLoader抽象类。 ClassLoader 类有两个关键的方法 protected Class loadClass(String name, boolean resolve)加载指定二进制名称的类实现了双亲委派机制 。name 为类的二进制名称resolve 如果为 true在加载时调用 resolveClass(Class? c) 方法解析该类。protected Class findClass(String name)根据类的二进制名称来查找类默认实现是空方法。 注意如果我们不想打破双亲委派模型就重写 ClassLoader 类中的 findClass() 方法即可无法被父类加载器加载的类最终会通过这个方法被加载。但是如果想打破双亲委派模型则需要重写 loadClass() 方法。 什么时候需要自定义类加载器 想加载非 classpath 随意路径中的类文件。都是通过接口来使用实现、希望解耦时常用在框架设计。这些类希望予以隔离不同应用的同名类都可以加载不会发生冲突常见于 tomcat 容器。 步骤 继承 ClassLoader 父类要遵从双亲委派机制重写 findClass 方法 注意不是重写 loadClass 方法否则不会走双亲委派机制读取类文件的字节码调用父类的 defineClass 方法来加载类使用者调用该类加载器的 loadClass 方法 代码示例 public class F {//通过是否运行静态代码块观察是否被加载并初始化static {System.out.println(bootstrap F init);} }自定义类加载器 class MyClassLoader extends ClassLoader {Override // name 就是类名称protected Class? findClass(String name) throws ClassNotFoundException {//F.class位置String path D:\\java\\jvm\\out\\production\\jvm\\ name .class;try {ByteArrayOutputStream os new ByteArrayOutputStream();Files.copy(Paths.get(path), os);// 得到字节数组byte[] bytes os.toByteArray();// byte[] - *.classreturn defineClass(name, bytes, 0, bytes.length);} catch (IOException e) {e.printStackTrace();throw new ClassNotFoundException(类文件未找到, e);}}Overrideprotected synchronized Class? loadClass(String name, boolean resolve) throws ClassNotFoundException {// 打印加载类的类加载器System.out.println(Loading class name with this);return super.loadClass(name, resolve);} }使用自定义类加载器加载F类 public class Load {public static void main(String[] args) throws Exception {MyClassLoader classLoader new MyClassLoader();Class? c1 classLoader.loadClass(F);Class? c2 classLoader.loadClass(F);System.out.println(c1 c2);MyClassLoader classLoader2 new MyClassLoader();Class? c3 classLoader2.loadClass(F);System.out.println(c1 c3);System.out.println(c1: c1.getClassLoader());System.out.println(c2: c2.getClassLoader());System.out.println(c3: c3.getClassLoader());c1.newInstance();} }输出 Loading class F with cn.itcast.jvm.t3.load.MyClassLoader12bb4df8 Loading class F with cn.itcast.jvm.t3.load.MyClassLoader12bb4df8 true Loading class F with cn.itcast.jvm.t3.load.MyClassLoader4cc77c2e true c1: sun.misc.Launcher$AppClassLoader18b4aac2 c2: sun.misc.Launcher$AppClassLoader18b4aac2 c3: sun.misc.Launcher$AppClassLoader18b4aac2 bootstrap F init5.双亲委派模式 类与类加载器 站在Java虚拟机的角度来看只存在两种不同的类加载器 一种是启动类加载器BootstrapClassLoader这个类加载器使用C语言实现[1]是虚拟机自身的一部分另外一种就是其他所有的类加载器这些类加载器都由Java语言实现独立存在于虚拟机外部并且全都继承自抽象类java.lang.ClassLoader。 站在Java开发人员的角度来看类加载器就应当划分得更细致一些 JDK 9之前的Java应用都是由启动、扩展、应用程序类加载器互相配合来完成加载的如果用户认为有必要还可以加入自定义的类加载器来进行拓展典型的如增加除了磁盘位置之外的Class文件来源或者通过类加载器实现类的隔离、重载等功能。 类加载器有很多种当我们想要加载一个类的时候具体是哪个类加载器加载呢这就需要提到双亲委派模型了。 ClassLoader 类使用委托模型来搜索类和资源。双亲委派模型要求除了顶层的启动类加载器外其余的类加载器都应有自己的父类加载器。ClassLoader 实例会在试图亲自查找类或资源之前将搜索类或资源的任务委托给其父类加载器。 双亲委派模型 下图展示的各种类加载器之间的层次关系被称为类加载器的“双亲委派模型(Parents Delegation Model)”。 双亲委派模型要求除了顶层的启动类加载器外其余的类加载器都应有自己的父类加载器。不过这里类加载器之间的父子关系一般不是以继承Inheritance的关系来实现的而是通常使用组合Composition关系来复用父加载器的代码。 注意⚠️类加载器的双亲委派模型在JDK 1.2时期被引入并被广泛应用于此后几乎所有的Java程序中但它并不是一个具有强制性约束力的模型而是Java设计者们推荐给开发者的一种类加载器实现的最佳实践。 在面向对象编程中有一条非常经典的设计原则组合优于继承多用组合少用继承。 双亲委派模型的执行流程 java.lang.ClassLoader#loadClass(java.lang.String, boolean) protected Class? loadClass(String name, boolean resolve)throws ClassNotFoundException {synchronized (getClassLoadingLock(name)) {// First, check if the class has already been loaded// 1. 检查该类是否已经加载Class? c findLoadedClass(name);if (c null) {//如果 c 为 null则说明该类没有被加载过long t0 System.nanoTime();try {if (parent ! null) {// 2. 有上级的话委派上级 loadClass来加载该类c parent.loadClass(name, false);} else {// 3. 如果没有上级了ExtClassLoader则委派BootstrapClassLoaderc findBootstrapClassOrNull(name);}} catch (ClassNotFoundException e) {// ClassNotFoundException thrown if class not found// from the non-null parent class loader}if (c null) {// If still not found, then invoke findClass in order// to find the class.long t1 System.nanoTime();// 4. 每一层找不到调用 findClass 方法每个类加载器自己扩展来加载c findClass(name);// this is the defining class loader; record the stats// 5. 记录耗时sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);sun.misc.PerfCounter.getFindClasses().increment();}}if (resolve) {resolveClass(c);}return c;} }结合上面的源码简单总结一下双亲委派模型的执行流程 如果一个类加载器收到了类加载的请求它首先不会自己去尝试加载这个类会首先判断当前类是否被加载过。已经被加载的类会直接返回否则才会尝试加载每个父类加载器都会走一遍这个流程。类加载器在进行类加载的时候它首先不会自己去尝试加载这个类而是把这个请求委派给父类加载器去完成调用父加载器 loadClass()方法来加载类。这样的话所有的请求最终都会传送到顶层的启动类加载器 BootstrapClassLoader 中。只有当父加载器反馈自己无法完成这个加载请求它的搜索范围中没有找到所需的类时子加载器才会尝试自己去加载调用自己的 findClass() 方法来加载类。如果子类加载器也无法加载这个类那么它会抛出一个 ClassNotFoundException 异常。 双亲委派模型的好处 双亲委派模型是 Java 类加载机制的重要组成部分它通过委派父加载器优先加载类的方式实现了两个关键的安全目标避免类的重复加载和防止核心 API 被篡改。 JVM 区分不同类的依据是类名加上加载该类的类加载器即使类名相同如果由不同的类加载器加载也会被视为不同的类。 双亲委派模型确保核心类总是由 BootstrapClassLoader 加载保证了核心类的唯一性。 例如当应用程序尝试加载 java.lang.Object 时AppClassLoader 会首先将请求委派给 ExtClassLoaderExtClassLoader 再委派给 BootstrapClassLoader。BootstrapClassLoader 会在 JRE 核心类库中找到并加载 java.lang.Object从而保证应用程序使用的是 JRE 提供的标准版本。 同时即使攻击者绕过了双亲委派模型Java 仍然具备更底层的安全机制来保护核心类库。ClassLoader 的 preDefineClass 方法会在定义类之前进行类名校验。任何以 “java.” 开头的类名都会触发 SecurityException阻止恶意代码定义或加载伪造的核心类。 打破双亲委派模型方法 重写 loadClass() 方法打破双亲委派模型 原因类加载器在进行类加载的时候它首先不会自己去尝试加载这个类而是把这个请求委派给父类加载器去完成调用父加载器 loadClass()方法来加载类。 重写 loadClass()方法之后我们就可以改变传统双亲委派模型的执行流程。例如子类加载器可以在委派给父类加载器之前先自己尝试加载这个类或者在父类加载器返回之后再尝试从其他地方加载这个类。具体的规则由我们自己实现根据项目需求定制化。 我们比较熟悉的 Tomcat 服务器为了能够优先加载 Web 应用目录下的类然后再加载其他目录下的类就自定义了类加载器 WebAppClassLoader 来打破双亲委托机制。这也是 Tomcat 下 Web 应用之间的类实现隔离的具体原理。 Tomcat 的类加载器的层次结构如下 从图中的委派关系中可以看出 CommonClassLoader作为 CatalinaClassLoader 和 SharedClassLoader 的父加载器。CommonClassLoader 能加载的类都可以被 CatalinaClassLoader 和 SharedClassLoader 使用。因此CommonClassLoader 是为了实现公共类库可以被所有 Web 应用和 Tomcat 内部组件使用的类库的共享和隔离。CatalinaClassLoader 和 SharedClassLoader 能加载的类则与对方相互隔离。CatalinaClassLoader 用于加载 Tomcat 自身的类为了隔离 Tomcat 本身的类和 Web 应用的类。SharedClassLoader 作为 WebAppClassLoader 的父加载器专门来加载 Web 应用之间共享的类比如 Spring、Mybatis。每个 Web 应用都会创建一个单独的 WebAppClassLoader并在启动 Web 应用的线程里设置线程上下文类加载器为 WebAppClassLoader。各个 WebAppClassLoader 实例之间相互隔离进而实现 Web 应用之间的类隔。 单纯依靠自定义类加载器没办法满足某些场景的要求例如有些情况下高层的类加载器需要加载低层的加载器才能加载的类。 比如假设我们的项目中有 Spring 的 jar 包由于其是 Web 应用之间共享的因此会由 SharedClassLoader 加载Web 服务器是 Tomcat。 我们项目中有一些用到了 Spring 的业务类比如实现了 Spring 提供的接口、用到了 Spring 提供的注解。所以加载 Spring 的类加载器也就是 SharedClassLoader也会用来加载这些业务类。 但是业务类在 Web 应用目录下不在 SharedClassLoader 的加载路径下所以 SharedClassLoader 无法找到业务类也就无法加载它们。 如何解决这个问题呢 这个时候就需要用到 线程上下文类加载器ThreadContextClassLoader 了。 6.线程上下文类加载器 拿 Spring 这个例子来说当 Spring 需要加载业务类的时候它不是用自己的类加载器而是用当前线程的上下文类加载器。因为每个 Web 应用都会创建一个单独的 WebAppClassLoader并在启动 Web 应用的线程里设置线程上下文类加载器为 WebAppClassLoader。这样就可以让高层的类加载器SharedClassLoader借助子类加载器 WebAppClassLoader来加载业务类破坏了 Java 的类加载委托机制让应用逆向使用类加载器。 线程上下文类加载器的原理是将一个类加载器保存在线程私有数据里跟线程绑定然后在需要的时候取出来使用。这个类加载器通常是由应用程序或者容器如 Tomcat设置的。 Java.lang.Thread 中的getContextClassLoader()和 setContextClassLoader(ClassLoader cl)分别用来获取和设置线程的上下文类加载器。如果没有通过setContextClassLoader(ClassLoader cl)进行设置的话线程将继承其父线程的上下文类加载器。 Spring 获取线程线程上下文类加载器的代码如下 cl Thread.currentThread().getContextClassLoader();我们在使用 JDBC 时都需要加载 Driver 驱动不知道你注意到没有不写Class.forName(com.mysql.jdbc.Driver)也是可以让 com.mysql.jdbc.Driver 正确加载原因 java.sql.DriverManager public class DriverManager {// 注册驱动的集合private final static CopyOnWriteArrayListDriverInfo registeredDrivers new CopyOnWriteArrayList();// 初始化驱动static {loadInitialDrivers();println(JDBC DriverManager initialized);} }先看看 DriverManager 的类加载器 System.out.println(DriverManager.class.getClassLoader());打印 null表示它的类加载器是 Bootstrap ClassLoader会到 JAVA_HOME/jre/lib 下搜索类但 JAVA_HOME/jre/lib 下显然没有 mysql-connector-java-5.1.47.jar 包这样问题来了在DriverManager 的静态代码块中怎么能正确加载 com.mysql.jdbc.Driver 呢 继续看 loadInitialDrivers() 方法 private static void loadInitialDrivers() {String drivers;try {drivers AccessController.doPrivileged(new PrivilegedActionString() {public String run() {return System.getProperty(jdbc.drivers);}});} catch (Exception ex) {drivers null;}// 1.使用 ServiceLoader 机制加载驱动即 SPIAccessController.doPrivileged(new PrivilegedActionVoid() {public Void run() {ServiceLoaderDriver loadedDrivers ServiceLoader.load(Driver.class);IteratorDriver driversIterator loadedDrivers.iterator();try{while(driversIterator.hasNext()) {driversIterator.next();}} catch(Throwable t) {// Do nothing}return null;}});println(DriverManager.initialize: jdbc.drivers drivers);// 2.使用 jdbc.drivers 定义的驱动名加载驱动if (drivers null || drivers.equals()) {return;}String[] driversList drivers.split(:);println(number of Drivers: driversList.length);for (String aDriver : driversList) {try {println(DriverManager.Initialize: loading aDriver);// 这里的 ClassLoader.getSystemClassLoader() 就是应用程序类加载器Class.forName(aDriver, true,ClassLoader.getSystemClassLoader());} catch (Exception ex) {println(DriverManager.Initialize: load failed: ex);}} }先看 2. 发现它最后是使用 Class.forName 完成类的加载和初始化关联的是应用程序类加载器因此可以顺利完成类加载 再看 1. 它就是大名鼎鼎的 Service Provider Interface SPI 约定如下在 jar 包的 META-INF/services 包下以接口全限定名名为文件文件内容是实现类名称 这样就可以使用以下代码 ServiceLoader接口类型 allImpls ServiceLoader.load(接口类型.class); Iterator接口类型 iter allImpls.iterator(); while(iter.hasNext()) {iter.next(); }来得到实现类体现的是【面向接口编程解耦】的思想在下面一些框架中都运用了此思想 JDBCServlet 初始化器Spring 容器Dubbo对 SPI 进行了扩展 接着看 ServiceLoader.load 方法 public static S ServiceLoaderS load(ClassS service) {// 获取线程上下文类加载器(其实是应用程序类加载器)ClassLoader cl Thread.currentThread().getContextClassLoader();return ServiceLoader.load(service, cl); }线程上下文类加载器是当前线程使用的类加载器默认就是应用程序类加载器它内部又是由Class.forName 调用了线程上下文类加载器完成类加载具体代码在 ServiceLoader 的内部类LazyIterator 中 java.util.ServiceLoader.LazyIterator#nextService private S nextService() {if (!hasNextService())throw new NoSuchElementException();String cn nextName;nextName null;Class? c null;try {c Class.forName(cn, false, loader);} catch (ClassNotFoundException x) {fail(service,Provider cn not found);}if (!service.isAssignableFrom(c)) {fail(service,Provider cn not a subtype);}try {S p service.cast(c.newInstance());providers.put(cn, p);return p;} catch (Throwable x) {fail(service,Provider cn could not be instantiated,x);}throw new Error(); // This cannot happen }相关文章 JVM内存结构 JVM内存结构笔记01-运行时数据区域JVM内存结构笔记02-堆JVM内存结构笔记03-方法区JVM内存结构笔记04-字符串常量池JVM内存结构笔记05-直接内存JVM内存结构笔记06-HotSpot虚拟机对象探秘JVM中常量池和运行时常量池、字符串常量池三者之间的关系 JVM垃圾回收 JVM垃圾回收笔记01-垃圾回收算法JVM垃圾回收笔记02-垃圾回收器 JVM类加载与字节码 JVM类文件结构详解JVM类加载过程详解JVM类加载器详解