java类加载过程:
.java文件经过编译之后生成.class文件,.class文件被加载内存中即jvm中,.class文件加载过程包括验证(校验.class文件是否有错),准备(给类的静态变量分配内存,给.class文件中的变量赋默认值),解析(将符号引用替换为直接引用,该阶段会吧一些静态方法(符号引用,比如main()方法)替换为指数数据所存内存的指针或句柄等(直接引用),这是所谓的静态连接过程(类加载期间完成),动态链接是在程序运行期间完成的将符号引用替换为直接引用)。初始化:对类的静态变量初始化为指定的指,执行静态代码块。
示例如下:
其中loadClass的类加载过程如下几步:
加载》验证》准备》解析》初始化》使用》卸载
加载:在硬盘上查找并通过io读入字节码文件,使用到类时才会加载,例如调用类的main方法,new对象等等,在加载阶段会在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据的访问入口
验证:校验字节码文件的正确性
准备:给类的静态变量分配内存,并赋予默认值
解析:将符号应用替换为直接引用,该阶段会把一些静态方法(符号引用,比如main()方法)替换为指向数据所存内存的指针或句柄等(直接引用),这是所谓的静态链接过程(类加载期间完成),动态链接是在程序运行期间完成的将符号引用替换为直接引用。
初始化:对类的静态变量初始化指定的值,执行静态代码块
类加载器初始化过程:
首先会创建jvm启动器示例sun.misc.Launcher.sun.misc.Launcher初始化使用了单例模式设计,保证一个jvm虚拟机内只有一个sun.misc.Launcher示例,在Launcher构造方法内部,其创建了两个类加载器,分别是sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)
jvm默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序。
public Launcher() {
Launcher.ExtClassLoader var1;
try {
var1 = Launcher.ExtClassLoader.getExtClassLoader(); //先构建扩展类加载器,在构造过程中将其父类加载器设置为null
} catch (IOException var10) {
throw new InternalError("Could not create extension class loader", var10);
}
try {
this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);// 构建应用类加载器,在构造的过程中将其父加载器设置为ExtClassLoader
} 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);
}
}
代码中的注释依据如下:
ClassLoader appClassLoader = ClassLoader.getSystemClassLoader();
ClassLoader extClassLoader = appClassLoader.getParent();
ClassLoader bootstrapLoader = extClassLoader.getParent();
System.out.println(appClassLoader);
System.out.println(extClassLoader);
System.out.println(bootstrapLoader);
//
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$ExtClassLoader@1b6d3586
null
双亲委派机制:
加载过程图解:
加载过程讲解:
比如我们要加载Math这个类,首先应用类加载器(appClassLoader)会从已经加载类中查找Math类,如果已经加载,则直接返回不再加载。如果找不到,则委托他的的父类,扩展类加载器(extClassLoader)进行加载,扩展类加载器会从已经加载的类中查找是否加载过此类,如果加载过则直接返回,如果没有加载,则委托他的父类引导类加载器(bootstrapClassLoader)进行加载,引导类加载器会从已经加载的类中查找是否加载过此类,他会去jdk安装路径/jdk/jre/lib/下查找是否加载过此类,如果加载过则直接返回,如果没有加载过则由其子类扩展类加载器进行加载,扩展类加载器会去jdk安装路径/jdk/jre/lib/ext,C:\Windows\Sun\Java\lib\ext文件夹下去找是否加载过Math类,如果没有由其子类应用类加载器进行加载,应用类加载器会去项目根路径classpath的target路径下寻找Math类,如果能找到则返回,如果找不到则报ClassNotFoundException异常。
jdk中为什么要有双亲委派机制:
1、保证沙箱环境安全:比如在项目中自定了一个com.lang.String.class类是不是被加载的,这样就可以防止核心api库被篡改。
2、避免类的重复加载:如果父加载器已经加载此类时,子加载器就没有必要再去加载一次,这样保证被加载类的唯一性。
自定义一个类加载器:
public class MyClassLoaderTest {
static class MyClassLoader extends ClassLoader{
private String classPath;
public MyClassLoader(String classPath){
this.classPath = classPath;
}
private byte[] loadBy(String name) throws Exception{
name = name.replace(".","\\");
System.out.println(classPath+"\\"+name+".class");
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[] bytes = loadBy(name);
return defineClass(name,bytes,0, bytes.length);
} catch (Exception e) {
e.printStackTrace();
throw new ClassNotFoundException();
}
}
public static void main(String[] args) throws ClassNotFoundException, IllegalAccessException, InstantiationException, NoSuchMethodException, InvocationTargetException {
MyClassLoader classLoader = new MyClassLoader("E:\\test");
Class aClass = classLoader.findClass("com.cf.test.User");
Object o = aClass.newInstance();
Method m = aClass.getMethod("sout", null);
Object invoke = m.invoke(o, null);
System.out.println(aClass.getClassLoader().getClass().getName());
}
}
}
运行上面的main方法,发现输出的类加载器为sun.misc.Launcher$AppClassLoader,这是因为在我们的项目中存在一个user.class文件,因为自定义类加载器的父加载器为AppClassLoader及双亲委派机制的存在,所有先由父类加载器去加载。所以没有调用自定义的加载器。
将项目总user.class文件删掉,在运行main方法,就会发现此时调用的是com.cf.test.MyClassLoaderTest$MyClassLoader自定义的类加载器。综上我们便可更深入的了解双亲委派机制。
打破双亲委派机制:
因为jvm类加载器核心是loadClass,所以我们打破双亲委派机制也就是重写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) {
// 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();
// 添加自己定义的类自己用我们自定义的类加载器加载
if(!name.startsWith("com.cf")){
c = this.getParent().loadClass(name);
}else{
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;
}
}
jvm 图解