背景

攻城獅作為各類(lèi)互聯(lián)網(wǎng)企業(yè)在網(wǎng)絡(luò)上攻城略地的戰(zhàn)斗者，每時(shí)每刻都背負(fù)著巨量的開(kāi)發(fā)需求，以及近乎無(wú)量的代碼債務(wù)，為了碼出質(zhì)量，為了鄙視自私自利的物質(zhì)社會(huì)，精神已實(shí)現(xiàn)超脫的同學(xué)們發(fā)明了烏托邦式的開(kāi)源社區(qū)，把自己已經(jīng)做好的優(yōu)秀代碼共享到網(wǎng)絡(luò)中，從而造福全人類(lèi)。
為優(yōu)秀的他們點(diǎn)贊~~
為了保證代碼質(zhì)量，一般經(jīng)過(guò)一段時(shí)間開(kāi)發(fā)及沉淀后就會(huì)形成一個(gè)新版本封包推出，使用者無(wú)需關(guān)心代碼實(shí)現(xiàn)邏輯就可以直接拿來(lái)用，極大的滿(mǎn)足各類(lèi)伸手黨的欲望。
隨著這個(gè)非常有覺(jué)悟的群體不斷壯大，開(kāi)發(fā)界于是就不斷涌現(xiàn)出各類(lèi)優(yōu)秀的庫(kù)，為it的前進(jìn)直接就裝上了火箭推進(jìn)器。
而程序猿們開(kāi)發(fā)過(guò)程不再整天沉浸在各類(lèi)算法編寫(xiě)上面，可以直接從現(xiàn)成的庫(kù)中選擇合適的工具，于是作為應(yīng)用層面的開(kāi)發(fā)者們，算法和基礎(chǔ)知識(shí)不再是限制他們的束縛，豐富的知識(shí)面（類(lèi)庫(kù)認(rèn)知）能為他們插上飛翔的翅膀。
可是，工具太多太豐富也帶來(lái)了一些問(wèn)題，我這里舉例幾個(gè)看看大家是否有共鳴：

創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿(mǎn)足客戶(hù)于互聯(lián)網(wǎng)時(shí)代的綠春網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

• 為了使用一個(gè)工具引入了一個(gè)類(lèi)庫(kù)，甚至這個(gè)類(lèi)庫(kù)中只需要用到一個(gè)類(lèi)
• 一個(gè)應(yīng)用程序包幾十M，自己的代碼僅占幾百K
• 早期寫(xiě)個(gè)小程序幾十M內(nèi)存就跑起來(lái)了，現(xiàn)在隨便都要256M

當(dāng)然，隨著技術(shù)發(fā)展硬件單價(jià)不斷下降，能通過(guò)資源投入就能解決的問(wèn)題都不是問(wèn)題了，可真相真的是這樣嗎？

真相呢？

隨著微服務(wù)不斷在大大小小的企業(yè)落地，“無(wú)狀態(tài)”服務(wù)的理念也逐步成為一種標(biāo)配。
為什么無(wú)狀態(tài)呢？

• 無(wú)狀態(tài)代表服務(wù)無(wú)需存儲(chǔ)狀態(tài)數(shù)據(jù)，可以更加快速拉起和銷(xiāo)毀
• 無(wú)狀態(tài)服務(wù)關(guān)注自身計(jì)算能力，更容易橫向擴(kuò)容
• 無(wú)狀態(tài)讓微服務(wù)可以更加合理的“微”起來(lái)，而不至于一堆強(qiáng)耦合的服務(wù)強(qiáng)制堆積

還有嗎？肯定還有，我就不一一列舉了
微服務(wù)技術(shù)可以很好的和容器技術(shù)結(jié)合在一起，甚至可以說(shuō)是天生一對(duì)，微服務(wù)關(guān)注于業(yè)務(wù)的“微”，而容器則提供標(biāo)準(zhǔn)環(huán)境以及進(jìn)程級(jí)啟動(dòng)的“小”。
在無(wú)狀態(tài)的微服務(wù)中

1. 服務(wù)本身無(wú)需存儲(chǔ)狀態(tài)信息，對(duì)內(nèi)存的占用僅在計(jì)算過(guò)程
2. 服務(wù)自身功能單一內(nèi)聚，代碼量小

如此純凈的微服務(wù)在當(dāng)前開(kāi)發(fā)結(jié)果下，實(shí)際包會(huì)增大許多，同時(shí)運(yùn)行內(nèi)存也要求多了許多。
老鐵，可還記得64M跑Java的年代。。。

怎么辦？

我們?yōu)榱舜a質(zhì)量和開(kāi)發(fā)效率所以引入了一堆第三方庫(kù)，這是導(dǎo)致問(wèn)題的根源了，拿到為了區(qū)區(qū)內(nèi)存就放棄引入類(lèi)庫(kù)，回到原始人階段嗎？
因噎廢食，我想到了這個(gè)詞，這并不是我們想要的。
實(shí)際上，我們使用第三方庫(kù)時(shí)候，多數(shù)只是需要用到其中某些功能甚至某幾個(gè)類(lèi)，可以為包是整體加載的，導(dǎo)致了我們不需要用到的類(lèi)也進(jìn)入到我們的虛擬機(jī)中，膨脹了我們的內(nèi)存占用，因此，或許按需加載可以解決我們這類(lèi)問(wèn)題？

梳理邏輯

我們都知道，JVM對(duì)類(lèi)的操作是通過(guò)一系列的ClassLoader來(lái)實(shí)現(xiàn)的，由JVM的啟動(dòng)開(kāi)始一直到我們的業(yè)務(wù)代碼執(zhí)行，缺少了ClassLoader都不行。

BootstrapClassLoader是負(fù)責(zé)裝載Java核心類(lèi)的，ExtClassLoader則是負(fù)責(zé)裝載JVM外部類(lèi)庫(kù)，最后才到裝載我們應(yīng)用程序的AppClassLoader。
我們的程序有多少個(gè)包AppClassLoader就需要裝多少個(gè)到內(nèi)存，所以?xún)?nèi)存占用難以避免，為Java“吃?xún)?nèi)存”美名做了一番貢獻(xiàn)。
如果我們要實(shí)現(xiàn)按需裝載的話(huà)，就要對(duì)這個(gè)裝載鏈進(jìn)行重新設(shè)計(jì)，這也就是fast-loader的來(lái)源了。

我們不再讓APPClassLoader接觸到應(yīng)用，作為中間人我們加入FastClassLoader，由它去裝載應(yīng)用包，這樣我們就能對(duì)類(lèi)裝載進(jìn)行干涉，從而實(shí)現(xiàn)按需裝載類(lèi)了。
具體內(nèi)容請(qǐng)留意下一篇。