URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();  for (int i = 0; i < urls.length; i++) {      System.out.println(urls[i].toExternalForm());  }

System.out.println(System.getProperty("sun.boot.class.path"));

   public Launcher() {        Launcher.ExtClassLoader var1;        try {            var1 = Launcher.ExtClassLoader.getExtClassLoader();        } catch (IOException var10) {            throw new InternalError("Could not create extension class loader", var10);        }        try {　　　　　　　 //var1作为appclassload的父类            this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);        } catch (IOException var9) {            throw new InternalError("Could not create application class loader", var9);        }　　　　　//launcher的加载器设成appclassload        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{
　　　　　　　　　　　　.......　　                }            } else {                var3 = new SecurityManager();            }            if(var3 == null) {                throw new InternalError("Could not create SecurityManager: " + var2);            }            System.setSecurityManager(var3);        }    }

常见加载器类错误分析

ClassNotFoundException　　 

这个异常通常发生在显式加载类的时候，显式加载一个类通常有如下方式：

1. 通过类Class中的forName()方法。
2. 通过类 ClassLoader 中的 loadClass()方法。
3. 通过类 ClassLoader 中的 findSystemClass()方法。

出现这类错误就是当JVM要加载指定文件的字节码到内存时，并没有找到这个文件对应的字节码，也就是这个文件并不存在。解决的办法就是检査在当前的classpath目录下有没有指定的文件存在。如果不知道当前的classpath路径,就可以通过如下命令来获取：this .getClass().getClassLoader().getResource ("").toString()

NoClassDefFoundError

这个异常通常发生在隐式加载类的时候，在JVM的规范中描述了出现NoClassDefFoundError可能的情况就是使用new关键字、属性引用某个类、继承个接口或类，以及方法的某个参数中引用了某个类，这时会触发JVM隐式加载这些类时发现这些类不存在的异常。解决这个错误的办法就是确保每个类引用的类都在当前的classpath路径下面。

UnsatisfiedLinkError

这个异常倒不是很常见，但是出错的话，通常是在JVM启动的时候,如果一不小心将在JVM中的某个lib删除了,可能就会报这个错误了。这个错误通常是在解析native标识的方法时JVM找不到对应的本机库文件时出现。

public class NoLibException {      public native void nativeMethod();          static {              System.loadLibrary("NoLib");          }          public static void main(String[] args) {              new NoLibException().nativeMethod();          }  }  

ExceptionInInitializerError

这个错误在JVM规范中是这样定义的：

• 如果Java虚拟机试图创建类ExceptionlnInitializerError的新实例,但是因为出现Out-Of-Memory-Error而无法创建新实倒，那么就抛出OutOfMemoryError对象作为替代。
• 如果初始化器抛出一些Exception，而且Exception类不是Error或者它的某个子类，那么就会创建ExceptionlnlnitializeiError类的一个新实例，并用Exception作为参数，用这个实例代替Exception。

Tomcat的ClassLoad分析

 创建一个简单的Web应用,里面有一个HelloWorldServlet,然后在这个Servlet中打印加载它的ClassLoader,代码如下：

public class HelloWorldServlet extends HttpServlet {         public void doGet(HttpServletRequest request, HttpServletResponse response)              throws ServletException, IOException {           ClassLoader loader = this.getClass().getClassLoader();          while(loader != null) {              out.write(loader.getClass().getName()+"");              loader = loader.getParent();          }       }   }

将这个应用通过<context/>方式配置在server.xml中，代码如下:

注意，不要将这个应用直接放在Tomcat的webapps目录下，因为直接放在webapps目录下，Tomcat使用的ClassLoader会不一样。
上面这段代码打印出来的结果如下：

Tomcat容器类的加载

下面看看Tomcat是在什么时候创建这些ClassLoader的，首先看看StandardClassLoader的创建过程。
StandardClassLoader 是在 Bootstrap 类的 initClassLoaders 方法中创建的，Bootstrap 调用 ClassLoaderFactory 的 createClassLoader()方法创建 StandardClassLoader 对象。如果没有指定 StandardClassLoader 类的父 ClassLoader,就默认设置 getSystemClassLoader()方法返回的ClassLoader 作为其父类，getSystemClassLoader()返回的 ClassLoader 通常就是 AppClassLoader。 
如果StandardClassLoader创建成功，将设置到Bootstrap的catalinaLoader属性作为整个 Tomcat 的根 ClassLoader。接下来 Tomcat 将以StandardClassLoader 来加载 org.apache.catalina.startup.Catalina 类并创建对象，最终也将 StandardClassLoader 设置到 Catalina 的parentClassLoader属性中。后面整个Tomcat容器的加载 ClassLoader 都将是StandardClassLoader 。
ps：我们前面说Tomcat容器的加载ClassLoader是StandardClassLoader，但是如果你调用Tomcat中任何一个类，如StandardContext类，通过 getClass().getClassLoader()方法返回的 ClassLoader 并不是 StandardClassLoader，而是AppClassLoader,为什么呢？原因是StandardClassLoader虽然是加载 StandardContext的类，但是可以看StandardClassLoader的实现方法可以发现StandardClassLoader只是一个代理类，并没有覆盖ClassLoader的loadClass()方法，StandardClassLoader仍然沿用委托加载器，它首先会让父加载器来加载，所以真正加载类仍然是是通过其父类AppclassLoader来完成的，加载Tomcat容器本身仍然是AppclassLoader。但是如果Tomcat的ClassPath没有被设置，那么AppClassLoader就将加载不到Tomcat容器的类，这时就要通过StandardClassLoader来加载了。其实不管是StandardClassLosder还是AppClassLoader加载，都没有任何影响；因为它们的加载规则一模—样，唯一不同的就是加载的路径不同。

Tomcat应用类的加载

其实我们真正关心的不是Tomcat容器本身是谁加载的，而是我们的应用是怎么加载的，也就是一个Web应用需要Tomcat执行时，这应用中的类是通过什么规则加载起来的？
我们知道，一个应用在Tomcat中由一个StandardContext表示.由 StandardContext来解释Web应用的web.xml配置文件实例化所有的Servlet。Servlet的calss是由<servlet-class>来指定的，所以可想而知，每个Servlet类的加载肯定是通过显式加载方法加载到Tomcat容器中的。那么Servlet是如何被加载的呢？先看看StandardContext类的startInternal()方法，在StandardContext初始化时將会检査loader属性是否存在，不存在就将创建它。看如下代码：

if (getLoader() == null)[ WebappLaader webappLoader = new WebappLaader (getParentClassLoader()); webappLoader.setDelegate(getDelegate()); setLoader(webappLoader); } 

这段代码清楚地表示将创建WebappLoader对象，而WebappLoader对象将创建WebappClassLoader 作为其 ClassLoader。再翻阅 StandardWrapper 类的 loadServlet()方法可以发现，所有的Servlet都是InstanceManager实例化的，那么InstanceManager类使用的ClassLoader 是不是 WebappClassLoader 呢？
InstanceManager 对象的 ClassLoader也获取 StandardContext 的 Loader 中的ClassLoader，也就是前面设置的 WebappClassLoader,所以 Servlet 的 ClassLoader 是WebappClassLoader.WebappClassLoader 不像 StandardClassLoader 那么简单，它覆盖了父类的 loadClass 方法，使用自己的加载机制，这个加载机制有点复杂，大体分为以下几个步骤：

1. 首先检查在WebappClassLoader中是否已经加载过了，如果请求的类以前是被WebappClassLoader 加载的，那么肯定在 WebappClassLoader的缓存容器 resourceEntries 中。
2. 如果不在WebappClassLoader的resourceEntries中，则继续检查在JVM虚拟机中是否已经加载过，也就是调用ClassLoader的findLoadedClass方法。
3. 如果在前两个缓存中都没有，则先调用SystemClassLoader加载请求的类，SystemClassLoader在这里是AppClassLoader,也就是在当前的JVM的ClassPath路径下査找请求的类。
4. 检查请求的类是否在packageTriggers定义的包名下，如果在这个设置的包目录下(即webapps目录下)，则将通过StandardClassLoader类来加载。
5. 如果仍然没有找到，将由WebappClassLoader来加栽，WebappClassLoader将会在这个应用的WEB-INF/classes目录下查找请求的类文件的字节码。找到后将创建一个ResourceEntry对象保存这个类的元信息，并把它保存在WebappClassLoader的resourceEntries容器中便于下次查找。接着将调用defineClass方法生成请求类的Class对象并返回给InstanceManager来创建实例。

从上面的分析来看，Tomcat仍然沿用了 JVM的类加载规范，也就是委托式加载，保证核心类通过AppClassLoader来加载。但是Tomcat会优先检查WebappClassLoader己经加载的缓存，而不是JVM的findLoadedClass缓存，这一点需要注意。这也说明了如果你将一个Web应用直接放到webapp目录下，那么Tomcat就通过StandardClassLoader 直接加载，而不是通过 WebappClassLoader 来加载。

实现类的热部署

什么是类的热部署

所谓热部署，就是在应用正在运行的时候升级软件，不需要重新启用应用。

对于Java应用程序来说，热部署就是运行时更新Java类文件。在基于Java的应用服务器实现热部署的过程中，类装入器扮演着重要的角色。大多数基于Java的应用服务器，包括EJB服务器和Servlet容器，都支持热部署。

如何实现热部署

我们知道，JVM在加载类之前会检査请求的类是否已经被加载过来，也就是要调用flndLoadedClass()方法查看是否能够返回类实例。如果类已经加载过来，再调用loadClass()将会导致类冲突。

但是JVM判断一个类是否是同一个类会有两个条件。一是看这个类的完整类名是否一样，这个类名包括类所在的包名。 二是看加载这个类的ClassLoader是否是同一个(既是是同一个ClassLoader类的两个实例，加载同一个类也会不一样)。

所以要实现类的热部署可以创建不同的ClassLoader的实例对象，然后通过这个不同的实例对象来加载同名的类， 

ps：

类装入器不能重新装入一个已经装入的类，但只要使用一个新的类装入器实例，就可以将类再次装入一个正在运行的应用程序。
重复加载一个类会抛出java.lang.LinkageError，即用同一个ClassLoader的实例对象加载两次同一个类名。
使用不同的Classloader实例加载同一个类，会不会导致JVM的PermGen区无限增大？
答案是否定的，因为我们的Classloader对象也和其他对象一样，当没有对象再引用它以后，也会被JVM回收，但是需要注意的一点是，被这个Classloader加载的类的字节码会保存在JVM的PermGen区，这个数据一般只是在执行Full GC时才会被回收的，所以如果在你的应用中都是大量的动态类加载，FullGC又不是太频繁，也要注意PermGen区的大小，防止内存溢出。

应不应该动态加载类

我想大家都知道用Java有一个痛处，就是修改一个类，必须要重启一遍，很费时，于是就想能不能来个动态类的加载而不需要重启JVM,如果你了解JVM的工作机制，就应该放弃这样的念头。
Java的优势正是基于共享对象的机制，达到信息的髙度共享，也就是通过保存并持有对象的状态而省去类信息的重复创建和回收。我们知道对象一旦被创建，这个对象就可以被人持有和利用。
假如，我只是说假如，如我们能够动态加载一个对象进入JVM,但是如何做到JVM中对象的平滑过渡？几乎不可能！虽然在JVM中对象只有一份，在理论上可以直接替换这个对象，然后更新Java栈中所有对原对象的引用关系。看起来好像对象可以被替换了，但是这仍然不可行，因为它违反了 JVM的设计原则，对象的引用关系只有对象的创建者持有和使用，JVM不可以干预对象的引用关系，因为JVM并不知道对象是怎么被使用的，这就涉及JVM并不知道对象的运行时类型而只知道编译时类型。
假如一个对象的属性结构被修改，但是在运行时其他对象可能仍然引用该属性。虽然完全的无障碍的替换是不现实的，但是如果你非要那样做，也还是有一些“旁门左道”的。前面的分析造成不能动态提供类对象的关键是，对象的状态被保存了，并且被其他对象引用了，一个简单的解决办法就是不保存对象的状态，对象被创建使用后就被释放掉，下次修改后，对象也就是新的了。
这种方式是不是就很好呢？这就是JSP,它难道不是可以动态加载类吗？修改了jsp不用重启。