面经读后感-双亲委派模型和ClassLoader部分源码阅读
发现很多看似艰深的面试题 原来在以前看不懂的书里有讲解
代码写多了，以前看不懂的东西慢慢的能理解了
原题：谈谈双亲委派模型，以及怎么被破坏的
扩展：能否自己写一个java.lang.System
双亲委派模型：
每个类加载器应该有一个成员变量作为父加载器，在加载时先让父加载器加载，父加载器抛出异常再调用本体的findClass()方法。
它是Java设计者推荐的实现，直接体现在抽象类ClassLoader的loadClass()方法里。
好处在于符合Java语言的设计，例如自行编写的java.lang.Object()类必然会被BootStrap加载器加载，并且会报错“找不到方法”。
（即使自己编写类加载器尝试加载，也会由于包名开头是java.而抛出SecurityException，体现在抽象类ClassLoader的preDefineClass()方法）
重点在于父加载器是成员变量而不是父类，采用的是组合而不是继承。
被破坏：
第一次是由于存在一些老代码。JDK1.2前，自定义类加载器只能覆写loadClass()方法，当时没有这个模型，自然也没有父类优先的逻辑了。
在实现双亲委派时，为了兼容老代码，JDK的做法是添加一个findClass()方法，并且在loadClass()方法中调用，并且提倡用户覆写findClass()方法。
（问题，如果不需要兼容老代码可以怎么做呢？可以直接修改loadClassInternal()方法吗，这么做会有什么后果呢？）
第二次是由于模型缺陷（需求变更），由父加载器加载的代码需要调用子加载器的代码。
书中给的例子是JNDI，JNDI作为Java标准服务，代码在rt.jar中，并且由启动类加载器加载。但是它需要调用应用程序ClassPath的代码。
为了解决问题，Java团队只能引入线程上下文加载器，可以在创建线程时设一个类加载器，就可以逆向请求子加载器了。
第三次是技术迭代，OGSi的类加载器比双亲委派多了很多规则……