Java后端開發三年，你不得不了解的JVM
JAVA程序員，三年是個坎，如果過了三年你還沒有去研究JVM的話，那么你這個程序員只能是板磚的工具了。下面來個JVM的解析可好?
JVM是Java Virtual Machine(Java虛擬機)的縮寫，也就是指的JVM虛擬機，屬于是一種虛構出來的計算機，在我們實際的電腦上來進行模擬各種計算機的功能的這么個東西。
因為有了JVM的存在，搞JAVA的不再需要去關心什么時候去釋放內存，也不會像C++程序員那樣為了一點點內存而惆悵，對就是你，JVM虛擬機幫你把這些東西都完成了，那么我們來說說JAVA的JVM吧!
我們先來看看JVM的模型吧，之前在百度上看文檔，上面就說了幾個，方法區，堆，棧，計數器。沒了，很難受，于是看了深入理解JVM的書，也算是有點體會。
在深入理解JVM一書中提到，JVM運行時的數據區域會劃分為幾個不同的區域，有方法區(Method Area)，虛擬機棧(VM Stack)，本地方法棧(Native Method Stack)，堆(heap)，程序計數器(Program Counter Register)，下面就是書中的圖：
咱們一個一個來解釋: 先說程序計數器(Program Counter Register)：程序計數器實際上就是用于存放下一條指令所在地址的地方，當我們執行一條指令的時候，要先知道他存放的指令位置，然后把指令帶到寄存器上這是就是獲取指令，然后程序計數器中的存貯地址會加1，然后這樣子循環的去執行，而且程序計數器這個小的內存區是“線程私有的內存”。
為什么會是私有的呢?，在深入理解JVM一書中說的是虛擬機的多線程通過線程的輪流切換來切換分配處理器的執行時間的方式來實現，說起來其實很拗口的，其實也就是說一個處理器，同一個時刻，只會執行一個線程的指令，但是時間可能不均衡，可能***分鐘在a線程，第二分鐘就去執行b線程了，但是呢，為了保證切換回來還需要是一致的，那么每個線程中就會有一個獨立存在的程序計數器，獨立來存貯，為了保證不影響。所以他是一個“線程私有的內存”。
程序計數器還有幾個特點：
- 如果線程正在執行的是Java 方法，則這個計數器記錄的是正在執行的虛擬機字節碼指令地址。
- 如果正在執行的是Native 方法，則這個計數器值為空(Undefined)。
- 此內存區域是唯一一個在Java虛擬機規范中沒有規定任何OutOfMemoryError情況的區域。
分別解釋一下這三句話吧，這是深入理解java虛擬機中的原話，***句好像已經很直白了，沒的說，來說說第二句話吧
因為這個計數器記錄的是字節碼指令地址，但是Native(本地方法);就比如說(System.currentTimeMillis())他是通過C來實現，直接通過系統就能直接調用了不需要去編譯成需要執行的字節碼指令的話，那么就相當于不過程序計數器，它沒有記錄的話，那他的計數器的值就肯定為空了。
第三句話 我們可以試試編譯一小段代碼，然后反編譯出來看看
也就是實際上是這個樣子的
- public class Test{ public int test(){ int a = 10; //0 ...... int b = 20; //3....... int c = 30; //6...... return (a+b)*c; //11.... 13.... 14...執行加減乘除操作 } }
上面的0,2，3,5,6,8....就是指令的偏移地址bipush就是入棧指令， 在執行到test方法的時候，線程就會創建對應的程序計數器在計數器中放0,2，3,5,6,8....這些指令地址，所以計數器里改變的不是內存的大小，它也就沒有溢出了。
下面我們再來說一下：JAVA虛擬機棧(VM Stack)
線程私有，生命周期和線程一樣，這個虛擬機棧描述的是JAVA方法執行的內存模型，用于存局部變量，操作數棧，方法出口等信息的，上面那個bipush就是入棧指令，在這里最需要注意的就是他存放的是什么數據.局部變量里面放的就是那些我們所知道的基本的數據類型，對象引用的話那就是一個地址。
在虛擬機規范里面還說，他的2個異常狀況：
- 一個是StackOverflowError異常，棧內存溢出，這肯定很容易理解，就是棧的內存不夠，你的請求線程太大。(固定長度的棧)
- 如果說在動態擴展的過程中，申請的長度還是不夠，那么會拋出另外一個異常OutOfMemoryError異常。
本地方法棧(Native Method Stack) ：
它和虛擬機棧很類似，區別就在于虛擬機棧執行的是JAVA方法，但是本地方法棧則是Native方法，其他的沒啥不同就連拋出異常都一樣的。
JAVA堆(heap) 在JVM一書中也有提到，Heap是在JAVA虛擬機中內存占用***的一個地方，也是所有線程共享的一個內存區域，堆內存中主要就是用于存放對象實例的。
幾乎是所有的對象實例都在這里分配內存，JAVA堆是垃圾收集器管理的主要區域，那么現在重點來了，面試中問到最多的垃圾回收機制接下來就要仔細說說了。
內存回收，現在都是進行的分代算法，堆中也是，新生代，老年代，而且兩種垃圾回收機制是采用的不同的回收機制的，在新生代中，每次垃圾收集時都發現有大批對象死去，只有少量存活，那就選用復制算法，只需要付出少量存活對象的復制成本就可以完成收集。
而老年代中因為對象存活率高、沒有額外空間對它進行分配擔保，就必須使用"標記-清理"或"標記-壓縮"算法來進行回收，說回收機制先看看heap的分區(這個from和to 并不是絕對的，看對象處在哪個位置，GC的次數不一樣之后，那from和to會有相應轉變)
分區一目了然，下面研究一下算法實現吧
Minor GC：GC新生代，
Full GC：老年代GC，
因為新生代中對象的存活率比較低，所以一般采用復制算法，老年代的存活率一般比較高，一般使用”標記-清理”或者”標記-整理”算法進行回收。
看了有幾天才明白啥意思，我說說我自己的見解吧，還是畫圖吧，
Minor GC：
我們每次new對象的時候都會先在新生代的Enden區放著也就是最開始 是這樣子的
然后在Enden用完的時候里面會出現待回收的
然后就來了把存活的對象復制放到Survior1(from)中，待回收的等待給他回收掉 就是這樣的
然后把Enden區清空回收掉
這樣的話 ***次GC就完成了，下面再往下走
當Enden充滿的時候就會再次GC
先是這個樣子的
然后會把 Enden和Survoir1中的內容復制到Survior中，
然后就會把Enden和Survior進行回收
然后從Enden中過去的就相當于次數少的，而從Survior1中過去的就相當于移動了2次
這樣新生代的GC就執行了2次了，
當Enden再次被使用完成的時候，就會從Survior2復制到Survior1中
經過回收之后Surior1就變了，1對象是從Enden直接復制過來的，2對象是Enden-->Survior2-->Survior1 ，3對象則是從Enden-->Surivior1-->Survior2-->Survior1 復制過來的，這樣一步一步的執行下去的時候，就是新生代的GC。
既然這樣，那為什么還會存在老年代呢?其實如果GC在執行的時候有些對象一直沒有被回收，那么他移動次數就會***的累計，每次從Surior(from)到Surior(to)的過程中就相當于又增加了一次移動，當他達到一定的次數的時候(默認是15)，就會移動到老年代里了，所以不存在不會被回收的對象，但是這個次數可以設置的，
-XX:MaxTenuringThreshold
就類似這樣子
其實上邊的這只是一種情況，還有就是如果對象太大，存不下，那就直接會進入老年代。
還有那種默認就是長期活著的也會進入老年代，
而且這種復制算法的垃圾回收機制是比較浪費內存的，每次都會有一塊內存區是閑著不干活的，但是優點很明顯，簡單高效
以上就是GC中垃圾回收中的新生代復制算法解析，新生代的Minor GC也算是知道了不少東西了，以上就是一些個人的見解，圖比較清晰，容易理解，有不對的地方希望能夠各位同行指點一下。
