01_从JDK源码级别剖析JVM类加载机制

从JDK源码级别剖析JVM类加载机制

应用-------》扩展---------》引导类

双亲委派机制

AppClassLoader会调用URLClassLoader中的LoadClass方法，该方法中findLoadedClass方法来在已加载集合中判断该类是否已经被加载，如果被加载了则直接返回。如果没有则会进入if判断语句，判断parent是否为空，不为空则进去ExtClassLoader类加载器，再次调用LoadClass方法【方法和AppClassLoader流程一致】，，【查找该类是否在扩展类中已被加载】若为空则，，则进入if判断语句判断parent是否为空，为空的话【引导类加载器是找不到的为空】，，会直接调将值C = findBootstrapClassOrNull(name),这个方法，会去引导类加载器已经加载过的类中找有没有这个类，，如果没有的话，则跳出执行扩展类加载器（ExtClassLoader加载器）因为一开始就确定了应用类加载器与扩展类加载器的关系，就会去进去AppClassLoader加载器中，，在里面会调用findclass方法（该方法为URLClassLoader父类的方法），findClass方法中ucp.getResourse(path,false)得到路径后，，defineclass方法将该类加载【该方法的实现里面都是本地方法c++实现】

自己写类加载器

该类要继承ClassLoader，重写里面的findClass(类名)方法，该方法跟你局传过来的类名，直接去磁盘中找，调用defineclass方法，它调用一系列的本地方法区实现对该类的加载

【问题】：任何类都会是Object类的子类，所以jvm底层中有沙箱安全机制，会报错，这时候加个判断逻辑

if(!name.startWith("该类的包名路径")){
		c=this.getParent().loadClass(name)
}else{
		c=findClass(name)
}

打破双亲委派机制

主要是重写LoadClass方法，并将向上委派的逻辑代码删除掉即可

以上是回忆篇，今后还会回顾整理，并附上debug详细步骤