前言
隨著硬件性能的大大提高, 很多情況我們的應(yīng)用即使寫的簡(jiǎn)單粗暴些, 系統(tǒng)也可以可用的, 只是極端情況下會(huì)暴露出問題, 這也就是對(duì)于系統(tǒng)穩(wěn)定性追求的價(jià)值所在, 另一個(gè)我們充分利用資源, 不造成資源的浪費(fèi)也可以減少集群所需要的機(jī)器數(shù)量節(jié)約成本.
資源有限性場(chǎng)景
應(yīng)用存儲(chǔ)有限性
內(nèi)存是一種高速, 造價(jià)昂貴的存儲(chǔ)設(shè)備, 而磁盤速度較慢造價(jià)低廉. 內(nèi)存是通過電流來實(shí)現(xiàn)存儲(chǔ), 磁盤是通過磁記錄來實(shí)現(xiàn)存儲(chǔ). 所以電腦斷電后, 內(nèi)存中的數(shù)據(jù)會(huì)丟失, 而磁盤中的數(shù)據(jù)在不損壞的情況下可以長(zhǎng)久保留
內(nèi)存有限性
java 內(nèi)存模型里又有一些模型概念, 其中最常見的就是在 new Object() 的時(shí)候使用的堆內(nèi)存, 內(nèi)存本身是有限的, 堆內(nèi)存就更小一些, 所以我們?cè)谌粘＞幊讨行枰紤]堆內(nèi)存的有限性, 不是一個(gè)對(duì)象多大都能承載. 比如類似的代碼就有可能會(huì)造成 jvm 一直回收不了導(dǎo)致內(nèi)存溢出:
List?userNamedCodogList?=newArrayList<>();
while(response.hasNext())?{
userNamedCodogList.addAll(response.getUserList());
response?=?queryUserList();
}
這種從接口讀取用戶列表, 然后添加到 userlist 里, 如果查詢很多次, list 一直釋放不了, 系統(tǒng)就會(huì)掛掉了, 甚至簡(jiǎn)單如:
List?userNamedCodogList?=?userDao.selectList("name","codog");
如果結(jié)果集特別多也會(huì)掛掉
其實(shí)除了考慮堆內(nèi)存還得考慮方法棧等內(nèi)存模型, 但是一般經(jīng)過良好測(cè)試的正常寫代碼不會(huì)造成棧溢出的, 一般只有遞歸的調(diào)用容易發(fā)生這類問題, 但是這時(shí)候一般 CPU 也會(huì)先顯示出來異常了
磁盤有限性
相對(duì)于內(nèi)存, 磁盤確實(shí)大很多, 所以一般不怎么出問題, 但是在使用磁盤的時(shí)候要注意一些日積月累的問題, 比如一些程序臨時(shí)文件的定期及時(shí)清理等, 如 excel 新版本就會(huì)在內(nèi)存中保留一個(gè)窗口的數(shù)據(jù), 其他的都是在磁盤上的臨時(shí)文件
網(wǎng)絡(luò)帶寬有限性
這個(gè)主要考慮到接口的定義和使用, 比如定義一個(gè)拉取一段時(shí)間內(nèi)注冊(cè)的用戶的接口:
ListqueryUserByTimeRange(Range<LocalDateTime>?timeRange);
這就要考慮到用戶列表很多的時(shí)候, 網(wǎng)絡(luò)傳輸是不是會(huì)造成問題, 其實(shí)好的方式是改成分頁的接口
另外比如 Get 方法的請(qǐng)求參數(shù)不能過大, 不然就無法傳輸?shù)膯栴}, 這時(shí)候一開始就需要寫成 Post,,,,,
還有比如應(yīng)用程序上傳文件的服務(wù)器和應(yīng)用代碼的服務(wù)器需要隔離開, 不然會(huì)導(dǎo)致因?yàn)榇罅康娜松蟼鲌D片導(dǎo)致正常的應(yīng)用功能無法接收到用戶的接口請(qǐng)求, 對(duì)于這種一般的公司會(huì)提供專門的文件服務(wù)器用來承接文件, 使用 key 與應(yīng)用程序進(jìn)行溝通
CPU有限性
其實(shí)應(yīng)用程序很少是 CPU 機(jī)器密集型的, 所以 CPU 很少是瓶頸, 主要是需要注意比如設(shè)置線程池的時(shí)候不能設(shè)置的太大, 不然 CPU 會(huì)頻繁切換線程, 正事干的反而慢了
