从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详细步骤