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，由它去裝載應用包，這樣我們就能對類裝載進行干涉，從而實現按需裝載類了。
具體內容請留意下一篇。