类的加载过程
类的加载过程分三个阶段
类的加载 ==》类的链接 ==》类的初始化
- **类的加载:**将Class文件字节码加载到内存中,并将这些静态数据转换为方法区的运行时数据结构,然后在堆中(方法区)生成一个代表该类的Class对象,作为类数据的访问入口,可以使用反射获取该类的所有信息。
- **类的链接:**将Java类的二进制代码合并到JVM中
- 验证:确保加载的类符合JVM规范
- 准备:为静态变量分配内存并设置成员变量的默认值
- 解析:JVM常量池内的符号引用(常量名)替换为直接引用(地址)的过程
- **类的初始化:**执行类构造器< clinit >()方法的过程
- 类构造器方法是由编译期按顺序收集类中所有类变量的赋值动作和静态代码块中的语句合并而成的(类构造器是构造类信息的,不是对象构造器)
- 当初始化一个类的时候,如果其父类为初始化,则先初始化其父类
- JVM会保证类构造器在多线程环境下被正确加锁
类的链接为黑盒实现
类的主动引用(一定会发生类的初始化)
- 当JVM启动的时候,先初始化main方法所在的类
- new 一个类的对象
- 调用该类的静态成员(除了final)和静态方法
- 使用反射对其类进行反射调用
- 当初始化一个类时,其父类若没有初始化,则先初始化其父类
类的被动引用(不会发生类的初始化)
- 当访问一个静态域的时候,只有真正声明该域的类才会被初始化。举个栗子:当通过子类调用父类的静态变量,该子类是不会被初始化的
- 通过数组定义类引用,不会导致初始化
- 引用常量不会导致初始化
类加载器
市面上有三种JVM,不同的JVM对类加载器的实现是不同的,我们主要学习的并且使用的是Sun公司的HotSpot
类加载器的作用就是将类(class)装进内存的
JVM规定了以下类型的加载器
**引导类加载器:用C++**编写的,是JVM自带的类加载器,负责java平台的核心库,用来装载核心类库,该加载器无法直接获取(获取的时候会是null)
扩展类加载器(ExtClassLoader):负责<JAVA_HOME>/lib/etc目录下的jar包户或者 -d java.ext.dirs指定目录下的jar包装入工作库
系统类加载器(AppClassLoader):负责java -classpath或者java.class.path指定目录下的类与jar包
**用户加载器(User ClassLoader):**用户自定义的加载器
扩展类加载器、系统类加载器、用户加载器都是继承自java.lang.ClassLoader
JVM规范:每个类加载器都有属于自己的命名空间
双亲委派机制
检查顺序从下至上,加载顺序从顶至下
举个栗子:我写了一个Student类,我要加载它需要经过以下过程
- 先将该任务委托给AppClassLoader
- AppClassLoader很懒,它不想加载,将任务向上委托给ExtClassLoader
- ExtClassLoader也很懒,它不想加载,继续将任务向上委托给BootStrapClassLoader
- BootStrapClassLoader没法偷懒了,只能自己加载,但是在自己管理的lib目录下并没有找到该类,只能将任务再次交给ExtClassLoader去加载
- 那ExtClassLoader没法偷懒了,只能在自己管理的ext目录下找该类,但是也没有找到,只能将任务继续向下转交给AppClassLoader
- AppClassLoader不得不自己去尝试加载该类,于是加载成功
既然最后还是AppClassLoader去加载Student类何必绕一个大圈子呢?
这是为了防止原始类被用户写的类所覆盖。
再举个栗子:我自己写了一个String类,我要加载它会经历以下过程
- 先将该任务委托给AppClassLoader
- ExtClassLoader也很懒,它不想加载,继续将任务向上委托给BootStrapClassLoader
- BootStrapClassLoader没法偷懒了,只能自己加载,于是在自己管理的lib目录下找到该类并加载,将加载结果向下一直传递到用户
对双亲委派模型的破坏
1、自定义类加载器
我们写一个类继承java.lang.ClassLoader
,重写loadClass方法,双亲委派的逻辑就在这个方法中,但是我自定义的类加载器可以不这么写,也就破坏了双亲委派。在jdk1.2之后,jdk增加了一个findClass
方法提供给上层重写,也就有效地防止了双亲委派被破坏
public static void main(String[] args) throws ClassNotFoundException, InstantiationException, IllegalAccessException {
ClassLoader myClassLoader = new ClassLoader(){
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
try{
String fileName = name.substring(name.lastIndexOf(".")+1)+".class";
InputStream is = getClass().getResourceAsStream(fileName);
if(is==null){
return super.loadClass(name);
}
byte[] buffer = new byte[is.available()];
is.read(buffer);
return defineClass(name,buffer,0, buffer.length);
}catch (Exception e){
e.printStackTrace();
throw new ClassNotFoundException(name);
}
}
};
Object o = myClassLoader.loadClass("com.test.A").newInstance();
System.out.println(o.getClass());
System.out.println(o instanceof com.test.A);
}
控制台输出
class com.test.A
false
这不仅破坏了双亲委派,并且证明了每个类加载器都有自己的命名空间
2、SPI(Service Provider Interface)服务发现机制
JDK中定义了JDBC的接口,规范各大厂家。对于JDK中的接口,使用的是BootstrapClassLoader
但是对于各大厂家的实现类,使用的是ApplClassLoader
@CallerSensitive
public static Driver getDriver(String url)
throws SQLException {
println("DriverManager.getDriver(\"" + url + "\")");
ensureDriversInitialized();
Class<?> callerClass = Reflection.getCallerClass();
// Walk through the loaded registeredDrivers attempting to locate someone
// who understands the given URL.
for (DriverInfo aDriver : registeredDrivers) {
// If the caller does not have permission to load the driver then
// skip it.
if (isDriverAllowed(aDriver.driver, callerClass)) {
try {
if (aDriver.driver.acceptsURL(url)) {
// Success!
println("getDriver returning " + aDriver.driver.getClass().getName());
return (aDriver.driver);
}
} catch(SQLException sqe) {
// Drop through and try the next driver.
}
} else {
println(" skipping: " + aDriver.driver.getClass().getName());
}
}
println("getDriver: no suitable driver");
throw new SQLException("No suitable driver", "08001");
}
@CallerSensitive
public static <S> ServiceLoader<S> load(Class<S> service) {
// 当前线程的ClassLoader默认为AppClassLoader
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return new ServiceLoader<>(Reflection.getCallerClass(), service, cl);
}
3、热部署