手撸jdk源码分析类加载机制
我们一般写的java文件jvm是识别不了的，因此需要编译，编译后会变成.class文件，而要执行代码，jvm首先会去加载.class文件到内存中，那么他的流程是什么样的呢：
1.首先肯定创建java虚拟机(就像我们运行windows的程序首先得安装windows系统一个道理)
2.同时会创建一个引导类加载器实例(这个由c++实现，也就是我们的BootStrap类加载器)
3.然后c++代码会调用创建java的启动类launcher创建类加载器，去加载不同类型的类
4.类加载完成会调用对应的main方法
5.运行后销毁
流程如下图所示：
具体的类加载流程：加载>>验证>>准备>>解析>>初始化>>使用>>卸载
1.加载：加载就是找到对应的字节码文件并加载到内存
2.验证： 验证字节码文件的格式等正确性
3.准备：加载静态变量到内存并赋值
4.解析：将符号引用转换为直接引用（内存地址）
5.初始化： 将类加载到方法区，执行静态代码块，初始化静态变量值
大概了解之后，我们直接撸代码：
public Launcher() { Launcher.ExtClassLoader var1; try { //获取扩展类加载器extclassLoader var1 = Launcher.ExtClassLoader.getExtClassLoader(); } catch (IOException var10) { throw new InternalError("Could not create extension class loader", var10); } try { 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); } } public ExtClassLoader(File[] var1) throws IOException { super(getExtURLs(var1), (ClassLoader)null, Launcher.factory);//这里可以看到ext的父类加载器设为null SharedSecrets.getJavaNetAccess().getURLClassPath(this).initLookupCache(this); } AppClassLoader(URL[] var1, ClassLoader var2) { //这里可以看到app的父类加载器就是上面传进来的var1->extClassLoader super(var1, var2, Launcher.factory); this.ucp.initLookupCache(this); }
这就可以看到应用类加载器的父类加载器是扩展类加载器，继续看加载流程，看appClassLoader的loadClass方法：
public Class<?> loadClass(String var1, boolean var2) throws ClassNotFoundException { int var3 = var1.lastIndexOf(46); if (var3 != -1) { SecurityManager var4 = System.getSecurityManager(); if (var4 != null) { var4.checkPackageAccess(var1.substring(0, var3)); } } if (this.ucp.knownToNotExist(var1)) { //查看是否已经被加载过,获取存在直接 Class var5 = this.findLoadedClass(var1); if (var5 != null) { if (var2) { this.resolveClass(var5); } return var5; } else { throw new ClassNotFoundException(var1); } } else { //不存在调用父类 return super.loadClass(var1, var2); } }
再看父类，extClassLoader调用的也是这个：
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); //查询JVM，已经被加载并返回，否则返回null if (c == null) { //不存在 long t0 = System.nanoTime(); try { if (parent != null) { //有父调用父类加载器 c = parent.loadClass(name, false); } else { //当父类加载器不存在，如extClassLoad设置父类为null(其实是有的,但其父类bootStrapClassLoad在JVM中由c++实现，所以设置为null) c = findBootstrapClassOrNull(name); //这里点进去看可以发现其实就是获取BootStrapClass } } 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(); 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; } }
这里我们可以理一下顺序：
1.首先会去调用appClassLoad的loadClass方法，如果已经加载过，则直接获取，否则调用父加载方法
2.父类方法依旧会找一次当然还是没有，会去调用父类加载器的loadClass方法(前面我们已经知道appClassLoad父加载器为extClassLoad)
3.递归调用classLoad方法，直到父加载器为空(也就是extClassLoad)，会去获取BootStrapClass类加载器调用类加载方法
4.还是获取不到则按顺序查找类，这个我们下面详细再看
protected Class<?> findClass(final String name) throws ClassNotFoundException { final Class<?> result; try { result = AccessController.doPrivileged( new PrivilegedExceptionAction<Class<?>>() { public Class<?> run() throws ClassNotFoundException { String path = name.replace('.', '/').concat(".class"); //拼接class文件地址 Resource res = ucp.getResource(path, false); //获取资源 if (res != null) { try { return defineClass(name, res); //解析指定的资源类 } catch (IOException e) { throw new ClassNotFoundException(name, e); } } else { return null; } } }, acc); } catch (java.security.PrivilegedActionException pae) { throw (ClassNotFoundException) pae.getException(); } if (result == null) { throw new ClassNotFoundException(name); } return result; }
其实就是根据类名拼接class文件地址，并解析指定的资源类，再往下基本就是分析c++代码了，这个后续有时间在研究吧.
看完代码，我们再来看一些我们之前背了又忘的理论：双亲委派机制，那么我们再来分析分析：
双亲委派机制：
如上图所示，其实就是双亲委派机制，仔细看的话发现和我上面分析代码的逻辑是一样的，是的，上面loadClass递归调用其实就是我们双亲委派机制的实现，而实际的类加载，就在我们的findClass方法里。
这个时候问题就来了，类加载一个类加载器就够了，为什么要搞这么复杂的结构呢？
答案其实就是为了安全，可靠。我们java中有很多基础类库如Object类，算是我们开发的基石，但是如果说只用一个编辑器的话，当出现外部也定义了一个相同路径名的类时，就可能覆盖或者冲突，无论哪种情况，都会对我们的程序造成不可控的影响。而像上述图中，每个类加载器各司其职，只专注于做自己的事情，这样既不会改变基础类库，也不会出现重复加载的情况。仔细想想，这也是解耦的思想的体现。
双亲委派模型的特色就是，安全，可靠，不会出现重复加载，但是像tomcat这样需要加载多个应用程序的又怎么办呢----->打破双亲委派。
打破双亲委派
双亲委派机制是很厉害的，但jdk也给我们提供了自定义类加载的拓展，其实就是让我们有更多的实现，其实要打破的实现也很简单，就是重写loadClass方法，将所需要打破的直接findClass，而不去调用父类的findClass,代码如下：
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { Class<?> c = findLoadedClass(name); if (c == null) { long t = System.nanoTime(); if(!name.startsWith("broker")){ //可以将需要打破双亲委派的单独放一个包里 c = super.loadClass(name); }else { c = findClass(name); } sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t); sun.misc.PerfCounter.getFindClasses().increment(); } if (resolve) { resolveClass(c); } return c; } }
tomcat打破双亲委派：
tomcat是服务部署容器，首先我们得了解他有哪些问题：
1.在部署多应用程序时，可能出现多个程序不同版本，因此，每个程序依赖需要相互独立，互相隔离。
2.相同版本类库不需要重新加载。
3.web容器和应用容器隔离
4.jsp文件热加载
tomcat为了解决这个问题，肯定是需要打破双亲委派模型的，毕竟应用之间有需要隔离的，web容器和应用容器也需要隔离，而jsp文件预加载则需要改动后卸载掉重新加载，总结一下就是：
第一个问题，如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认的类加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。
第二个问题，默认的类加载器是能够实现的，因为他的职责就是保证唯一性。
第三个问题和第一个问题一样。
我们再看第四个问题，我们想我们要怎么实现jsp文件的热加载，jsp文件其实也就是class文件，那么如果修改了，但类名还是一样，类加载器会直接取方法区中已经存在的，修改后的jsp是不会重新加载的。那么怎么办呢？我们可以直接卸载掉这jsp文件的类加载器，所以你应该想到了，每个jsp文件对应一个唯一的类加载器，当一个jsp文件修改了，就直接卸载这个jsp类加载器。重新创建类加载器，重新加载jsp文件。
具体如下图所示：
tomcat类加载器分的很多，各司其职，其实我在想，可能一开始tomcat也没有那么多，也许就多一个tomcat类加载器，后来多服务部署发现不同版本兼容性等问题，于是又新增类加载器去隔离，后来jsp出现又新增，慢慢发展到这么复杂的地步吧。
总结：
这一章呢，从分析源码入手，讲解了类加载的过程，以及双亲委派模型的实现，从源码角度去看，双亲委派机制还是很好理解的。最后介绍了tomcat如何打破双亲委派机制。类的加载流程很简单，双亲委派机制去加载不同类，但实现很复杂，需要考虑的问题太多，验证，解析等等都是非常复杂的流程。大体上算是了解了，但想理解，可能还是得去撸jvm源码了。
