JVM內存模型
首先我們來了解一下JVM的內存模型的怎么樣的：
1.堆：存放對象實例，幾乎所有的對象實例都在這里分配內存
- 堆得內存由-Xms指定，默認是物理內存的1/64；最大的內存由-Xmx指定，默認是物理內存的1/4。
- 默認空余的堆內存小於40%時，就會增大，直到-Xmx設置的內存。具體的比例可以由-XX:MinHeapFreeRatio指定
- 空余的內存大於70%時，就會減少內存，直到-Xms設置的大小。具體由-XX:MaxHeapFreeRatio指定。
2.虛擬機棧
虛擬機棧描述的是Java方法執行的內存模型：每個方法被執行的時候都會同時創建一個棧幀（Stack Frame）用於存儲局部變量表、操作棧、動態鏈接、方法出口等信息本地方法棧：本地方法棧則是為虛擬機使用到的Native方法服務。
3.方法區：存儲已被虛擬機加載的類元數據信息(元空間)
1）有時候也成為永久代，在該區內很少發生垃圾回收，但是並不代表不發生GC，在這里進行的GC主要是對方法區里的常量池和對類型的卸載
2）方法區主要用來存儲已被虛擬機加載的類的信息、常量、靜態變量和即時編譯器編譯后的代碼等數據。
該區域是被線程共享的。
3）方法區里有一個運行時常量池，用於存放靜態編譯產生的字面量和符號引用。該常量池具有動態性，也就是說常量並不一定是編譯時確定，運行時生成的常量也會存在這個常量池中。
4.程序計數器：當前線程所執行的字節碼的行號指示器
總結：
JVM垃圾回收算法
1.標記-清除: 這是垃圾收集算法中最基礎的，根據名字就可以知道，它的思想就是標記哪些要被回收的對象，然后統一回收。這種方法很簡單，但是會有兩個主要問題：1.效率不高，標記和清除的效率都很低；2.會產生大量不連續的內存碎片，導致以后程序在分配較大的對象時，由於沒有充足的連續內存而提前觸發一次GC動作。
2.復制算法: 為了解決效率問題，復制算法將可用內存按容量划分為相等的兩部分，然后每次只使用其中的一塊，當一塊內存用完時，就將還存活的對象復制到第二塊內存上，然后一次性清楚完第一塊內存，再將第二塊上的對象復制到第一塊。但是這種方式，內存的代價太高，每次基本上都要浪費一般的內存。 於是將該算法進行了改進，內存區域不再是按照1：1去划分，而是將內存划分為8:1:1三部分，較大那份內存交Eden區，其余是兩塊較小的內存區叫Survior區。每次都會優先使用Eden區，若Eden區滿，就將對象復制到第二塊內存區上，然后清除Eden區，如果此時存活的對象太多，以至於Survivor不夠時，會將這些對象通過分配擔保機制復制到老年代中。(java堆又分為新生代和老年代)
3. 標記-整理 該算法主要是為了解決標記-清除，產生大量內存碎片的問題；當對象存活率較高時，也解決了復制算法的效率問題。它的不同之處就是在清除對象的時候現將可回收對象移動到一端，然后清除掉端邊界以外的對象，這樣就不會產生內存碎片了。
4.分代收集 現在的虛擬機垃圾收集大多采用這種方式，它根據對象的生存周期，將堆分為新生代和老年代。在新生代中，由於對象生存期短，每次回收都會有大量對象死去，那么這時就采用復制算法。老年代里的對象存活率較高，沒有額外的空間進行分配擔保，所以可以使用標記-整理 或者 標記-清除。
JVM垃圾收集器有哪些？以及優劣勢比較？
1.串行收集器
串行收集器是最簡單的，它設計為在單核的環境下工作（32位或者windows），你幾乎不會使用到它。它在工作的時候會暫停整個應用的運行，因此在所有服務器環境下都不可能被使用。
使用方法：-XX:+UseSerialGC
2.並行收集器
這是JVM默認的收集器，跟它名字顯示的一樣，它最大的優點是使用多個線程來掃描和壓縮堆。缺點是在minor和full GC的時候都會暫停應用的運行。並行收集器最適合用在可以容忍程序停滯的環境使用，它占用較低的CPU因而能提高應用的吞吐（throughput）。
使用方法：-XX:+UseParallelGC
3.CMS收集器
CMS是Concurrent-Mark-Sweep的縮寫，並發的標記與清除。
這個算法使用多個線程並發地（concurrent）掃描堆，標記不使用的對象，然后清除它們回收內存。在兩種情況下會使應用暫停（Stop the World, STW）：
1. 當初次開始標記根對象時initial mark。
2. 當在並行收集時應用又改變了堆的狀態時，需要它從頭再確認一次標記了正確的對象final remark。
這個收集器最大的問題是在年輕代與老年代收集時會出現的一種競爭情況（race condition），稱為提升失敗promotion failure。對象從年輕代復制到老年代稱為提升promotion，但有時侯老年代需要清理出足夠空間來放這些對象，這需要一定的時間，它收集的速度可能趕不上不斷產生的要提升的年輕代對象的速度，這時就需要做STW的收集。STW正是CMS想避免的問題。為了避免這個問題，需要增加老年代的空間大小或者增加更多的線程來做老年代的收集以趕上從年輕代復制對象的速度。
除了上文所說的內容之外，CMS最大的問題就是內存空間碎片化的問題。CMS只有在觸發FullGC的情況下才會對堆空間進行compact。如果線上應用長時間運行，碎片化會非常嚴重，會很容易造成promotion failed。為了解決這個問題線上很多應用通過定期重啟或者手工觸發FullGC來觸發碎片整理。
對比並行收集器它的一個壞處是需要占用比較多的CPU。對於大多數長期運行的服務器應用來說，這通常是值得的，因為它不會導致應用長時間的停滯。但是它不是JVM的默認的收集器。
4.G1收集器
如果你的堆內存大於4G的話，那么G1會是要考慮使用的收集器。它是為了更好支持大於4G堆內存在JDK 7 u4引入的。G1收集器把堆分成多個區域，大小從1MB到32MB，並使用多個后台線程來掃描這些區域，優先會掃描最多垃圾的區域，這就是它名稱的由來，垃圾優先Garbage First。
如果在后台線程完成掃描之前堆空間耗光的話，才會進行STW收集。它另外一個優點是它在處理的同時會整理壓縮堆空間，相比CMS只會在完全STW收集的時候才會這么做。
使用過大的堆內存在過去幾年是存在爭議的，很多開發者從單個JVM分解成使用多個JVM的微服務（micro-service）和基於組件的架構。其他一些因素像分離程序組件、簡化部署和避免重新加載類到內存的考慮也促進了這樣的分離。
除了這些因素，最大的因素當然是避免在STW收集時JVM用戶線程停滯時間過長，如果你使用了很大的堆內存的話就可能出現這種情況。另外，像Docker那樣的容器技術讓你可以在一台物理機器上輕松部署多個應用也加速了這種趨勢。
使用方法：－XX:+UseG1GC