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