类加载器原理

       类加载器源自于JAVA的applet需求，在JAVA中负责将字节码转换成内存中的Class对象放入方法区中，如果两个类的对象加载器不一致，那么这两个对象instanceof、equals方法必定返回false

       类加载器的结构如下图所示，采用了双亲委派模式，意思是除了顶层的Bootstrap以外，其他加载器都有自己的父加载器，当遇到加载Class的请求的时候先会判断内存中此类是否有加载过，如果没有被加载则将请求交给父加载器来处理，如果父加载器没有，则自己在尝试加载，这样有层次的好处是为了不会导致内存中有更多混乱的类重复加载

      

      

          双亲委派模型虽然好但并不是万能的，如果我们想要用自己的类加载器强制加载顶层的类，就会出现安全的异常，但一些应用场景如JNDI、Spring的IOC就会期望交给它们来管理类，因此出现破坏双亲委派模型，这次破坏仅仅是将加载顺序颠倒

          在生产环境的需求中，我们希望我们的项目无停顿一直对外服务，这里除了要减少FullGC的停顿时间以外，我们还有打版本的需求，比如今天我们需要向外网打某个模块的版本，一般情况下通过Ng前端的控制就可以让用户感受到无间歇的为他们服务，但是这样的的局限性和代价还是很大，我们期望最好是能够让这个模块单独重启，不影响其他模块的业务。这里JAVA为我们提供了JSR规范，现在业内使用比较多的是OSGI，OSGI把每个模块都拥有自己的类加载器，当需要替换某个模块的时候，就连同类姐在前一起替换掉