面经读后感-双亲委派模型和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的类加载器比双亲委派多了很多规则……