南阳网站建设电话,wordpress4.9.5中文版,和政网站建设,太原竞价托管公司推荐目录
什么是类加载器
类加载器的分类
Bootstrap启动类加载器
通过启动类加载器加载用户jar包
Extension扩展类加载器和Application应用程序类加载器
通过扩展类加载器加载用户jar包
双亲委派机制
打破双亲委派机制
自定义类加载器
线程上下文类加载器
Osgi框架的类加…
目录
什么是类加载器
类加载器的分类
Bootstrap启动类加载器
通过启动类加载器加载用户jar包
Extension扩展类加载器和Application应用程序类加载器
通过扩展类加载器加载用户jar包
双亲委派机制
打破双亲委派机制
自定义类加载器
线程上下文类加载器
Osgi框架的类加载器
总结
JDK9之后的类加载器 什么是类加载器
类加载器ClassLoader是Java虚拟机提供给应用程序去实现获取类和接口字节码数据的技术类加载器只参与加载过程中的字节码获取并加载到内存这一部分。 类加载器会通过二进制流的方式获取到字节码文件的内容接下来将获取到的数据交给Java虚拟机虚拟机会在方法区和堆上生成对应的对象保存字节码信息。
类加载器的分类
类加载器分为两类一类是Java代码中实现的一类是Java虚拟机底层源码实现的。
1. JDK中默认提供或者自定义JDK中默认提供了多种处理不同渠道的类加载器程序员也可以自己根据需求定制使用Java语言。所有Java中实现的类加载器都需要继承ClassLoader这个抽象类。2. 虚拟机底层实现源代码位于Java虚拟机的源码中实现语言与虚拟机底层语言一致比如Hotspot使用C。主要目的是保证Java程序运行中基础类被正确地加载比如java.lang.StringJava虚拟机需要确保其可靠性。
类加载器的设计JDK8和8之后的版本差别较大首先来看JDK8及之前的版本这些版本中默认的类加载器有如下几种 Bootstrap启动类加载器
1. 启动类加载器Bootstrap ClassLoader是由Hotspot虚拟机提供的、使用C编写的类加载器。 2. 默认加载Java安装目录/jre/lib下的类文件比如rt.jartools.jarresources.jar等。
/*** 启动程序类加载器案例*/
public class BootstrapClassLoaderDemo {public static void main(String[] args) throws IOException {ClassLoader classLoader String.class.getClassLoader();System.out.println(classLoader);System.in.read();}
}
这段代码通过String类获取到它的类加载器(Bootstrap)并且打印结果是null。这是因为启动类加载器在JDK8中是由C语言来编写的在Java代码中去获取既不适合也不安全所以返回null。
通过启动类加载器加载用户jar包
如果用户想扩展一些比较基础的jar包并让启动类加载器加载有以下两种途径。1. 放入jre/lib下进行扩展(不推荐)尽可能不要去更改JDK安装目录中的内容会出现即时放进去由于文件名不匹配的问题也不会正常地被加载2. 使用参数进行扩展(推荐)使用-Xbootclasspath/a:jar包目录/jar包名 进行扩展参数中的/a代表新增。 如下图在IDEA配置中添加虚拟机参数就可以加载D:/jvm/jar/classloader-test.jar这个jar包了。 Extension扩展类加载器和Application应用程序类加载器 1. ClassLoader类定义了具体的行为模式简单来说就是先从本地或者网络获得字节码信息然后调用虚拟机底层的方法创建方法区和堆上的对象。这样的好处就是让子类只需要去实现如何获取字节码信息这部分代码 2. SecureClassLoader提供了证书机制提升了安全性 3. URLClassLoader提供了根据URL获取目录下或者指定jar包进行加载获取字节码的数据 4. 扩展类加载器和应用程序类加载器继承自URLClassLoader获得了上述的三种能力。
通过扩展类加载器加载用户jar包
1. 放入/jre/lib/ext下进行扩展(不推荐)尽可能不要去更改JDK安装目录中的内容2. 使用参数进行扩展使用参数进行扩展(推荐)使用-Djava.ext.dirsjar包目录 进行扩展这种方式会覆盖掉原始目录可以用;(windows系统)或:(macos/linux系统)符号进行分隔追加上原始目录如下图。 使用引号将整个地址包裹起来这样路径中即便是有空格也不需要额外处理。路径中要包含原来ext文件夹同时在最后加上扩展的路径。 双亲委派机制
面试题1什么是双亲委派机制 1、当一个类加载器在加载某个类时会先自底向上查找是否有加载器加载过如果加载过就直接返回如果一直到最顶层的类加载器都没有加载再由顶向下进行加载 2、应用程序类加载器的父类加载器是扩展类加载器扩展类加载器的父类加载器是启动类加载器。
面试题2双亲委派的作用/好处有哪些 1.保证类加载的安全性。通过双亲委派机制避免恶意代码替换JDK中的核心类库比如java.lang.String确保核心类库的完整性和安全性 2.避免重复加载。双亲委派机制可以避免同一个类被多次加载。
面试题3如果一个类重复出现在三个类加载器的加载位置应该由谁来加载 答由启动类加载器加载根据双亲委派机制它的优先级是最高的。
面试题4String类能被覆盖吗在自己的项目中创建一个java.lang.String类会被加载吗 不会因为存在双亲委派机制类不会被重复加载会返回启动类加载器加载在rt.jar包中的String类。 打破双亲委派机制
打破双亲委派机制历史上有如下三种方式但本质上只有第一种算是真正的打破了双亲委派机制。 1. 自定义类加载器并且重写loadClass方法。Tomcat通过这种方式实现应用之间类隔离 2. 线程上下文类加载器。利用上下文类加载器加载类比如JDBC和JNDI等 3. Osgi框架的类加载器。历史上Osgi框架实现了一套新的类加载器机制允许同级之间委托进行类的加载目前很少使用。
自定义类加载器 一个Tomcat程序中是可以运行多个Web应用的如果这两个应用中出现了相同限定名的类比如Servlet类Tomcat就需要保证这两个类都能加载并且它们应该是不同的类。如果不打破双亲委派机制当应用类加载器加载Web应用1中的MyServlet之后Web应用2中相同限定名的MyServlet类就无法被加载了。 那么自定义加载器是如何做到打破双亲委派机制的呢首先我们需要了解双亲委派机制的代码到底在哪里接下来只需要把这段代码消除即可。 ClassLoader中包含了4个核心方法双亲委派机制的核心代码就位于loadClass方法中。
//类加载的入口提供了双亲委派机制。内部会调用findClass [重要]
public Class? loadClass(String name)//由类加载器子类实现,获取二进制数据调用defineClass
//比如URLClassLoader会根据文件路径去获取类文件中的二进制数据。[重要]
protected Class? findClass(String name)//做一些类名的校验然后调用虚拟机底层的方法将字节码信息加载到虚拟机内存中
protected final Class? defineClass(String name, byte[] b, int off, int len)//执行类生命周期中的连接阶段
protected final void resolveClass(Class? c)loadClass方法核心代码如下
//先查找是否加载过加载过就返回
Class? c findLoadedClass(name);//如果没有加载过,则委派给父类加载
if(c null){//parent等于null则说明父类加载器是启动类加载器if(parent ! null){c parent.loadClass(name,false);//由父类加载elsec findBootstrapClassOrNull(name);//由启动类加载器加载//若父类加载器无法加载则由本加载器加载if(c null)c findClass(name);}return c;
自定义加载器通过重写 loadClass 方法清除了其中有关双亲委派机制的逻辑因此打破了双亲委派机制。 按照loadClass方法的逻辑如果父类加载失败会调用自己的findClass方法来完成类的加载。如果用户在实现自定义类加载器时希望按照自己的意愿去加载类但又想保证自定义类加载器是符合双亲委派机制的则可以重写findClass方法在该方法中实现类的加载逻辑而不必重写loadClass方法从而保留了双亲委派机制的逻辑。
自定义类加载器打破双亲委派机制代码如下
package classloader.broken;//package com.itheima.jvm.chapter02.classloader.broken;import org.apache.commons.io.IOUtils;import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.nio.charset.StandardCharsets;
import java.security.ProtectionDomain;
import java.util.regex.Matcher;/*** 打破双亲委派机制 - 自定义类加载器*/public class BreakClassLoader1 extends ClassLoader {private String basePath;private final static String FILE_EXT .class;//设置加载目录public void setBasePath(String basePath) {this.basePath basePath;}//使用commons io 从指定目录下加载文件private byte[] loadClassData(String name) {try {String tempName name.replaceAll(\\., Matcher.quoteReplacement(File.separator));FileInputStream fis new FileInputStream(basePath tempName FILE_EXT);try {return IOUtils.toByteArray(fis);} finally {IOUtils.closeQuietly(fis);}} catch (Exception e) {System.out.println(自定义类加载器加载失败错误原因 e.getMessage());return null;}}//重写loadClass方法不再走双亲委派机制Overridepublic Class? loadClass(String name) throws ClassNotFoundException {//在加载默认的Object父类时需要交由父类加载if(name.startsWith(java.)){return super.loadClass(name);}//从磁盘中指定目录下加载byte[] data loadClassData(name);//调用虚拟机底层方法方法区和堆区创建对象return defineClass(name, data, 0, data.length);}public static void main(String[] args) throws ClassNotFoundException, InstantiationException, IllegalAccessException, IOException {//第一个自定义类加载器对象BreakClassLoader1 classLoader1 new BreakClassLoader1();classLoader1.setBasePath(D:\\lib\\);Class? clazz1 classLoader1.loadClass(com.itheima.my.A);//第二个自定义类加载器对象BreakClassLoader1 classLoader2 new BreakClassLoader1();classLoader2.setBasePath(D:\\lib\\);Class? clazz2 classLoader2.loadClass(com.itheima.my.A);System.out.println(clazz1 clazz2);Thread.currentThread().setContextClassLoader(classLoader1);System.out.println(Thread.currentThread().getContextClassLoader());System.in.read();}
}
默认情况下自定义类加载器的父类加载器是应用程序类加载器。
两个自定义类加载器加载相同限定名的类不会冲突吗 不会冲突在同一个Java虚拟机中只有相同类加载器相同的类限定名才会被认为是同一个类。 线程上下文类加载器
利用线程上下文类加载器加载类比如JDBC和JNDI等现对JDBC案例进行讨论首先需要介绍java SPI机制。
Java SPI机制 定义SPI 是一种基于接口的编程模式它允许服务提供者在不修改原有系统代码的情况下通过实现特定接口并将其部署到应用程序的类路径下从而被应用程序自动加载和使用。服务使用者只需定义接口规范并由服务提供者负责对接口进行实现服务使用者不用关心具体的实现细节。这使得代码的维护和升级更加容易降低了模块之间的耦合度。
Java SPI 的详细工作原理如下 1. 定义服务接口 首先定义一个接口这个接口将作为服务的规范规定所有实现类必须遵循的方法 2. 实现服务接口 接着创建一个或多个接口实现类每个实现类代表一个具体的服务提供者 3. 注册服务实现 在实现类的JAR 包中创建一个 META-INF/services/ 目录并在其中创建一个以服务接口全名命名的文件。文件内容包含实现类的全名每行一个 4. 加载和使用服务 使用 ServiceLoader 类来加载这些服务实现。ServiceLoader 会查找 META-INF/services 目录中的服务定义并加载所有实现类。
在 Java 中数据库连接是一个典型的 SPI 应用场景。Java 的java.sql.Driver接口就是一个服务接口。不同数据库厂商如 MySQL、Oracle、SQL Server 等提供了各自的Driver实现类。 JDBC中使用了DriverManager来管理项目中引入的不同数据库的驱动比如mysql驱动、oracle驱动。 DriverManager类由JDK提供位于rt.jar包中由启动类加载器加载。DriverManager类需要去加载服务提供者引入的jar包中的驱动类(SPI机制)而jar包中的驱动类需要委派应用程序类加载器去加载这种父类加载器去请求子类加载器完成类的加载行为打破了双亲委派机制。Java中涉及SPI的加载基本上都采用这种方式来完成。 Osgi框架的类加载器
历史上OSGi模块化框架存在同级之间的类加载器的委托加载。OSGi还使用类加载器实现了热部署的功能。热部署指的是在服务不停止的情况下动态地更新字节码文件到内存中。
以下内容节选自《深入理解 Java 虚拟机》总结在 OSGi 环境下类加载器不再遵循双亲委派模型所推荐的树状结构而是拥有一套自身的类加载规则其中部分规则打破了类的双亲委派机制。 总结
在上述介绍的三种打破双亲委派机制的方式中本质上只有第一种方式算是真正打破了该机制。这是因为双亲委派机制的核心代码在 loadClass 中而只有第一种方式重写了 loadClass 方法清除了其中有关双亲委派机制的逻辑。
至于其他两种方式从宏观层面也就是类的调用层面来看违背了双亲委派机制。但这两种方式并没有重写loadClass方法并未清除有关双亲委派机制逻辑的代码所以从单个类的角度而言是符合双亲委派机制的。 JDK9之后的类加载器
JDK8及之前的版本中扩展类加载器和应用程序类加载器的源码位于rt.jar包中的sun.misc.Launcher.java。
由于JDK9引入了module的概念类加载器在设计上发生了很多变化。 1.启动类加载器使用Java编写位于jdk.internal.loader.ClassLoaders类中。 Java中的BootClassLoader继承自BuiltinClassLoader实现从模块中找到要加载的字节码资源文件。启动类加载器依然无法通过java代码获取到返回的仍然是null保持了统一。
2、扩展类加载器被替换成了平台类加载器Platform Class Loader。 平台类加载器遵循模块化方式加载字节码文件所以继承关系从URLClassLoader变成了BuiltinClassLoaderBuiltinClassLoader实现了从模块中加载字节码文件。平台类加载器的存在更多的是为了与老版本的设计方案兼容自身没有特殊的逻辑。
