本文主要对上两篇文章进行总结，同时结合过去工作说一些感想
首先通过上两篇文章的讲解和代码实战，对JAVA类加载的双亲委派是有了进一步认识的；对所谓的类， 类加载都应该有新的认识，而这些都是可以自由发挥的。
其次，在工作中的确是经常遇到依赖问题、版本升级问题；比如业务依赖了rpc中间件，数据库中间件, 而这两个都依赖fastjson，但是是不同版本；还有比如经常有fastjson安全漏洞，要全员业务升级，比较糟糕的做法就是每个业务组，每个项目都人工一个一个依赖升级（我上一家公司就是）；…
经过上两篇文章和现公司的做法，思路即如下
- 原来的情况
- 假如中间加上一层
业务与中间件依赖之间有专门的一层，那么依赖冲突就可以依靠中间层去做类加载，去做缓存等，来避免多个业务的重复问题
比如中间层缓存了 fastjson 1.0; fastjson 2.0; fastjson 3.0; 这三个版本类，那么业务层取之即用就好，如果业务要强制，那么中间层修改强制就行。
而在阿里就有这么个pandora, 魔盒一样帮你做好这一切，具体说来只需要如下三个步骤
- 业务方自己的类加载器加载Pandora
- Pandora加载起来，用Pandora自己内部组件、类加载器去把各种rpc,db插件给加载缓存起来
- 最后业务方直接找Pandora要相关依赖就好了
所以有点像依赖转移一样，但本质还是对双亲委派或者说类加载的一种完美应用