easyui datagrid重新加载detailview异常_tomcat类加载机制了解一下
一、tomcat类加载器关系
tomcat类加载器设计结构如上图所示，上面三个Bootstrap加载器、Ext加载器、Application加载器是JVM加载器，下半部分的加载器才是tomcat自定义的加载器。
学习tomcat类加载器之前先回顾下之前写过的jvm类加载器的知识点。
· 类加载机制
类加载机制的本质是将经过虚拟机编译后的.class文件转化为二进制，并将二进制加载成Class对象的加载过程。
因此判断类是否完全相同，需要以下两个条件即：类的全路径名是否相同、加载类的类加载器是否为同一个，这两个条件决定类是否完全相同。
· 双亲委派机制
双亲委派机制的存在，保证类是安全的，他的存在保证了类的加载顺序会优先委派父类加载器进行加载，如果父类加载器没有加载才会有子类进行加载。比如在JVM类加载器的继承关系(从子到父)为Application ClassLoader—>Extension ClassLoader—>Bootstrap ClassLoader。因此当自己在代码内部中编写恶意java代码时，比如HashMap文件，如果路径名相同，则会委派给父类Bootstrap ClassLoader进行加载，发现在Bootstrap加载的lib目录下存在HashMap文件则加载应该由Bootstrap加载的HashMap文件。从而保证自己编写的恶意java代码不会替换应由Bootstrap加载的源文件。
· 打破双亲委派机制
由于虚拟机中的加载规则是按需加载的，即需要用到什么类的时候才会去加载那个类。并且在加载该类时用的是什么加载器，那么加载该类引用的类也需要用到对应的加载器，在java中的SPI机制，加载jdbc时由于Driver类不在rt.jar中因此不能被Bootstrap加载器进行加载，因此使用了线程上下文类加载器委派子类进行加载。所以打破了双亲委派机制，并且在tomcat类加载器中也存在打破双亲委派机制的情况。
二、tomcat类加载器
· Common ClassLoader
Common ClassLoader是tomcat最基本的类加载器，被此加载器加载的类即可以被tomcat所访问，也可以被应用war包中的程序所访问。
· Catalina ClassLoader
Catalina ClassLoader是tomcat私有的类加载器，被此加载器加载的类，只能被tomcat所访问。
· Shared ClassLoader
Shared ClassLoader是各个war包共享的类加载器，被此加载器加载的类，只能被应用war包中的程序所访问。
当tomcat中存在多个war包并同时使用了相同版本的jar包时，为了减少资源的浪费，可以使用该加载器，抽出这些相同版本的jar包，使用Shared ClassLoader加载一次被共享的jar即可，来代替每个war包中都需要加载的过程。
· WebApp ClassLoader
WebApp ClassLoader是多个war包的类加载器，即tomcat中的一个war包由一个WebApp ClassLoader加载。
Shared ClassLoader和WebApp ClassLoader的存在可以让共享的jar包由Shared ClassLoader加载，其余不一样或需要独立部署的由WebApp ClassLoader进行加载，达成共享与隔离的统一。
· JSP ClassLoader
JSP ClassLoader是一个jsp文件的类加载器，即tomcat中存在一个jsp就会new出一个JSP ClassLoader进行jsp文件的加载。
JSP ClassLoader是一个特殊的类加载器，他的特点也保证了jsp文件可以进行热部署，因为当对jsp文件进行修改，重新加载该jsp文件时，又会new出一个JSP ClassLoader来加载jsp文件，替换修改前的jsp文件(此时需要注意的是jsp文件的类的唯一性也变了，类的唯一性由类的全路径名+类加载器决定，此时的类加载器是重新new出来的所以和修改前的加载器是完全不一样的)。而Controller、service等文件的修改前和修改后是由相同的WebApp ClassLoader加载的，因此不能在这种情况下和jsp一样实现实现修改后的热部署。
· 源码中的加载器关系
private void initClassLoaders() {try {//common加载器，父类为null commonLoader = createClassLoader("common", null); if (commonLoader == null) {
commonLoader = this.getClass().getClassLoader(); }//catalina加载器，父类为commonLoader catalinaLoader = createClassLoader("server", commonLoader); //shared加载器，父类为commonLoader sharedLoader = createClassLoader("shared", commonLoader); } catch (Throwable t) {
handleThrowable(t); log.error("Class loader creation threw exception", t); System.exit(1); }
}但是创建common加载器时，传入的是null，如何判断common加载器的父类是ApplicationClassLoader呢。
跟到底层会发现获取系统类加载器为父类加载器，即AppClassLoader。其余源码的分析在类加载详解中有进行过分析，这里不再做详细阐述。
三、tomcat类加载流程
· Bootstrap
主要加载JVM启动所需要的类。
· System
主要加载tomcat启动的类，比如bootstrap.jar。位于bin/bootstrap.jar。
· Common
主要加载tomcat中常用的类，位于lib中。
· WebApp
主要加载应用的类文件，即位于WEB-INF/lib下的jar文件和WEB-INF/classes下的class文件。
四、tomcat类加载源码分析
public Class> loadClass(String name) throws ClassNotFoundException {return loadClass(name, false);}//重写了loadClass方法public Class> loadClass(String name, boolean resolve) throws ClassNotFoundException {synchronized (JreCompat.isGraalAvailable() ? this : getClassLoadingLock(name)) {if (log.isDebugEnabled())
log.debug("loadClass(" + name + ", " + resolve + ")"); Class> clazz = null; //校验程序是否启动，如果已启动抛出异常 checkStateForClassLoading(name); //校验当前对象缓存是否加载过该类 clazz = findLoadedClass0(name); //如果已经加载过该类 则直接返回 if (clazz != null) {if (log.isDebugEnabled())
log.debug(" Returning class from cache"); if (resolve)
resolveClass(clazz); return clazz; }//校验是否加载过该类，会调用native方法 clazz = JreCompat.isGraalAvailable() ? null : findLoadedClass(name); if (clazz != null) {if (log.isDebugEnabled())
log.debug(" Returning class from cache"); if (resolve)
resolveClass(clazz); return clazz; }
String resourceName = binaryNameToPath(name, false); ClassLoader javaseLoader = getJavaseClassLoader(); boolean tryLoadingFromJavaseLoader; try {//使用javaseLoader加载 // 即-使用ExtClassLoader/BootstrapClassLoader判断是否需要加载这个calss // 防止先被webAppClassLoader加载了脏的类 URL url; if (securityManager != null) {
PrivilegedAction dp = new PrivilegedJavaseGetResource(resourceName); url = AccessController.doPrivileged(dp); } else {
url = javaseLoader.getResource(resourceName); }
tryLoadingFromJavaseLoader = (url != null); } catch (Throwable t) {
ExceptionUtils.handleThrowable(t); tryLoadingFromJavaseLoader = true; }if (tryLoadingFromJavaseLoader) {try {
clazz = javaseLoader.loadClass(name); if (clazz != null) {if (resolve)
resolveClass(clazz); return clazz; }
} catch (ClassNotFoundException e) {
}
}//安全策略校验 if (securityManager != null) {int i = name.lastIndexOf('.'); if (i >= 0) {try {
securityManager.checkPackageAccess(name.substring(0, i)); } catch (SecurityException se) {
String error = sm.getString("webappClassLoader.restrictedPackage", name); log.info(error, se); throw new ClassNotFoundException(error, se); }
}
}//判断是否需要被WebAppClassLoader进行加载，是否设置了delegate boolean delegateLoad = delegate || filter(name, true); //委托给父类 CommonClassLoader加载 if (delegateLoad) {if (log.isDebugEnabled())
log.debug(" Delegating to parent classloader1 " + parent); try {
clazz = Class.forName(name, false, parent); if (clazz != null) {if (log.isDebugEnabled())
log.debug(" Loading class from parent"); if (resolve)//加载成功则返回 resolveClass(clazz); return clazz; }
} catch (ClassNotFoundException e) {
}
}//使用WebAppClassLoader进行加载 if (log.isDebugEnabled())
log.debug(" Searching local repositories"); try {
clazz = findClass(name); if (clazz != null) {if (log.isDebugEnabled())
log.debug(" Loading class from local repository"); if (resolve)
resolveClass(clazz); return clazz; }
} catch (ClassNotFoundException e) {
}//WebAppClassLoader加载失败，则委托WebAppClassLoader的父类进行加载 if (!delegateLoad) {if (log.isDebugEnabled())
log.debug(" Delegating to parent classloader at end: " + parent); try {
clazz = Class.forName(name, false, parent); if (clazz != null) {if (log.isDebugEnabled())
log.debug(" Loading class from parent"); if (resolve)
resolveClass(clazz); return clazz; }
} catch (ClassNotFoundException e) {// Ignore }
}
}//加载不到 抛出异常 throw new ClassNotFoundException(name);}上述源码分析中，tomcat的类加载步骤为(delegate设置为true的情况)：
(1)判断当前被加载的类对象是否存在缓存中，如果存在则直接返回该类。
(2)判断是否加载过该类，如果加载过则直接返回该类。
(3)委派jvm中的父类ExtClassLoader、BootStrapClassLoader是否加载过该类。
(4)委派tomcat中的父类CommonClassLoader是否加载过该类。
(5)当前WebAppClassLoader自己加载该类。
(6)如果类仍然没有加载成功，则抛出异常。
五、tomcat打破双亲委派加载机制
不论加载的delegate配置设置为true或者false，tomcat加载类的顺序都为先查询当前WebAppClassLoader类加载器是否加载过该类，而不是预先委托父类进行加载。
第二点是当delegate设置为false时，上述的第四步和第五步可能也会打破双亲委派，优先使用WebAppClassLoader加载器进行加载，加载不到才委托父类进行加载。