背景
攻城狮作为各类互联网企业在网络上攻城略地的战斗者,每时每刻都背负着<强>巨量强的开发需求,以及近乎<强>无量强的代码债务,为了码出质量,为了鄙视自私自利的物质社会、精神已实现超脱的同学们发明了乌托邦式的开源社区,把自己已经做好的优秀代码共享到网络中,从而造福全人类。
为优秀的他们点赞~ ~
为了保证代码质量,一般经过一段时间开发及沉淀后就会形成一个新版本封包推出,使用者无需关心代码实现逻辑就可以直接拿来用,极大的满足各类伸手党的欲望。
随着这个非常有觉悟的群体不断壮大,开发界于是就不断涌现出各类优秀的库,为它的前进直接就装上了火箭推进器。
而程序猿们开发过程不再整天沉浸在各类算法编写上面,可以直接从现成的库中选择合适的工具,于是作为应用层面的开发者们,算法和基础知识不再是限制他们的束缚,丰富的知识面(类库认知)能为他们插上飞翔的翅膀。
可是,工具太多太丰富也带来了一些问题,我这里举例几个看看大家是否有共鸣:
-
<李>为了使用一个工具引入了一个类库,甚至这个类库中只需要用到一个类李
<李>一个应用程序包几十米,自己的代码仅占几百K
<李>早期写个小程序几十米内存就跑起来了,现在随便都要256李
当然,随着技术发展硬件单价不断下降,能通过资源投入就能解决的问题都不是问题了,可真相真的是这样吗?
真相呢?
随着微服务不断在大大小小的企业落地,“无状态”服务的理念也逐步成为一种标配。
为什么无状态呢?
-
<李>无状态代表服务无需存储状态数据,可以更加快速拉起和销毁李
<李>无状态服务关注自身计算能力,更容易横向扩容李
<李>无状态让微服务可以更加合理的“微”起来,而不至于一堆强耦合的服务强制堆积李
还有吗?肯定还有,我就不一一列举了
微服务技术可以很好的和容器技术结合在一起,甚至可以说是天生一,对微服务关注于业务的“微”,而容器则提供标准环境以及进程级启动的“小”。
在无状态的微服务中
-
<李>服务本身无需存储状态信息,对内存的占用仅在计算过程李
<李>服务自身功能单一内聚,代码量小李
如此纯净的微服务在当前开发结果下,实际包会增大许多,同时运行内存也要求多了许多。
老铁,可还记得64米跑Java的年代…
怎么办?
我们为了代码质量和开发效率所以引入了一堆第三方库,这是导致问题的根源了,拿到为了区区内存就放弃引入类库,回到原始人阶段吗?
<强>因噎废食强,我想到了这个词,这并不是我们想要的。
实际上,我们使用第三方库时候,多数只是需要用到其中某些功能甚至某几个类,可以为包是整体加载的,导致了我们不需要用到的类也进入到我们的虚拟机中,膨胀了我们的内存占用,因此,或许按需加载可以解决我们这类问题?
梳理逻辑
我们都知道,JVM对类的操作是通过一系列的类加载器来实现的,由JVM的启动开始一直到我们的业务代码执行,缺少了类加载器都不行。
fast-loader(一)起源
