fast-loader（一）起源

背景

攻城狮作为各类互联网企业在网络上攻城略地的战斗者，每时每刻都背负着巨量的开发需求，以及近乎无量的代码债务，为了码出质量，为了鄙视自私自利的物质社会，精神已实现超脱的同学们发明了乌托邦式的开源社区，把自己已经做好的优秀代码共享到网络中，从而造福全人类。
为优秀的他们点赞~~
为了保证代码质量，一般经过一段时间开发及沉淀后就会形成一个新版本封包推出，使用者无需关心代码实现逻辑就可以直接拿来用，极大的满足各类伸手党的欲望。
随着这个非常有觉悟的群体不断壮大，开发界于是就不断涌现出各类优秀的库，为it的前进直接就装上了火箭推进器。
而程序猿们开发过程不再整天沉浸在各类算法编写上面，可以直接从现成的库中选择合适的工具，于是作为应用层面的开发者们，算法和基础知识不再是限制他们的束缚，丰富的知识面（类库认知）能为他们插上飞翔的翅膀。
可是，工具太多太丰富也带来了一些问题，我这里举例几个看看大家是否有共鸣：

• 为了使用一个工具引入了一个类库，甚至这个类库中只需要用到一个类
• 一个应用程序包几十M，自己的代码仅占几百K
• 早期写个小程序几十M内存就跑起来了，现在随便都要256M

当然，随着技术发展硬件单价不断下降，能通过资源投入就能解决的问题都不是问题了，可真相真的是这样吗？

真相呢？

随着微服务不断在大大小小的企业落地，“无状态”服务的理念也逐步成为一种标配。
为什么无状态呢？

• 无状态代表服务无需存储状态数据，可以更加快速拉起和销毁
• 无状态服务关注自身计算能力，更容易横向扩容
• 无状态让微服务可以更加合理的“微”起来，而不至于一堆强耦合的服务强制堆积

还有吗？肯定还有，我就不一一列举了
微服务技术可以很好的和容器技术结合在一起，甚至可以说是天生一对，微服务关注于业务的“微”，而容器则提供标准环境以及进程级启动的“小”。
在无状态的微服务中

1. 服务本身无需存储状态信息，对内存的占用仅在计算过程
2. 服务自身功能单一内聚，代码量小

如此纯净的微服务在当前开发结果下，实际包会增大许多，同时运行内存也要求多了许多。
老铁，可还记得64M跑Java的年代。。。

怎么办？

我们为了代码质量和开发效率所以引入了一堆第三方库，这是导致问题的根源了，拿到为了区区内存就放弃引入类库，回到原始人阶段吗？
因噎废食，我想到了这个词，这并不是我们想要的。
实际上，我们使用第三方库时候，多数只是需要用到其中某些功能甚至某几个类，可以为包是整体加载的，导致了我们不需要用到的类也进入到我们的虚拟机中，膨胀了我们的内存占用，因此，或许按需加载可以解决我们这类问题？

梳理逻辑

我们都知道，JVM对类的操作是通过一系列的ClassLoader来实现的，由JVM的启动开始一直到我们的业务代码执行，缺少了ClassLoader都不行。

BootstrapClassLoader是负责装载Java核心类的，ExtClassLoader则是负责装载JVM外部类库，最后才到装载我们应用程序的AppClassLoader。
我们的程序有多少个包AppClassLoader就需要装多少个到内存，所以内存占用难以避免，为Java“吃内存”美名做了一番贡献。
如果我们要实现按需装载的话，就要对这个装载链进行重新设计，这也就是fast-loader的来源了。

我们不再让APPClassLoader接触到应用，作为中间人我们加入FastClassLoader，由它去装载应用包，这样我们就能对类装载进行干涉，从而实现按需装载类了。
具体内容请留意下一篇。