Java堆內存又溢出了！教你一招必殺技

JAVA堆內存管理是影響性能主要因素之一。
堆內存溢出是JAVA項目很是常見的故障，在解決該問題以前，必須先了解下JAVA堆內存是怎麼工做的。

先看下JAVA堆內存是如何劃分的，如圖：

1. JVM內存劃分爲堆內存和非堆內存，堆內存分爲年輕代（Young Generation）、老年代（Old Generation），非堆內存就一個永久代（Permanent Generation）。
2. 年輕代又分爲Eden和Survivor區。Survivor區由FromSpace和ToSpace組成。Eden區佔大容量，Survivor兩個區佔小容量，默認比例是8:1:1。
3. 堆內存用途：存放的是對象，垃圾收集器就是收集這些對象，而後根據GC算法回收。
4. 非堆內存用途：永久代，也稱爲方法區，存儲程序運行時長期存活的對象，好比類的元數據、方法、常量、屬性等。

在JDK1.8版本廢棄了永久代，替代的是元空間（MetaSpace），元空間與永久代上相似，都是方法區的實現，他們最大區別是：元空間並不在JVM中，而是使用本地內存。
元空間有注意有兩個參數：

• MetaspaceSize ：初始化元空間大小，控制發生GC閾值
• MaxMetaspaceSize ： 限制元空間大小上限，防止異常佔用過多物理內存

爲何移除永久代？

移除永久代緣由：爲融合HotSpot JVM與JRockit VM（新JVM技術）而作出的改變，由於JRockit沒有永久代。
有了元空間就再也不會出現永久代OOM問題了！

分代概念

新生成的對象首先放到年輕代Eden區，當Eden空間滿了，觸發Minor GC，存活下來的對象移動到Survivor0區，Survivor0區滿後觸發執行Minor GC，Survivor0區存活對象移動到Suvivor1區，這樣保證了一段時間內總有一個survivor區爲空。通過屢次Minor GC仍然存活的對象移動到老年代。
老年代存儲長期存活的對象，佔滿時會觸發Major GC=Full GC，GC期間會中止全部線程等待GC完成，因此對響應要求高的應用盡可能減小發生Major GC，避免響應超時。
Minor GC ： 清理年輕代
Major GC ： 清理老年代
Full GC ： 清理整個堆空間，包括年輕代和永久代
全部GC都會中止應用全部線程。

爲何分代？

將對象根據存活機率進行分類，對存活時間長的對象，放到固定區，從而減小掃描垃圾時間及GC頻率。針對分類進行不一樣的垃圾回收算法，對算法揚長避短。

爲何survivor分爲兩塊相等大小的倖存空間？

主要爲了解決碎片化。若是內存碎片化嚴重，也就是兩個對象佔用不連續的內存，已有的連續內存不夠新對象存放，就會觸發GC。

JVM堆內存經常使用參數

參數	描述
-Xms	堆內存初始大小，單位m、g
-Xmx（MaxHeapSize）	堆內存最大容許大小，通常不要大於物理內存的80%
-XX:PermSize	非堆內存初始大小，通常應用設置初始化200m，最大1024m就夠了
-XX:MaxPermSize	非堆內存最大容許大小
-XX:NewSize（-Xns）	年輕代內存初始大小
-XX:MaxNewSize（-Xmn）	年輕代內存最大容許大小，也能夠縮寫
-XX:SurvivorRatio=8	年輕代中Eden區與Survivor區的容量比例值，默認爲8，即8:1
-Xss	堆棧內存大小

垃圾回收算法（GC，Garbage Collection）

紅色是標記的非活動對象，綠色是活動對象。

• 標記-清除（Mark-Sweep）
  GC分爲兩個階段，標記和清除。首先標記全部可回收的對象，在標記完成後統一回收全部被標記的對象。同時會產生不連續的內存碎片。碎片過多會致使之後程序運行時須要分配較大對象時，沒法找到足夠的連續內存，而不得已再次觸發GC。

• 複製（Copy）
  將內存按容量劃分爲兩塊，每次只使用其中一塊。當這一塊內存用完了，就將存活的對象複製到另外一塊上，而後再把已使用的內存空間一次清理掉。這樣使得每次都是對半個內存區回收，也不用考慮內存碎片問題，簡單高效。缺點須要兩倍的內存空間。

• 標記-整理（Mark-Compact）
  也分爲兩個階段，首先標記可回收的對象，再將存活的對象都向一端移動，而後清理掉邊界之外的內存。此方法避免標記-清除算法的碎片問題，同時也避免了複製算法的空間問題。
  通常年輕代中執行GC後，會有少許的對象存活，就會選用複製算法，只要付出少許的存活對象複製成本就能夠完成收集。而老年代中由於對象存活率高，沒有額外過多內存空間分配，就須要使用標記-清理或者標記-整理算法來進行回收。

垃圾收集器

• 串行收集器（Serial）
  比較老的收集器，單線程。收集時，必須暫停應用的工做線程，直到收集結束。
• 並行收集器（Parallel）
  多條垃圾收集線程並行工做，在多核CPU下效率更高，應用線程仍然處於等待狀態。
• CMS收集器（Concurrent Mark Sweep）
  CMS收集器是縮短暫停應用時間爲目標而設計的，是基於標記-清除算法實現，整個過程分爲4個步驟，包括：
  • 初始標記（Initial Mark）
  • 併發標記（Concurrent Mark）
  • 從新標記（Remark）
  • 併發清除（Concurrent Sweep）

其中，初始標記、從新標記這兩個步驟仍然須要暫停應用線程。初始標記只是標記一下GC Roots能直接關聯到的對象，速度很快，併發標記階段是標記可回收對象，而從新標記階段則是爲了修正併發標記期間因用戶程序繼續運做致使標記產生變更的那一部分對象的標記記錄，這個階段暫停時間比初始標記階段稍長一點，但遠比並發標記時間段。
因爲整個過程當中消耗最長的併發標記和併發清除過程收集器線程均可以與用戶線程一塊兒工做，因此，CMS收集器內存回收與用戶一塊兒併發執行的，大大減小了暫停時間。

• G1收集器（Garbage First）
  G1收集器將堆內存劃分多個大小相等的獨立區域（Region），而且能預測暫停時間，能預測緣由它能避免對整個堆進行全區收集。G1跟蹤各個Region裏的垃圾堆積價值大小（所得到空間大小以及回收所需時間），在後臺維護一個優先列表，每次根據容許的收集時間，優先回收價值最大的Region，從而保證了再有限時間內得到更高的收集效率。
  G1收集器工做工程分爲4個步驟，包括：
  • 初始標記（Initial Mark）
  • 併發標記（Concurrent Mark）
  • 最終標記（Final Mark）
  • 篩選回收（Live Data Counting and Evacuation）

初始標記與CMS同樣，標記一下GC Roots能直接關聯到的對象。併發標記從GC Root開始標記存活對象，這個階段耗時比較長，但也能夠與應用線程併發執行。而最終標記也是爲了修正在併發標記期間因用戶程序繼續運做而致使標記產生變化的那一部分標記記錄。最後在篩選回收階段對各個Region回收價值和成本進行排序，根據用戶所指望的GC暫停時間來執行回收。

垃圾收集器參數

參數	描述
-XX:+UseSerialGC	串行收集器
-XX:+UseParallelGC	並行收集器
-XX:+UseParallelGCThreads=8	並行收集器線程數，同時有多少個線程進行垃圾回收，通常與CPU數量相等
-XX:+UseParallelOldGC	指定老年代爲並行收集
-XX:+UseConcMarkSweepGC	CMS收集器（併發收集器）
-XX:+UseCMSCompactAtFullCollection	開啓內存空間壓縮和整理，防止過多內存碎片
-XX:CMSFullGCsBeforeCompaction=0	表示多少次Full GC後開始壓縮和整理，0表示每次Full GC後當即執行壓縮和整理
-XX:CMSInitiatingOccupancyFraction=80%	表示老年代內存空間使用80%時開始執行CMS收集，防止過多的Full GC
-XX:+UseG1GC	G1收集器
-XX:MaxTenuringThreshold=0	在年輕代通過幾回GC後還存活，就進入老年代，0表示直接進入老年代

爲何會堆內存溢出？

在年輕代中通過GC後還存活的對象會被複制到老年代中。當老年代空間不足時，JVM會對老年代進行徹底的垃圾回收（Full GC）。若是GC後，仍是沒法存放從Survivor區複製過來的對象，就會出現OOM（Out of Memory）。

OOM（Out of Memory）異經常見有如下幾個緣由：
1）老年代內存不足：java.lang.OutOfMemoryError:Javaheapspace
2）永久代內存不足：java.lang.OutOfMemoryError:PermGenspace
3）代碼bug，佔用內存沒法及時回收。
OOM在這幾個內存區都有可能出現，實際遇到OOM時，能根據異常信息定位到哪一個區的內存溢出。
能夠經過添加個參數-XX:+HeapDumpOnOutMemoryError，讓虛擬機在出現內存溢出異常時Dump出當前的內存堆轉儲快照以便過後分析。

熟悉了JAVA內存管理機制及配置參數，下面是對JAVA應用啓動選項調優配置：

JAVA_OPTS="-server -Xms512m -Xmx2g -XX:+UseG1GC -XX:SurvivorRatio=6 -XX:MaxGCPauseMillis=400 -XX:G1ReservePercent=15 -XX:ParallelGCThreads=4 -XX:
ConcGCThreads=1 -XX:InitiatingHeapOccupancyPercent=40 -XX:+PrintGCDetails  -XX:+PrintGCTimeStamps -Xloggc:../logs/gc.log"

• 設置堆內存最小和最大值，最大值參考歷史利用率設置
• 設置GC垃圾收集器爲G1
• 啓用GC日誌，方便後期分析

小結

• 選擇高效的GC算法，可有效減小中止應用線程時間。
• 頻繁Full GC會增長暫停時間和CPU使用率，能夠加大老年代空間大小下降Full GC，但會增長回收時間，根據業務適當取捨。

這不是一個彩蛋，是一個技術乾貨

在2018/2019年Docker/Kubernetes容器技術無疑是業內最火的技術。根據招聘簡介狀況來看，容器技術已成爲運維工程師、架構師必備技能。
爲幫助你們快速掌握這門主流技術，少走彎路，提升核心競爭力。決定寫《基於Kubernetes企業容器雲平臺落地與實踐》文章專欄，給朋友在企業落地容器雲平臺提供一些企業實踐性指導，但願本身所學所思的東西可以幫助到你們，可以有所啓發。

• 掌握Docker、Kubernetes核心概念
• 熟悉Docker平常運維管理
• 熟練部署Kubernetes集羣
• 熟悉容器雲平臺平常運維管理
• 容器雲平臺架構設計及規劃
• 將微服務業務架構遷移到容器雲平臺