小喇叭，“请关注，欢迎转发，二次创作，有疑问请留言，谢谢”

背景：

最近团队中引入了插件化解决方案pf4j，为了能cover住此技术，需要我们理解它的工作原理，此框架中有自定义classLoader。很遗憾在接触此框架之前，我对于classLoader的认识也只停留在双亲委派模型。

由于本次引入此技术的项目非常重要，因此需要我们吃透pf4j，我看到 Parent Last ClassLoader

一些重要问题

双亲委派模型，是学习classLoader绕不开的，也很简单。

我们回忆下：如果一个类加载器收到了类的加载请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一层的类加载器都是如此，因此所有的加载请求，最终都应该传送到顶层的启动类加载器（Bootstrap ClassLoader），只有父加载器反馈自己无法完成这个请求时（也就是它的搜索范围没有找到需要的类）时，子加载器才会尝试自己去加载。

这个可能大家都知道，那我问几个问题？

1. 一个类能被一个加载器加载多次吗？
2. 一个类能被不同的加载器同时加载吗？
3. 为什么要采用双亲委派模型，这个模型有什么好处？有什么弊端？
4. 为什么要自己实现classLoader?Classloader是双亲委派模型，能破坏它吗？Parent Last ClassLoader是什么意思？
5. 加载的类，可以被卸载吗？

大家思考下，有些问题我不正面回答，我通过几个主要问题，试着带领大家去解答。

（1）如何打破双亲委派模型

双亲委派模型很好地解决了各个类加载器的基础类的统一问题（越基础的类由越上层的加载器加载），基础类之所以称为”基础”，是因为他们总是被用户代码调用，但是如果有一个场景，需要基础类调用用户的代码，那该怎么样？

比如Java中的JNDI服务，JNDI核心代码位于rt.jar中，按照双亲委派模型，它是Bootstrap顶层classLoader加载的。但是位于classPath下的JNDI的接口实现者，启动类加载器是不可能识别的。这很好理解，按照双亲委派模型，底层的classLoader能方便的拿到父亲加载的信息的，但是父亲确实没有办法取到孩子加载的信息，怎么解决？

为了解决这个问题,Java设计团队，引入了线程上下文（Thread Context ClassLoader）。

线程默认行为会继承父线程的classLoader,最初的线程的classLoader默认systemClassLoader（Application ClassLoader）。这样基本类，就可以通过线程上下文，加载到用户创建的类信息。

同时用户也可以实现自定义classLoader，比如pf4j实现的Parent Last ClassLoader，也就是先自己去加载，如果加载不到的话，在委托父加载器去加载。实现一个自定义加载器不难，难就难在，引入新的加载器后，对内存垃圾回收带来的挑战。

（2）classLoader除了能加载类之外，还有什么作用？

Java中，classLoader相当于命名空间，同样的全限定名对象，被不同的classLoader加载，jvm认为是不同的对象。

(3) classLoader加载的类，放在哪个区？方法区还是堆上？

这样问题，我查找了不少资料，下面的图是可信的，请参考。

（4）对象可以被卸载吗？

为啥我会对这个问题感兴趣。因为如果这个问题不弄清楚，自定义classLoader也只是一知半解，还有可能会出现内存泄漏等问题。

我们先看下，classLoader加载完类，实例化class对象，最终被实例化被执行的内存模型。

我们再看下方法区回收无用类信息的3个条件，注意必须都满足：

• 该类所有的实例都已经被回收，也就是JAVA堆中不存在，该类的任何实例。
• 加载该类的ClassLoader已经被回收。
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

通过上图以及方法区回收的条件。那么我们可以得出结论，自定义（或者自己新建的）classLoader加载的类，是可以回收的，但是3个条件必须都满足。

卸载之后，Class对象，以及方法区中的类信息将都会消失。