跑得好好的Java進程,怎么突然就癱瘓了?

Java能成為應用最廣泛的語言,和他的內存托管機制是分不開的。很多人眼中,Java虛擬機是透明的,只需知道核心api的用法,便可以專注于實現具體業務,然后依賴Java虛擬機運行甚至優化應用。

你是否有過這樣的經歷,跑得好好的Java進程,突然就癱瘓了。過于依賴Java虛擬機導致我們對問題無從下手,問題反復出現影響開發效率。其實,多數Java進程癱瘓的原因可以從java虛擬機層面找到原因,本文列舉出導致Java進程癱瘓的一些共性原因,供大家交流和學習。

一、內存回收一直是java的痛點

用Java無法做出類似Redis這樣的產品。java的內存回收機制使我們在編寫代碼時不需要關注對象的回收,同時加大了內存回收的消耗,標記復制需要做內存拷貝,標記清除算法則需要stop the world。所以我們在使用緩存的時候,量稍微大一些就需要借助類似Redis這樣的中間件幫我們處理了。作為Javaer,我們享受了自動內存回收的安逸,同時也需要多了解下內存優化的方法。

二、為什么fgc停不下來了

1.什么情況下會gc

為了了解我們的系統為什么會不停fgc,我們需要先了解一下系統什么情況下會gc。在jvm層面,當我們new一個對象的時候,jvm會先在堆區分配對象需要的內存,這個時候如果內存不夠的話,就需要gc了,gc的返回結果就是對象的空間地址。jvm會先進行ygc,也就是我們通常說的標記復制,如果ygc之后依然申請不到空間,就會進行fgc了。同理,如果fgc之后依然沒有足夠的空間,就會循環的進行fgc,直到申請到足夠的空間。

2.導致不停的fgc的原因

如上文所講,fgc有可能發生在你的每一行代碼。如果fgc之后依然沒有足夠的空間,就會不停的fgc,直到申請到足夠的空間。同時JVM會限制在拋出OutOfMemory錯誤之前在GC中花費的VM時間的比例。系統頻繁FGC大致有五種情況:

  • 內存泄漏
  • 請求處理變慢導致同時申請內存的線程太多
  • metaspace 耗盡
  • 常量池將堆區占滿
  • 堆外內存耗盡

1w,正常情況下處理一個請求的時間是1ms,那同一時刻并行的請求數量僅為10。如果性能發生抖動,每個請求處理的時間增加到100ms,那同一時刻并行的請求數量就會增加到100個。每個線程在處理請求的時候都會new一些對象出來,長時間存活的線程會造成類似內存泄漏的效果,將系統的內存耗盡。同時fgc也會加劇系統性能的開銷,使系統變得更慢,產生雪崩。

三、如何讓系統fgc之后仍然能活下來

1.杜絕內存泄漏

內存泄漏造成系統癱瘓的頻率很高,有些系統定時從數據庫拉取配置信息緩存到集合中,但是set不小心寫成了list,最終在新增元素的時候內存溢出了。養成良好的編程習慣,多關注些細節,就能避免很多未知的問題。

2.并發限制:防止系統被撐死

每臺服務器都有并行處理請求的上限,不管請求處理的多快,超過上限之后就會被撐死,對高并發的請求做好并發數限制是保持系統穩定的必要條件。需要注意的是,有一些系統在拒絕過多的請求時,也會做一些降級邏輯,降級邏輯也是有性能開銷的,同樣需要做并發限制,如果降級的請求超過并發限制,將不進行降級邏輯直接拋出異常。我們可使用的限流組件有很多,推薦我們阿里自研的Sentinel 和 Netflix開源的Hystrix。

3.自適應限流:防止系統被摸死

我們需要自適應限流有兩個原因:

a. 每臺服務器所處的環境是不一樣的

有些服務器和離線計算的vm混部在一起,有些部署在實體機,有些部署在新老型號的機器上,每臺服務器能承受的qps并不完全一樣。統一配置分布式系統中每臺服務器限流閥值,要么發揮不出每臺服務器應有的作用,要么在高qps的情況下一些比較慢的服務器宕機,所以用服務器作為限流粒度是最合適的。

b.設置了正確的限流閥值,也可能被摸死

當單機承受的QPS 6~20倍于限流的流量時,拒絕一次請求的開銷就無法忽略不記了。譬如春晚活動有些系統設置了正確的限流也被6~20倍于限流的流量沖垮。這種死法稱為被摸死。應對這種情況,我們可以做的是在受到6~20倍的大流量時,動態減少限流的閥值。比如系統最開始接受1000qps,5000的拒絕流量過來會把系統摸死,這個時候我們調整系統的閥值,限流設置到100,被摸死的閥值就可以高一些,這樣就算有6000個請求進來,我們系統也可以保證活下來。

4.異常流量監控:防止長尾請求拖垮系統

我們盯系統監控的時候通常會關注99分位的數據,但如果設置了合理的限流,系統依然被流量打掛,就要從那百分之一的長尾數據入手了。有些長尾數據對系統的影響會非常大。想象如果一個put請求傳過來幾十兆的數據,對java是極為不友好的,很有可能產生fgc,讓請求變慢,導致一系列問題。 總之,磨刀不誤砍柴工,當我們的系統因為fgc一次又一次重啟的時候,不如花時間了解下系統產生性能問題的原因,將產生問題的那根針拔掉,晚上睡個安穩覺,白天更加充滿活力的挖新坑。希望每個程序員手里都是一個穩定的系統。

參考資料:jvm調優總結:https://hllvm-group.iteye.com/group/wiki/?category_id=301諾亞(Noah)自適應限流 穩定性利器 :https://www.atatech.org/articles/149208

我來評幾句
登錄后評論

已發表評論數()

相關站點

+訂閱
熱門文章
贵州11选5走势图软件 黑龙江22选5 赚钱区块链下载 人们认为李锦记最赚钱的是酸奶业务 云南十一选五 苹果手机买qq会员赚钱 老11选5 股票型基金赚钱比例 北京快3 蓝牌车货车拉货赚钱吗 20131104天下足球直播 p3开机号 河北20选5 魂淡放人家去赚钱 澳洲幸运8 qq农村怎么赚钱 pc蛋蛋