java疫苗之殇？关于java类加载器的一些思考

港控/mmm° 2022-05-18 04:07 260阅读 0赞

近日疫苗之殇闹得沸沸扬扬，究其原因是因为长春长生生物公司随意改动制药工艺，不管注射了这种疫苗会不会对身体有太大的影响，但是这严重影响了国民对医药的信任，可能导致国民不愿注射疫苗，对传染病防控带来极大打击，对公众的生命安全带来极大的风险。

对于此事，java王国却在偷乐，他们早就有一个完善的方案来避免这种事情发生。从上到下，java王国政府都建有大大小小的药厂，它们管这些药厂叫做ClassLoader（类加载器），其中全国最大、最权威的药厂叫做Bootstrap ClassLoader，次大一点的药厂叫做Extension ClassLoader，这两个药厂管理着java王国里面对公众生命安全最重要、最基本的药物。当然了java王国贵为编程语言第一大国，仅靠这两家厂生产和管理这些药物是远远不够的，对于那些不那么重要的药，不会对公众健康造成很大影响的药物，java王国允许他们建造自己的ClassLoader，这些ClassLoader叫做Application ClassLoader，那么这一小部分人就可以使用这个药房的药了。以上的药厂都属于中央或者地方政府的制药工厂。然后接下来，对于那些实力强劲的企业如java第一集团apache旗下子公司tomcat，他们完全有能力自己制药，自定义classLoader，并且能获得举国上下的认可和使用。  
![这里写图片描述][70]

他们实行了什么政策可以保证疫苗的安全呢？他们出台了“双亲委托模型”管理办法，要求低一级的药厂或者药房在制造药物的时候，必须交由它的上一级审核和制造，如果上一级认为这种药物不会危害生命，完全可以交由下级药厂制造，那么就会把这个申请打回下一级。

举个例子，假如现在我想要一种叫做Object的药，我会先到Application去买药，而Application不管三七二十一，直接请求他的上级Extention ，而Extention ClassLoader也是同样请求Bootstrap ，Bootstrap 发现这种药是生命的必需药物，当然应该由自己生产，于是就把Object药物再逐层递交到我手上。请求链是这样的：Application–>Extention–>Bootstrap  
这样做有什么用呢？可以防止一些不法分子生产危害系统的药物，譬如有些不怀好意的人仿制了Object药，并且这种药具有破坏性，但是系统必须保证它使用的是Bootstrap 制造的，否则王国最基本的行为都无法保证了。

java王国做了这么多事，无非就是想保证一个命名空间。如何确定一个类的命名空间呢？有一个办法：加载它的类加载器，以及委托这个类加载器的子类加载器构成一个命名空间。创造命名空间主要是为了隔离不同命名空间的类之间的互相影响。体现这点的一个例子就是Tomcat的类加载器：  
![这里写图片描述][70 1]  
tomcat的类加载自己实现了Common、Catalina、Shared、WebApp等类加载器，主要是为了方便管理jar包。如放在tomcat的common文件夹下的jar包由Common ClassLoader加载，这会有什么效果呢？这个tomcat下的每一个应用都可以使用common里面的类了。而放在web app下的lib下的jar包，由于命名空间只是webApp+jasper，因此仅限这个web app去访问这个类。  
当然凡事也有例外，为什么这么说呢。有时候有些大药厂忙不过来，他们只会会定标准，让下面的药厂去实现，如JDBC。这些JDBC的标准接口就会由Bootstrap去加载，其命名空间是Bootstrap，而具体的实现类可能由Application去加载（命名空间为Application），那么Bootstrap就无法找到JDBC的具体实现了。为此，java王国开辟了特别的通道：线程上下文的ClassLoader：Thread.currentThread().getContextClassLoader()。线程会借此拿到当前线程上下文的ClassLoader去加载具体的JDBC的实现。  
（完）

**题外话**：  
最近在读spring的源码，发现一个方法ClassUtils\#getDefaultClassLoader，是一个获取类加载器的方法，这个方法写得挺有意思，引起了对类加载器的一些回忆。于是就有了这篇文章。  
![这里写图片描述][70 2]  
读过周志明的<<深入了解java虚拟机>>的（相信这是很多人接触JVM的第一本读物吧）会发现这其实就是里面提到的双亲委托模型的第二次被破坏，它是由这个模型本身的缺陷所导致的。原文的内容是：  
*双亲委派模型的第二次“被破坏”是这个模型自身的缺陷所导致的，双亲委派模型很好地解决了各个类加载器的基础类统一问题(越基础的类由越上层的加载器进行加载)，基础类之所以被称为“基础”，是因为它们总是作为被调用代码调用的API。但是，如果基础类又要调用用户的代码，那该怎么办呢。*

[70]: /images/20220518/01c0acddb5a9481a8f09648e7255b936.png
[70 1]: /images/20220518/48d9e0a3011b4c16b7b346da536686ea.png
[70 2]: /images/20220518/1223e47d91b947f1ae0257031539843f.png