1、JDK的组成
- JDK 的全称(Java Development Kit Java开发工具包),作为java程序开发和运行的基础,包括了JRE(JavaRuntime Environment Java运行环境)和开发工具集,其中我们最熟悉的指令就是java、javac、jar、javap这几个;
- JRE(JavaRuntime Environment Java运行环境)其主要由JVM和java的一些核心类库组成;
今天我们主要围绕JVM来展开分析,深入浅出,走过路过不要错过。
2、类加载过程
- 在讲整体的结构之前,我们先得了解JVM干了什么?
- 众所周知,java程序有一大特性,叫做一次编译多次运行,也可称之为跨平台运行,而实现这个功能的最大功臣就是JVM。当java代码经过编译生成字节码文件(xxx.class),经由不同的JVM可以编译成不同的机器可识别的二进制文件进行计算和运行,这也解释了我们去下载jdk的时候需要选择不同的机器版本。
如上图所示,JVM会加载对应路径下的class文件到内存中运行,负责加载文件这一动作的一系列工具和包又被称之为类加载子系统。它分为三个阶段,其中会将验证、准备和解析的过程统一定义为链接过程:
加载:通过一个类的全限定名获取定义此类的二进制字节流,并将这个字节流所代表的静态数据结构转化为方法区的运行时数据结构(运行时常量池、类型信息、字段信息、方法信息、类加载器的引用、对应class实例的引用等)。使用到类时才会加载,例如调用类的main()方法,new对象等等,在加载阶段会在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口。注意,主类在运行过程中如果使用到其它类,会逐步加载这些类。jar包或war包里的类不是一次性全部加载的,是使用到时才加载。
验证:校验字节码文件的正确性,主要包括文件格式校验、无数据验证、字节码验证、符号引用验证等。
准备:给类的静态变量分配内存,并赋予默认值0、null、false,另外就是final修饰的变量因为是常量,会在准备阶段就显示的赋值。
解析:将符号引用替换为直接引用,该阶段会把一些静态方法(符号引用,比如main()方法)替换为指向数据所存内存的指针或句柄等(直接引用),这是所谓的静态链接过程(类加载期间完成),动态链接是在程序运行期间完成的将符号引用替换为直接引用。
初始化:对类的静态变量初始化为指定的值,执行静态代码块。
3、类加载器子系统
前面提到的类加载过程主要是通过类加载器来实现的,
Java里有如下几种类加载器:
引导类加载器:负责加载支撑JVM运行的位于JRE的lib目录下的核心类库,比如rt.jar、charsets.jar等
扩展类加载器:负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包
应用程序类加载器:负责加载ClassPath路径下的类包,主要就是加载你自己写的那些类
自定义加载器:负责加载用户自定义路径下的类包
4、双亲委派机制
重点来了,这么多加载器在程序运行的时候先加载那个后加载那个?是一起加载还是只选其中一个?这就不得不引出今天的第一个重点 :双亲委派机制。
其实这个大家背面试题的时候经常遇到,无非就是加载某个类时会先委托父加载器寻找目标类,找不到再委托上层父加载器加载,如果所有父加载器在自己的加载类路径下都找不到目标类,则在自己的类加载路径中查找并载入目标类。
定理很简单,它是怎么来的呢?为什么要这样做呢?好处是什么?相信很多人被这么一追问可能就开始慌了。首先我们先来说说为什么要这样做吧!
前面已经提到类在类加载的过程中只会加载一次,因此这几个类加载器一定要么从父类开始加载,要么从子类开始加载,为什么不从父类开始加载呢?这就要涉及到一个JVM的设计思想,其实不知道大家有没有运行过打印类加载器范围代码,从运行结果可以看出,在web应用中90%以上的类都可以被应用程序类加载器来加载,只有极少数的类需要用到它的父类加载器。因此,如果从父类开始一层层往下加载,就会浪费了大量的时间和空间。
public class TestJDKClassloader {
public static void main(String[] args) {
System.out.println(String.class.getClassLoader());//引导类加载器,因为核心是一个c++对象,所以,java程序无法识别
System.out.println(com.sun.crypto.provider.DESKeyFactory.class.getClassLoader().getClass().getName());//扩展类加载器
System.out.println(TestJDKClassloader.class.getClassLoader().getClass().getName());//应用程序类加载器
System.out.println();
ClassLoader appClassLoader = ClassLoader.getSystemClassLoader();
ClassLoader extClassloader = appClassLoader.getParent();
ClassLoader bootstrapLoader = extClassloader.getParent();
System.out.println("the bootstrapLoader: " + bootstrapLoader);
System.out.println("the extClassloader: " + extClassloader);
System.out.println("the appClassLoader: " + appClassLoader);
System.out.println();
System.out.println("bootstrapLoader加载以下文件: ");
URL[] urls = Launcher.getBootstrapClassPath().getURLs();
for (int i = 0; i < urls.length; i++) {
System.out.println(urls[i]);
}
System.out.println();
System.out.println("extClassloader加载以下文件: ");
System.out.println(System.getProperty("java.ext.dirs"));
System.out.println();
System.out.println("appClassLoader加载以下文件: ");
System.out.println(System.getProperty("java.class.path"));
}
}
解释完加载方向上的问题,我相信很多同学还会有一个问题,为什么要向上委托呢?看我下面的代码,运行结果告诉了我们一切,为什么呀!为了安全呀,如果不一层一层向上委托那么我直接就用应用程序类加载器把一个伪String类加载到内存中了,安全风险不要我多说了吧!这也是双亲委托机制的一个优点:
沙箱安全机制:自己定义的一些核心类不会被加载,可以有效防止核心的API库被篡改。
5、自定义类加载器
package java.lang;
/**
* @Auther: FU
* @Date: 2023/2/15 20:29
* @Description:
*/
public class String {
public static void main(String[] args) {
System.out.println("************My String Class*****************");
}
}
讲完为什么要这样做,双亲委托机制的好处想必大家也有一定理解了
除了上面所说的沙箱安全机制外,还有一个好处就是避免了类的重复加载,
当父亲已经加载了该类时,就没有必要子ClassLoader再加载一次,保证被加载类的唯一性
既然为什么和好处都明白了,我们不妨挑战一下Coding,看一下源码是如何来实现双亲委派机制的。
//ClassLoader的loadClass方法,里面实现了双亲委派机制
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {//如果当前加载器的父加载器不为空,则调用父类的loclass方法加载
c = parent.loadClass(name, false);
} else {//如果当前类加载的父类加载器为空,就委托引导类加载器加载
c = 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();
//如果父类加载器没有加载,则子类自己调用方法加载该类
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
该方法的大体逻辑如下:
1.首先,检查一下指定名称的类是否已经加载过,如果加载过了,就不需要再加载,直接返回。
2.如果此类没有加载过,那么,再判断一下是否有父加载器;如果有父加载器,则由父加载器加载(即调用parent.loadClass(name,false);)或者是调用bootstrap类加载器来加载。
3.如果父加载器及bootstrap类加载器都没有找到指定的类,那么调用当前类加载器的findClass方法来完成类加载。
看完了loadClass()方法,findClass()方法是不是也该看看。findClass()方法在ClassLoader类中并没有被实现,下面附上的是各个加载器的底层实现类URLClassLoader类的重写。其大致实现的功能就是获取到类的全限定名后经过一系列处理,把对应class文件以流的形式调用本地方法后转变成Class对象。
protected Class<?> findClass(final String name)
throws ClassNotFoundException
{
final Class<?> result;
try {
result = AccessController.doPrivileged(
new PrivilegedExceptionAction<Class<?>>() {
public Class<?> run() throws ClassNotFoundException {
String path = name.replace('.', '/').concat(".class");
Resource res = ucp.getResource(path, false);
if (res != null) {
try {
return defineClass(name, res);
} catch (IOException e) {
throw new ClassNotFoundException(name, e);
}
} else {
return null;
}
}
}, acc);
} catch (java.security.PrivilegedActionException pae) {
throw (ClassNotFoundException) pae.getException();
}
if (result == null) {
throw new ClassNotFoundException(name);
}
return result;
}
源码看完了,还记得我们上面的类加载过程中的自定义类加载器吗?
如果说**loadClass()方法实现了双亲委派的机制,那么findClass实现的就是去哪里获取资源,因此实现自定义加载器的关键就是findClass()**方法,下面我就自定义了一个类加载器来加载指定路径上的class文件。除此之外,既然loadClass方法可以重写,那么,我们是不是可以打破它呢?
答案是完全可以的,对于一些我们自定义的类,我就是不想让它一级一级往上委托,我就要一次直接加载,没问题。tomcat就是这样打破双亲委派机制的。
public class MyClassLoaderTest extends ClassLoader{
private String classPath;
public MyClassLoaderTest(String classPath) {
this.classPath = classPath;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
byte[] b = new byte[0];
try {
b = loadClassData(name);
//把一个字节数组转化为class对象,这个字节数组就是class文件读取到的内容
return defineClass(name, b, 0, b.length);
} catch (Exception e) {
e.printStackTrace();
throw new ClassNotFoundException();
}
}
private byte[] loadClassData(String name) throws Exception{
name = name.replaceAll("\\.","/");
FileInputStream inputStream = new FileInputStream(classPath +"/"+ name + ".class");
int len = inputStream.available();
byte[] data = new byte[len];
inputStream.read(data);
inputStream.close();
return data;
}
@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
if(!name.startsWith("com.fuyao.jvm")){
c = super.loadClass(name,false);
}else{
c = findClass(name);
}
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
public static void main(String[] args) throws Exception {
//初始化自定义加载器,会先去初始化父类的classLoader,其中会把自定义类加载器的父加载器设置为应用程序类加载器ApploadclassLoader
// MyClassLoaderTest classLoader = new MyClassLoaderTest("D:/tmp");
// //在D盘创建 tmp/com/fuyao/jvm/几级目录,将Solution.class的复制类Solution1.class丢入该目录
// Class clazz = classLoader.loadClass("com.fuyao.jvm.User");
// Object obj = clazz.newInstance();
// Method method = clazz.getDeclaredMethod("sout",null);
// method.invoke(obj,null);
// System.out.println(clazz.getClassLoader().getClass().getName());
MyClassLoaderTest classLoader = new MyClassLoaderTest("D:/tmp");
Class clazz = classLoader.loadClass("com.fuyao.jvm.User");
Object obj = clazz.newInstance();
Method method= clazz.getDeclaredMethod("sout", null);
method.invoke(obj, null);
System.out.println(clazz.getClassLoader());
System.out.println();
MyClassLoaderTest classLoader1 = new MyClassLoaderTest("D:/tmp1");
Class clazz1 = classLoader1.loadClass("com.fuyao.jvm.User");
Object obj1 = clazz1.newInstance();
Method method1= clazz1.getDeclaredMethod("sout", null);
method1.invoke(obj1, null);
System.out.println(clazz1.getClassLoader());
}
}
6、Tomcat打破双亲委派机制
我们思考一下:Tomcat是个web容器,
那么它要解决什么问题:
- 一个web容器可能需要部署两个应用程序,不同的应用程序可能会依赖同一个第三方类库的不同版本,不能要求同一个类库在同一个服务器只有一份,因此要保证每个应用程序的类库都是独立的,保证相互隔离。
- 部署在同一个web容器中相同的类库相同的版本可以共享。否则,如果服务器有10个应用程序,那么要有10份相同的类库加载进虚拟机。
- web容器也有自己依赖的类库,不能与应用程序的类库混淆。基于安全考虑,应该让容器的类库和程序的类库隔离开来。
- web容器要支持jsp的修改,我们知道,jsp文件最终也是要编译成class文件才能在虚拟机中运行,但程序运行后修改jsp已经是司空见惯的事情,web容器需要支持jsp修改后不用重启。
Tomcat如果使用默认的双亲委派类加载机制行不行?
答案是不行的。为什么?
第一个问题,如果使用默认的类加载器机制,那么是无法加载两个相同类库的不同版本的,默认的类加器是不管你是什么版本的,只在乎你的全限定类名,并且只有一份。
第二个问题,默认的类加载器是能够实现的,因为他的职责就是保证唯一性。
第三个问题和第一个问题一样。我们再看第四个问题,我们想我们要怎么实现jsp文件的热加载,jsp文件其实也就是class文件,那么如果修改了,但类名还是一样,类加载器会直接取方法区中已经存在的,修改后的jsp是不会重新加载的。那么怎么办呢?我们可以直接卸载掉这jsp文件的类加载器,所以你应该想到了,每个jsp文件对应一个唯一的类加载器,当一个jsp文件修改了,就直接卸载这个jsp类加载器。重新创建类加载器,重新加载jsp文件。
从图中的委派关系中可以看出:
CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用,从而实现了公有类库的共用,而CatalinaClassLoader和SharedClassLoader自己能加载的类则与对方相互隔离。WebAppClassLoader可以使用SharedClassLoader加载到的类,
但各个WebAppClassLoader实例之间相互隔离。而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件,它出现的目的就是为了被丢弃:当Web容器检测到JSP文件被修改时,会替换掉目前的JasperLoader的实例,并通过再建立一个新的Jsp类加载器来实现JSP文件的热加载功能。