|
你是否有過這樣的經(jīng)歷，跑得好好的Java進程，突然就癱瘓了。過于依賴Java虛擬機導致我們對問題無從下手，問題反復出現(xiàn)影響開發(fā)效率。其實，多數(shù)Java進程癱瘓的原因可以從java虛擬機層面找到原因，本文列舉出導致Java進程癱瘓的一些共性原因，供大家交流和學習。
一、內(nèi)存回收一直是java的痛點
用Java無法做出類似Redis這樣的產(chǎn)品。java的內(nèi)存回收機制使我們在編寫代碼時不需要關(guān)注對象的回收，同時加大了內(nèi)存回收的消耗，標記復制需要做內(nèi)存拷貝，標記清除算法則需要stop the world。所以我們在使用緩存的時候，量稍微大一些就需要借助類似Redis這樣的中間件幫我們處理了。作為Javaer，我們享受了自動內(nèi)存回收的安逸，同時也需要多了解下內(nèi)存優(yōu)化的方法。
二、為什么fgc停不下來了
1.什么情況下會gc
為了了解我們的系統(tǒng)為什么會不停fgc，我們需要先了解一下系統(tǒng)什么情況下會gc。在jvm層面，當我們new一個對象的時候，jvm會先在堆區(qū)分配對象需要的內(nèi)存，這個時候如果內(nèi)存不夠的話，就需要gc了，gc的返回結(jié)果就是對象的空間地址。jvm會先進行ygc，也就是我們通常說的標記復制，如果ygc之后依然申請不到空間，就會進行fgc了。同理，如果fgc之后依然沒有足夠的空間，就會循環(huán)的進行fgc，直到申請到足夠的空間。
2.導致不停的fgc的原因
如上文所講，fgc有可能發(fā)生在你的每一行代碼。如果fgc之后依然沒有足夠的空間，就會不停的fgc，直到申請到足夠的空間。同時JVM會限制在拋出OutOfMemory錯誤之前在GC中花費的VM時間的比例。系統(tǒng)頻繁FGC大致有五種情況：
內(nèi)存泄漏
請求處理變慢導致同時申請內(nèi)存的線程太多
metaspace 耗盡
常量池將堆區(qū)占滿
堆外內(nèi)存耗盡
1w，正常情況下處理一個請求的時間是1ms，那同一時刻并行的請求數(shù)量僅為10。如果性能發(fā)生抖動，每個請求處理的時間增加到100ms，那同一時刻并行的請求數(shù)量就會增加到100個。每個線程在處理請求的時候都會new一些對象出來，長時間存活的線程會造成類似內(nèi)存泄漏的效果，將系統(tǒng)的內(nèi)存耗盡。同時fgc也會加劇系統(tǒng)性能的開銷，使系統(tǒng)變得更慢，產(chǎn)生雪崩。
三、如何讓系統(tǒng)fgc之后仍然能活下來
1.杜絕內(nèi)存泄漏
內(nèi)存泄漏造成系統(tǒng)癱瘓的頻率很高，有些系統(tǒng)定時從數(shù)據(jù)庫拉取配置信息緩存到集合中，但是set不小心寫成了list，最終在新增元素的時候內(nèi)存溢出了。養(yǎng)成良好的編程習慣，多關(guān)注些細節(jié)，就能避免很多未知的問題。
2.并發(fā)限制：防止系統(tǒng)被撐死
每臺服務器都有并行處理請求的上限，不管請求處理的多快，超過上限之后就會被撐死，對高并發(fā)的請求做好并發(fā)數(shù)限制是保持系統(tǒng)穩(wěn)定的必要條件。需要注意的是，有一些系統(tǒng)在拒絕過多的請求時，也會做一些降級邏輯，降級邏輯也是有性能開銷的，同樣需要做并發(fā)限制，如果降級的請求超過并發(fā)限制，將不進行降級邏輯直接拋出異常。我們可使用的限流組件有很多，推薦我們阿里自研的Sentinel 和 Netflix開源的Hystrix。
3.自適應限流：防止系統(tǒng)被摸死
我們需要自適應限流有兩個原因：
a. 每臺服務器所處的環(huán)境是不一樣的
有些服務器和離線計算的vm混部在一起，有些部署在實體機，有些部署在新老型號的機器上，每臺服務器能承受的qps并不完全一樣。統(tǒng)一配置分布式系統(tǒng)中每臺服務器限流閥值，要么發(fā)揮不出每臺服務器應有的作用，要么在高qps的情況下一些比較慢的服務器宕機，所以用服務器作為限流粒度是最合適的。
b.設置了正確的限流閥值，也可能被摸死
當單機承受的QPS 6~20倍于限流的流量時，拒絕一次請求的開銷就無法忽略不記了。譬如春晚活動有些系統(tǒng)設置了正確的限流也被6~20倍于限流的流量沖垮。這種死法稱為被摸死。應對這種情況，我們可以做的是在受到6~20倍的大流量時，動態(tài)減少限流的閥值。比如系統(tǒng)最開始接受1000qps，5000的拒絕流量過來會把系統(tǒng)摸死，這個時候我們調(diào)整系統(tǒng)的閥值，限流設置到100，被摸死的閥值就可以高一些，這樣就算有6000個請求進來，我們系統(tǒng)也可以保證活下來。
4.異常流量監(jiān)控：防止長尾請求拖垮系統(tǒng)
我們盯系統(tǒng)監(jiān)控的時候通常會關(guān)注99分位的數(shù)據(jù)，但如果設置了合理的限流，系統(tǒng)依然被流量打掛，就要從那百分之一的長尾數(shù)據(jù)入手了。有些長尾數(shù)據(jù)對系統(tǒng)的影響會非常大。想象如果一個put請求傳過來幾十兆的數(shù)據(jù)，對java是極為不友好的，很有可能產(chǎn)生fgc，讓請求變慢，導致一系列問題。
總之，磨刀不誤砍柴工，當我們的系統(tǒng)因為fgc一次又一次重啟的時候，不如花時間了解下系統(tǒng)產(chǎn)生性能問題的原因，將產(chǎn)生問題的那根針拔掉，晚上睡個安穩(wěn)覺，白天更加充滿活力的挖新坑。希望每個程序員手里都是一個穩(wěn)定的系統(tǒng)。
 |
