系列文章目录
第一章 “解剖”JVM系列(一)之如何进行类加载？
目录
前言
随着互联网的飞速发展，JVM虚拟机的发展也层出不穷，也随着你工作经验的提升，JVM是面试以及知识栈里面不可或缺的一个组成部分。JVM虚拟机有很多，这个系列文章我们暂时讲的就是现在流行的Hotspot虚拟机。我们将以深度"解剖"虚拟机为目标，通过解析JVM的组成，实现，原理来了解整个JVM虚拟机的脉络。
下图是该系列文章的总图，将串联我们整个系列文章：
传送门：JVM内存模型全景 | ProcessOn免费在线作图,在线流程图,在线思维导图 |
一、JVM如何进行从java源码到class字节码？
从Java源码到Class字节码的过程就如总图中的javac编译器的过程，这个过程叫做前端编译。
说到JVM里面的编译先大致了解一下有如下3种：
- 前端编译器：把*.java文件转变成*.class文件的过程。
- 即时编译器：也叫做JIT，运行期把字节码转变成机器码的过程。
- 提前编译器：也叫做AOT，直接把程序编译成与目标机器指令集相关的二进制代码。
这里主要讲的第一种前端编译器，后续两种在后面章节会依次讲到。
这里的前端编译器指的是JDK中的Javac编译器，这个编译过程可以分为1个准备和3个处理过程。
- 准备过程：初始化插入时注解处理器。
- 解析与填充符号表过程。包括：
- 词法、语法分析：将源代码的字符流转变为标记集合，构造出抽象语法树。
- 填充符号表：产生符号地址和符号信息。
- 插入式注解处理器的注解处理过程。
- 分析与字节码生成过程。
- 标注检查：对语法的静态信息进行检查。
- 数据流及控制流分析：对程序动态运行过程进行检查。
- 解语法糖：将简化代码编写的语法糖还原为原有的形式。
- 字节码生成：将前面各个步骤所生成的信息转化为字节码。
二、类加载的全过程
一个类型从被加载到虚拟机内存中开始，直到卸载出内存为止，它的生命周期会经历加载，验证，准备，解析，初始化，使用，卸载。其中验证，准备，解析这三个部分统称为连接。
这里着重讲一下前5个阶段：
- 加载：通过一个类的全限定类名来获取定义此类的二进制字节流，在使用到类时才会加载；将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
- 验证：验证字节码文件的正确性。
- 准备：给类的静态变量分配内存，并赋予默认值。
- 解析：将符号引用替换为直接引用，该阶段会把一些静态方法(符号引用，比如main()方法)替换为指向数据所存内存的指针或者句柄等(直接引用)。
- 初始化：对类的静态变量初始化为指定的值，执行静态代码块。
类被加载到方法区中后主要包含：运行时常量池，类型信息，字段信息，方法信息，类加载器的引用，对象class实例的引用等。
PS：主类在运行过程中如果使用到其它类，会逐步加载这些类。jar包或者war包里的类不是一次性全部加载的，是使用到时才会加载。
代码示例如下：
public class DynamicLoad {
static {
System.out.println("-------------加载 DynamicLoad-----------------");
}
public static void main(String[] args) {
new A();
System.out.println("-------------加载 main-----------------");
B b = null;
}
}
class A {
static {
System.out.println("-------------加载 A-----------------");
}
public A() {
System.out.println("-------------初始化 A-----------------");
}
}
class B {
static {
System.out.println("-------------加载 B-----------------");
}
public B() {
System.out.println("-------------初始化 B-----------------");
}
}结果如下：
-------------加载 DynamicLoad-----------------
-------------加载 A-----------------
-------------初始化 A-----------------
-------------加载 main-----------------
三、类加载器和双亲委派机制
1.类加载器
类加载过程主要是通过类加载器来实现的，Java中主要有以下几种类加载器：
- 引导类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如
rt.jar、charsets.jar等。
- 扩展类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR
类包。
- 应用类加载器：负责加载ClassPath路径下的类包，主要就是加载你自己写的那
些类。
-
自定义类加载器：负责加载用户自定义路径下的类包。
2.双亲委派机制
3.从JDK源码层面剖析类加载器
JDK源码中类加载器初始化源码如下：
// Launcher的构造方法
public Launcher() {
Launcher.ExtClassLoader var1;
try {
// 构造扩展类加载器，在构造过程中将其父加载器设置为null
var1 = Launcher.ExtClassLoader.getExtClassLoader();
} catch (IOException var10) {
throw new InternalError("Could not create extension class loader", var10);
}
try {
// 构造应用类加载器，在构造的过程中将其父加载器设置为ExtClassLoader
// Launcher的loader属性值是AppClassLoader，我们一般都是用这个类加载器来加载我们自己写的应用程序
this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
} catch (IOException var9) {
throw new InternalError("Could not create application class loader", var9);
}
Thread.currentThread().setContextClassLoader(this.loader);
String var2 = System.getProperty("java.security.manager");
if (var2 != null) {
SecurityManager var3 = null;
if (!"".equals(var2) && !"default".equals(var2)) {
try {
var3 = (SecurityManager)this.loader.loadClass(var2).newInstance();
} catch (IllegalAccessException var5) {
} catch (InstantiationException var6) {
} catch (ClassNotFoundException var7) {
} catch (ClassCastException var8) {
}
} else {
var3 = new SecurityManager();
}
if (var3 == null) {
throw new InternalError("Could not create SecurityManager: " + var2);
}
System.setSecurityManager(var3);
}
}参考流程图和源码可以知道初始化sun.misc.Launcher实例的时候使用了单列模式，保证一个JVM虚拟机内只有一个sun.misc.Launcher实例。
在Launcher的构造方法内部，创建了两个类加载器，一个是：sun.misc.Launcher.ExtClassLoader；一个是：sun.misc.Launcher.AppClassLoader。
JVM默认Launcher中使用getLauncher()方法返回的类加载器是AppClassLoader的实例来加载我们自己写的程序。
JDK源码中双亲委派机制源码如下：
// ClassLoader的loadClass方法，里面实现了双亲委派机制
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 检查当前类加载器是否已经加载了该类
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
// 如果当前加载器父加载器不为空则委托父加载器加载该类
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) {
long t1 = System.nanoTime();
//都会调用URLClassLoader的findClass方法在加载器的类路径里查找并加载该类
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;
}
}双亲委派机制源码逻辑大致如下：
-
首先，检查一下指定名称的类是否已经加载过，如果加载过了，就不需要再加载，直接返回。
-
如果此类没有加载过，那么，再判断一下是否有父加载器；如果有父加载器，则由父加载器加载（即调用parent.loadClass(name, false);）.或者是调用bootstrap类加载器来加载。
-
如果父加载器及bootstrap类加载器都没有找到指定的类，那么调用当前类加载器的 findClass方法来完成类加载。
4.为什么要设计双亲委派机制？
- 沙箱安全机制：自己写的和JDK核心类同名的类不会被加载，这样便可以防止核心 API库被随意篡改。
- 避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次，保证被加载类的唯一性
5.自定义类加载器
自定义类加载器只需要继承java.lang.ClassLoader类。该类中有两个核心方法：
- loadClass(String name, boolean resolve)：实现了双亲委派机制。
- findClass(String name)：默认空实现。
自定义类加载器主要就是重写findClass方法。
public class MyClassLoader extends ClassLoader{
private String classPath;
public MyClassLoader(String classPath) {
this.classPath = classPath;
}
private byte[] loadByte(String name) throws Exception {
name = name.replaceAll("\\.", "/");
FileInputStream fis = new FileInputStream(classPath + "/" + name
+ ".class");
int len = fis.available();
byte[] data = new byte[len];
fis.read(data);
fis.close();
return data;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
byte[] data = loadByte(name);
//defineClass将一个字节数组转为Class对象，这个字节数组是class文件读取后最终的字节数组。
return defineClass(name, data, 0, data.length);
} catch (Exception e) {
e.printStackTrace();
throw new ClassNotFoundException();
}
}
}
class MyClassloaderTest {
public static void main(String[] args) throws Exception {
// 初始化自定义类加载器，会先初始化父类ClassLoader，其中会把自定义类加载器的父加载器设置为应用程序类加载器AppClassLoader
MyClassLoader classLoader = new MyClassLoader("D:/test");
// D盘创建 D:\test\com\atao\jvm 几级目录，将User类的复制类User.class丢入该目录
Class clazz = classLoader.loadClass("com.atao.jvm.User");
Object obj = clazz.newInstance();
Method method = clazz.getDeclaredMethod("sout", null);
method.invoke(obj, null);
System.out.println(clazz.getClassLoader().getClass().getName());
}
}
运行结果如下：
=======自己的加载器加载类调用方法=======
com.atao.jvm.MyClassLoader
6.打破双亲委派机制
沙箱安全机制打破双亲委派机制，加载自定义实现的java.lang.String.class:
public class MyClassLoaderString extends ClassLoader {
private String classPath;
public MyClassLoaderString(String classPath) {
this.classPath = classPath;
}
private byte[] loadByte(String name) throws Exception {
name = name.replaceAll("\\.", "/");
FileInputStream fis = new FileInputStream(classPath + "/" + name
+ ".class");
int len = fis.available();
byte[] data = new byte[len];
fis.read(data);
fis.close();
return data;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
byte[] data = loadByte(name);
//defineClass将一个字节数组转为Class对象，这个字节数组是class文件读取后最终的字节数组。
return defineClass(name, data, 0, data.length);
} catch (Exception e) {
e.printStackTrace();
throw new ClassNotFoundException();
}
}
/**
* 重写类加载方法，实现自己的加载逻辑，不委派给双亲加载
* @param name
* @param resolve
* @return
* @throws ClassNotFoundException
*/
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();
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;
}
}
}
class MyClassLoaderStringTest {
public static void main(String[] args) throws Exception {
MyClassLoaderString classLoader = new MyClassLoaderString("D:/test");
//尝试用自己改写类加载机制去加载自己写的java.lang.String.class
Class clazz = classLoader.loadClass("java.lang.String");
Object obj = clazz.newInstance();
Method method= clazz.getDeclaredMethod("sout", null);
method.invoke(obj, null);
System.out.println(clazz.getClassLoader().getClass().getName());
}
}
运行结果如下：
java.lang.SecurityException: Prohibited package name: java.lang
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:655)
at java.lang.ClassLoader.defineClass(ClassLoader.java:754)
at java.lang.ClassLoader.defineClass(ClassLoader.java:635)
7.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文件。
tomcat中主要的类加载器：
- common类加载器：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问；
- catalina类加载器：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见；
- shared类加载器：各个Webapp共享的类加载器，加载路径中的class对于所有Webapp可见，但是对于Tomcat容器不可见；
- webapp类加载器：各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见，比如加载war包里相关的类，每个war包应用都有自己的WebappClassLoader，实现相互隔离，比如不同war包应用引入了不同的spring版本，这样实现就能加载各自的spring版本；
CommonClassLoader能加载的类都可以被CatalinaClassLoader和SharedClassLoader使用，从而实现了公有类库的共用，而CatalinaClassLoader和SharedClassLoader自己能加载的类则与对方相互隔离。
WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个WebAppClassLoader实例之间相互隔离。
而JasperLoader的加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件，它出现的目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的热加载功能。
很显然，tomcat 不是这样实现，tomcat 为了实现隔离性，没有遵守这个约定，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器，打破了双亲委派机制。
总结
本篇文档主要从原理层面到源码层面深度剖析了类加载器的整个流程，结合文章中的示例代码让你在JVM类加载相关问题中游刃有余。
欢迎关注我的个人微信公众号：阿涛在coding