資訊專欄INFORMATION COLUMN
摘要：當兩個對象相互引用時，這兩個對象就不會被回收引用計數(shù)算法不被主流虛擬機采用，主要原因是它很難解決對象之間相互循環(huán)引用的問題。
垃圾收集器與內(nèi)存分配策略 詳解 3.1 概述
本文參考的是周志明的 《深入理解Java虛擬機》第三章 ，為了整理思路，簡單記錄一下，方便后期查閱。
3.2 對象已死嗎在垃圾收集器進行回收前，第一件事就是確定這些對象哪些還存活，哪些已經(jīng)死去。
3.2.1 引用計數(shù)算法在對象中添加一個引用計數(shù)器，每當有一個地方引用它時，計數(shù)器就加1；當引用失效時，計數(shù)器減1；其中計數(shù)器為0的對象是不可能再被使用的已死對象。
當兩個對象相互引用時，這兩個對象就不會被回收
引用計數(shù)算法,不被主流虛擬機采用，主要原因是它很難解決對象之間相互循環(huán)引用的問題。
3.2.2 可達性分析算法通過一系列的稱為GC Roots的對象作為起始點，從這些節(jié)點開始向下搜索，搜索所經(jīng)過
的路徑稱為引用鏈（Reference Chain），當一個對象到GC Roots沒有任何引用鏈相連（在圖論中稱為對象不可達）時，這個對象就是不可用的。
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除
在java語言中，可作為GC Roots的對象包括：
虛擬機棧（棧幀中的本地變量表）中引用的對象
方法區(qū)中類靜態(tài)屬性引用的對象
方法區(qū)中常量引用的對象
本地方法棧中JNI引用的對象
3.2.3 引用的分類java的引用可以分為強引用、軟引用、弱引用、虛引用：
強引用：是指在程序代碼中直接存在的引用，譬如引用new操作符創(chuàng)建的對象。只要強引用還存在，垃圾收集器就永遠不會回收掉被引用的對象。
軟引用：還有用但是并非必需的引用，早系統(tǒng)將要發(fā)生內(nèi)存溢出異常之前會把這些對象列進回收范圍中進行二次回收，若還是沒有足夠的內(nèi)存，才會拋出內(nèi)存溢出異常。
弱引用：非必需的對象，只能生存到下一次垃圾收集發(fā)生之前。當垃圾收集器工作時，無論內(nèi)存是否夠用都將回收這些對象。
虛引用：一個對象是否有虛引用的存在完全不會對他的生存時間構(gòu)成影響，也無法通過虛引用來取得一個對象實例。
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除3.2.4 宣告一個對象死亡的過程
要真正宣告一個對象死亡，至少要經(jīng)歷兩次標記過程：
若對象在進行可達性分析后發(fā)現(xiàn)沒有與GC Roots相連接的引用鏈，會被 第一次標記 并且進行一次篩選。篩選的條件是此對象是否有必要執(zhí)行finalize()方法（如當對象沒有重寫finalize()方法或者finalize()方法已經(jīng)被虛擬機調(diào)用過則認為沒有必要執(zhí)行）。
如果有必要執(zhí)行則將該對象放置在F-Queue隊列中，并在稍后由一個由虛擬機自己建立的、低優(yōu)先級的Finalizer線程去執(zhí)行它；稍后GC將對F-Queue中的對象進行第二次標記，如果對象還是沒有被引用，則會被回收。
但是作者不建議通過finalize()方法“拯救”對象，因為它運行代價高、不確定性大、無法保證各個對象的調(diào)用順序。
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除3.2.5 回收方法區(qū)
很多人認為方法區(qū)（HotSopt中的永久代）是沒有垃圾收集的，java虛擬機規(guī)范中也沒有要求需要對方法區(qū)實現(xiàn)垃圾收集。
永久代（方法區(qū)）的垃圾收集主要回收兩部分內(nèi)容：廢棄常量和無用的類
廢棄常量：假如一個字符串“abc”已經(jīng)進入了常量池中，但是當前系統(tǒng)沒有任何一個String對象是叫 做“abc”的，換句話說，就是沒有任何String對象引用常量池中的“abc”常量，也沒有其他 - 地方引用了這個字面量，如果這時發(fā)生內(nèi)存回收，而且必要的話，這個“abc”常量就會被系 - 統(tǒng)清理出常量池。
無用的類：同時滿足下面3個條件的類（實例、類加載器被回收，java.lang.Class對象沒有被引用）。
該類所有的實例都已經(jīng)被回收，也就是Java堆中不存在該類的任何實例。
加載該類的ClassLoader已經(jīng)被回收。
該類對應的java.lang.Class對象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。
3.3 垃圾收集算法 3.3.1 標記-清除算法 (Mark-Sweep)算法分為兩個階段：標記和清除
標記：首先標記所有需要回收的對象
清除：在標記完成后統(tǒng)一回收所有被標記的對象
標記過程在上文宣告一個對象死亡過程中提及
缺點
效率問題，標記和清除兩個過程的效率都不高（回收后空間碎片過多，再次回收（即可達性分析時）有時需要遍歷整個內(nèi)存區(qū)域）。
空間問題，標記清除之后會產(chǎn)生大量不連續(xù)的內(nèi)存碎片，空間碎片太多可能會導致以后在程序運行過程中需要分配較大對象時，無法找到足夠的連續(xù)內(nèi)存,而不得不提前觸發(fā)另一次垃圾收集動作。
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除3.3.2 復制算法（新生代算法）(Copying)
思路：將可用內(nèi)存按容量分為兩個塊，每次只用其中之一。當這一塊內(nèi)存用完之后，將還存活的對象復制到另一邊去，然后清除所有已經(jīng)使用過的部分。
優(yōu)點
每次都是對整個半?yún)^(qū)進行內(nèi)存回收，內(nèi)存分配時也就不用考慮內(nèi)存碎片等復雜情況，只要移動堆頂指針，按順序分配內(nèi)存即可，實現(xiàn)簡單，運行高效。
缺點
代價是將內(nèi)存縮小為了原來的一半，未免太高了一點。
解決方法
新生代中的對象98%是“朝生夕死”的，所以并不需要按照1:1的比例來劃分內(nèi)存空間，而是將內(nèi)存分為一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden和其中一塊Survivor。
在HotSpot里，考慮到大部分對象存活時間很短將內(nèi)存分為Eden和兩塊Survivor，默認比例為8:1:1。代價是存在部分內(nèi)存空間浪費，適合在新生代使用。
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除3.3.3 標記-整理算法（老年代算法）(Mark-Compact)
標記過程仍然與“標記-清除”算法一樣，但后續(xù)步驟不是直接對可回收對象進行清理，而是讓所有存活的對象都向一端移動，然后直接清理掉端邊界以外的內(nèi)存。
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除3.3.4 分代收集算法
當前商用虛擬機都采用了這種算法，根據(jù)對象的存活周期將內(nèi)存劃分為幾塊，一般是把Java堆分為新生代和老生代，根據(jù)各個年代采用適當?shù)氖占惴?/strong>。
新生代一般采用復制算法(Copying)。
老生代一搬采用 標記-清理(Mark-Sweep) 或者標記-整理(Mark-Compact) 進行回收。
3.4 hotspot的算法實現(xiàn) 3.4.1 枚舉根節(jié)點可達性分析的缺點
從GC Roots節(jié)點找引用鏈這個操作為例，可作為GC Roots的節(jié)點主要在全局性的引用（例如常量或類靜態(tài)屬性）與執(zhí)行上下文（例如棧幀中的本地變量表）中，現(xiàn)在很多應用僅僅方法區(qū)就有數(shù)百兆，如果要逐個檢查這里面的引用，那么必然會消耗很多時間。
由于要確保在一致性的快照中進行可達性分析，從而導致GC進行時必須要停頓所有Java執(zhí)行線程；
目前主流的Java虛擬機使用的都是準確式GC，當執(zhí)行系統(tǒng)停頓下來后并不需要一個不漏的檢查完所有執(zhí)行上下文和全局的引用變量，虛擬機應當有辦法直接得知哪些地方存著對象的引用
HotSpot使用一組稱為OopMap的數(shù)據(jù)結(jié)構(gòu)**來記錄哪些地方存著對象的引用
在類加載過程中，HotSpot就把對象內(nèi)什么偏移量上是什么類型的數(shù)據(jù)計算出來，在JIT編譯過程中會在特定的位置記錄下棧和寄存器中哪些位置是引用
判斷對象引用
類加載時，使用OopMap的數(shù)據(jù)結(jié)構(gòu)
JIT編譯時特定記錄
3.4.2 安全點HotSpot沒有為每條指令都生成OopMap，只是在特定位置記錄了這些信息，這些位置稱為安全點。
即程序執(zhí)行時并非在所有地方都能停頓下來開始GC，只有到達安全點時才能暫停。
對于安全點基本上是以程序是否具有讓程序長時間執(zhí)行的特征（比如方法調(diào)用、循環(huán)跳轉(zhuǎn)、異常跳轉(zhuǎn)等）為標準進行選定的。
另外還需要考慮如果在GC時讓所有線程都跑到最近的安全點上，有兩種方案：搶先式中斷和主動式中斷；
搶先式中斷
不需要線程的執(zhí)行代碼主動去配合，在GC發(fā)生時，首先把所有線程全部中斷，如果發(fā)現(xiàn)有線程中斷的地方不在安全點上，就恢復線程，讓它“跑”到安全點上。 現(xiàn)在幾乎沒有虛擬機實現(xiàn)采用搶先式中斷來暫停線程從而響應GC事件。
主動式中斷
當GC需要中斷線程的時候，不直接對線程操作，僅僅簡單地設置一個標志，各個線程執(zhí)行時主動去輪詢這個標志，發(fā)現(xiàn)中斷標志為真時就自己中斷掛起。輪詢標志的地方和安全點是重合的，另外再加上創(chuàng)建對象需要分配內(nèi)存的地方。
兩者的區(qū)別在于，搶先式中斷是無論如何都進行中斷，而主動式中斷則是線程執(zhí)行輪詢標志查看是否中斷。
3.4.3 安全區(qū)域為了處理不執(zhí)行的程序的安全點問題，提出了安全區(qū)域來解決問題。
安全區(qū)域是指在一段代碼片段之中，引用關系不會發(fā)生變化，在這個區(qū)域內(nèi)的任何地方進行GC都是安全的。
虛擬機如個具體的進行內(nèi)存回收是由虛擬機所采用的GC收集器決定的，而通常虛擬機中往往不止有一種GC收集器。
線程執(zhí)行到安全區(qū)域時，首先標識自己已經(jīng)進入了安全區(qū)域，這樣JVM在GC時就不管這些線程了。
3.5 垃圾收集器如果說收集算法是內(nèi)存回收的方法論，那么垃圾收集器就是內(nèi)存回收的具體實現(xiàn)。
不同的收集器應用的區(qū)域不同，到現(xiàn)在為止沒有最好的收集器，也沒有萬能的收集器。
3.5.1 serial收集器Serail 收集器是單線程的，他在進行垃圾收集時必須暫停其他的所有線程，直到收集結(jié)束。
隨著收集器的發(fā)展，用戶線程的停頓時間越來越段，但任然無法消除。
Serial收集器是虛擬機運行在Client模式下默認的新生代收集器。
對于單個CPU壞境來說，Serial收集器**由于沒有線程交互的開銷，專心做垃圾收集，可以獲得很高的單線程收集效率。
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除3.5.2 parnew收集器
ParNew收集器是Serial收集器的多線程版本
ParNew收集器是運行在Server模式下虛擬機中首選的新生代收集器
在垃圾收集器中并發(fā)與并行的概念：
并行：多條垃圾收集線程并行工作，但此時用戶線程仍然處于等待狀態(tài)。
并發(fā)：用戶線程與垃圾收集線程同時執(zhí)行（但不一定是并行的，可能會交替執(zhí)行），用戶程序在繼續(xù)運行，而垃圾收集程序運行在另一個CPU上。
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除3.5.3 parallel scavenge收集器
新生代收集器，使用復制算法，并行的多線程收集器；
與其他收集器關注于盡可能縮短垃圾收集時用戶線程停頓時間不同，它的目標是達到一個可控制的吞吐量。
吞吐量就是CPU用于運行用戶代碼的時間與CPU總消耗時間的比值，即吞吐量=運行用戶代碼時間/（運行用戶代碼時間+垃圾收集時間），虛擬機總共運行了100分鐘，其中垃圾收集花掉1分鐘，那吞吐量就是99%。
高吞吐量可以高效的利用CPU時間，盡快得完成程序的運算任務，主要適合在后臺運算而不需要太多交互的任務。
GC停頓時間的縮短是以犧牲吞吐量和新生代空間來換取的。
Parallel Scavenge收集器也經(jīng)常被稱為吞吐量優(yōu)先收集器。
Parallel Scavenge收集器提供了兩個參數(shù)用于精確控制吞吐量
控制最大垃圾收集停頓時間的-XX：MaxGCPauseMillis參數(shù)。
直接設置吞吐量大小的-XX：GCTimeRatio參數(shù)。
3.5.4 serial old收集器Serial Old是Serial收集器的老年代版本，它同樣是一個單線程收集器，使用“標記-整理”算法。
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除3.5.5 parallel old收集器
Serial Old收集器是Serail收集器的老年代版本，是一個單線程收集器，使用標記-整理算法。
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除
Serail Old收集器主要用于Clinet模式下。
Serail Old收集器另一種用途是作為CMS收集器的后備預案。
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多線程和“標記-整理”算法。
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除3.5.6 cms收集器
CMS收集器是一種以獲取最短的回收停頓時間為目標的收集器。
CMS收集器基于標記-清楚算法實現(xiàn)，分為四個步驟：初始標記、并發(fā)標記、重新標記、并發(fā)清除。
步驟詳解
初始標記：標記一下GC Roots能直接關聯(lián)到的對象，速度很快。
并發(fā)標記：進行GC Roots Tracing。
重新標記：是為了修正那些在并發(fā)標記期間因用戶程序繼續(xù)運作而導致標記產(chǎn)生變動的那一部分對象的標記記錄，在這一階段的停頓時間會比初始標記階段稍長一點。
并發(fā)清除：（CMS concurrent sweep）。
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除3.5.7 g1收集器
G1收集器是一款面向服務端應用的垃圾收集器。
G1收集器具備以下特點：
并行與并發(fā)
G1能充分利用多CPU、 多核環(huán)境下的硬件優(yōu)勢，使用多個CPU（CPU或者CPU核心）來縮短Stop-The-World停頓的時間，部分其他收集器原本需要停頓Java線程執(zhí)行的GC動作，G1收集器仍然可以通過并發(fā)的方式讓Java程序繼續(xù)執(zhí)行。
分代收集
與其他收集器一樣，分代概念在G1中依然得以保留。 雖然G1可以不需要其他收集器配合就能獨立管理整個GC堆，但它能夠采用不同的方式去處理新創(chuàng)建的對象和已經(jīng)存活了一段時間、 熬過多次GC的舊對象以獲取更好的收集效果。
空間整合
從整體上來看是基于“標記-整理”算法實現(xiàn)的，在局部上是基于復制算法實現(xiàn)的，但無論如何，這兩種算法都意味著G1運作期間不會產(chǎn)生內(nèi)存空間碎片，收集后能提供規(guī)整的可用內(nèi)存。 這種特性有利于程序長時間運行，分配大對象時不會因為無法找到連續(xù)內(nèi)存空間而提前觸發(fā)下一次GC。
可預測的停頓
這是G1相對于CMS的另一大優(yōu)勢，降低停頓時間是G1和CMS共同的關注點，但G1除了追求低停頓外，還能建立可預測的停頓時間模型，能讓使用者明確指定在一個長度為M毫秒的時間片段內(nèi)，消耗在垃圾收集上的時間不得超過N毫秒，這幾乎已經(jīng)是實時Java（RTSJ）的垃圾收集器的特征了。
G1收集器將整個Java堆劃分為多個大小相等的獨立區(qū)域，雖然還保留有新生代和老生代的概念，但新生代和老生代不再是物理隔的了，他們是一部分Region的集合。
G1收集器可以有計劃地避免在整個Java堆中進行全區(qū)域的垃圾收集：跟蹤各個Region里面的垃圾堆積的價值大小，在后臺維護一個優(yōu)先列表，每次根據(jù)允許的收集時間，優(yōu)先回收價值最大的Region。
在G1收集器中，使用Remembered Set來避免全堆掃描
G1收集器的運作大致可劃分為以下幾個步驟：
初始標記（Initial Marking）
僅僅只是標記一下GC Roots能直接關聯(lián)到的對象，并且修改TAMS（Next Top at Mark Start）的值，讓下一階段用戶程序并發(fā)運行時，能在正確可用的Region中創(chuàng)建新對象，這階段需要停頓線程，但耗時很短。
并發(fā)標記（Concurrent Marking）
從GC Root開始對堆中對象進行可達性分析，找出存活的對象，這階段耗時較長，但可與用戶程序并發(fā)執(zhí)行。
最終標記（Final Marking）
為了修正在并發(fā)標記期間因用戶程序繼續(xù)運作而導致標記產(chǎn)生變動的那一部分標記記錄，虛擬機將這段時間對象變化記錄在線Remembered Set Logs里面，最終標記階段需要把Remembered Set Logs的數(shù)據(jù)合并到Remembered Set中，這階段需要停頓線程，但是可并行執(zhí)行。
篩選回收（Live Data Counting and Evacuation）
首先對各個Region的回收價值和成本進行排序，根據(jù)用戶所期望的GC停頓時間來制定回收計劃
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除3.5.8 理解gc日志
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除
最前面的數(shù)字代表GC發(fā)生的時間（虛擬機啟動以后的秒殺）
“[GC”和“[Full GC”說明停頓類型，有Full代表的是Stop-The-World的；
“[DefNew”、“[Tenured”和“[Perm”表示GC發(fā)生的區(qū)域；
方括號內(nèi)部的“3324K -> 152K(3712K)” 含義是 “GC前該內(nèi)存已使用容量 -> GC后該內(nèi)存區(qū)域已使用容量(該區(qū)域總?cè)萘?”;
方括號之外的“3324K -> 152K(11904)” 含義是 “GC前Java堆已使用容量 -> GC后Java堆已使用容量(Java堆總?cè)萘?”;
再往后“0.0025925 secs”表示該內(nèi)存區(qū)域GC所占用的時間；
3.5.9 垃圾收集器參數(shù)總結(jié)垃圾收集器參數(shù)總結(jié)
-XX:+啟用選項
-XX:- 不啟用選項
-XX:
-XX:
| 參數(shù) | 描述 |
|---|---|
| UserSerialGC | 虛擬機在client模式下的默認值，打開此開關后，用于Serial+Serial Old的收集器組合進行內(nèi)存回收 |
| UserParNewGC | 打開此開關 使用ParNew + Serial Old收集器組合進行內(nèi)存回收 |
| UseConcMarkSweepGC | 打開此開關，使用ParNew+CMS+Serial Old收集器組合進行內(nèi)存回收。Serial Old在CMS收集器出現(xiàn)concurrent Mode Failure 失敗后的后備收集器 |
| UseParallelGC | 在server模式下的默認值，打開此開關后使用Scavenge+Serial Old收集器組合進行回收 |
| UseParallelOldGC | 打開此開關后使用 Parallel Scavenge+Parallel Old收集器組合進行內(nèi)存回收 |
| SurvivorRatio | 新生代中Eden區(qū)域與Survivor區(qū)域的比值，默認為8，表示Eden:Survivor=8:1 |
| PretenureSizeThreshold | 直接晉升到老年代對象的大小，設置這個參數(shù)后大于這個參數(shù)的對象直接在老年代中分配 |
| MaxTenuringThreshold | 晉升老年代對象的年齡,每個對象堅持一次MnorGC年齡就加一，當超過這個參數(shù)值就進入老年代 |
| UseAdaptiveSizePolicy | 動態(tài)調(diào)整java堆各個區(qū)域的大小以及進入老年代的年齡 |
| HandlePromotionFailure | 是否允許分配擔保失敗，即老年代剩余空間不足以應付新生代整個對象都存活的特殊情況 |
| ParalleGCThreads | 設置并行GC時進行內(nèi)存回收的線程數(shù) |
| GCTimeratio | GC時間占總時間比率，默認值為99，允許1%的GC時間。只在Parallel Seavenge收集器時生效 |
| MaxGCPauseMillis | 設置GC的最大停頓時間，只在Parallel Seavenge收集器時生效 |
| CMSInitiatingOccupancyFration | 設置CMS老年代空間被使用多少后觸發(fā)GC，默認值為68%，只在CMS收集器時生效 |
| UseCMSCompactAtFullCollection | 設置CMS收集器完成垃圾收集后是否需要進行一次碎片整理，只在CMS垃圾收集器時生效 |
| CMSFullGCBeforeCompaction | 設置CMS收集器進行若干次垃圾收集后再啟動一次內(nèi)存碎片整理，只在CMS垃圾收集器時生效 |
對象優(yōu)先在新生代分配
大對象直接進入老年代
長期存活的對象將進入老年代
動態(tài)對象年齡判斷：如果在Survivor空間中相同年齡所有對象大小總和大于Survivor空間的一半，大于或等于該年齡的對象直接進入老年代。
空間分配擔保：發(fā)生Minor GC前，虛擬機會先檢查老年代最大可用連續(xù)空間是否大于新生代所有對象總空間，如果不成立，虛擬機會查看HandlePromotionFailure設置值是否允許擔保失敗，如果允許繼續(xù)檢查老年代最大可用的連續(xù)空間是否大于歷次晉升到老年代的平均大小，如果大于會嘗試進行一次Minor GC；如果小于或者不允許冒險，會進行一次Full GC。
3.6.1 對象優(yōu)先在eden分配大多數(shù)情況下，對象優(yōu)先在新生代的Eden區(qū)分配。
當Eden區(qū)沒有足夠的空間時，虛擬機將發(fā)起一次Minor GC。
Minor GC與Full GC。
Minor GC：新生代GC，非常頻繁，回收速度快。
Fulll GC：老年代GC，又稱為Major GC，經(jīng)常會伴隨一次Minor GC，速度比較慢。
3.6.2 大對象直接進入老年代大對象是指需要大量連續(xù)的內(nèi)存空間的Java對象,最典型的大對象就是那種很長的字符串以及數(shù)組。
虛擬機提供了一個參數(shù)：PretenureSizeThreshold，大于這個參數(shù)的對象將直接在老年代分配。
3.6.3 長期存活的對象將進入老年代虛擬機給每個對象定義了一個對象年齡計數(shù)器（Age），對象每經(jīng)過一次Minor GC后仍然存活，且能被Survivor容納的話，年齡就 +1 ，當年齡增加到一定程度（默認為15），就會被晉升到老年代中，這個閾值可以通過參數(shù) MaxTenuringThreshold 來設置。
4.動態(tài)對象年齡的判定
3.6.4 動態(tài)對象年齡判定如果在Survivor空間中相同年齡所有對象大小的總和大于Survivor空間的一半，年齡大于或等于該年齡的對象就可以直接進入老年代。
3.6.5 空間分配擔保為了更好的適應不同程序的內(nèi)存狀況，對象年齡不是必須到達閾值才會進入老年代。
只要老年代的連續(xù)空間大于新生代對象總大小或者歷次晉升的平均大小就會進行Minor GC，否則將進行Full GC。
問題為什么程序要跑到安全點時停下來？
不設置安全點，而讓每一條指令都產(chǎn)生Oop(Ordinary Object Pointer)會需要大量的額外空間，增大GC的空間成本。設置了合適的安全點，有助于虛擬機得知對象引用所在的地方，因此有利于GC對“即將回收”的對象進行掃描。
最后上一張本章結(jié)構(gòu)圖
圖片來源于網(wǎng)絡如有侵權(quán)請私信刪除
《深入理解Java虛擬機：JVM高級特性與最佳實踐_周志明.高清掃描版.pdf》
下載地址：鏈接：http://pan.baidu.com/s/1miBQCBY 密碼：9kbn
推薦閱讀《深入理解Java虛擬機》（一）Java虛擬機發(fā)展史
《深入理解Java虛擬機》（二）Java虛擬機運行時數(shù)據(jù)區(qū)
《深入理解Java虛擬機》（三）垃圾收集器與內(nèi)存分配策略
《深入理解Java虛擬機》（四）虛擬機性能監(jiān)控與故障處理工具
《深入理解Java虛擬機》（五）JVM調(diào)優(yōu) - 工具
《深入理解Java虛擬機》（六）堆內(nèi)存使用分析，GC 日志解讀
Contact作者：鵬磊
出處：http://www.ymq.io
Email：admin@souyunku.com
版權(quán)歸作者所有，轉(zhuǎn)載請注明出處
Wechat：關注公眾號，搜云庫，專注于開發(fā)技術(shù)的研究與知識分享
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/67523.html
摘要：目錄往期博客課堂篇初識常量池簡單理解字符串常量池靜態(tài)常量池大整型常量池為什么要了解垃圾收集和內(nèi)存分配如何判斷對象已死引用計數(shù)算法可達性分析算法之后引用的擴充回收方法區(qū)垃圾收集算法分代收集理論標記清除標記復制標記整理對象分 ...
摘要：看來還是功力不夠，索性拆成了六篇文章，分別從自動內(nèi)存管理機制類文件結(jié)構(gòu)類加載機制字節(jié)碼執(zhí)行引擎程序編譯與代碼優(yōu)化高效并發(fā)六個方面來做更加細致的介紹。本文先說說虛擬機的自動內(nèi)存管理機制。在類加載檢查通過后，虛擬機將為新生對象分配內(nèi)存。 歡迎關注微信公眾號：BaronTalk，獲取更多精彩好文！ 書籍真的是常讀常新，古人說「書讀百遍其義自見」還是蠻有道理的。周志明老師的這本《深入理解 Ja...
摘要：虛擬機所處的區(qū)域，則表示它是屬于新生代收集器還是老年代收集器。虛擬機總共運行了分鐘，其中垃圾收集花掉分鐘，那么吞吐量就是。收集器線程所占用的數(shù)量為。 本文主要從GC（垃圾回收）的角度試著對jvm中的內(nèi)存分配策略與相應的垃圾收集器做一個介紹。 注：還是老規(guī)矩，本著能畫圖就不BB原則，盡量將各知識點通過思維導圖或者其他模型圖的方式進行說明。文字僅記錄額外的思考與心得，以及其他特殊情況 內(nèi)存...
摘要：第章內(nèi)存區(qū)域與內(nèi)存溢出異常運行時數(shù)據(jù)區(qū)域虛擬機在執(zhí)行程序的過程中會把它所管理的內(nèi)存劃分為若干個不同的數(shù)據(jù)區(qū)域。即對象指向它的類元數(shù)據(jù)的指針，虛擬機通過這個指針來確定這個對象是哪個類的實例。 第2章 Java內(nèi)存區(qū)域與內(nèi)存溢出異常 2.2 運行時數(shù)據(jù)區(qū)域 Java虛擬機在執(zhí)行Java程序的過程中會把它所管理的內(nèi)存劃分為若干個不同的數(shù)據(jù)區(qū)域。根據(jù)《Java虛擬機規(guī)范（Java SE 7版）...
摘要：堆內(nèi)存使用分析，垃圾收集器日志解讀重要的東東在中，對象實例都是在堆上創(chuàng)建。機制是由提供，用來清理需要清除的對象，回收堆內(nèi)存。在中，是由一個被稱為垃圾回收器的守護線程執(zhí)行的。 堆內(nèi)存使用分析，垃圾收集器 GC 日志解讀 重要的東東 在Java中，對象實例都是在堆上創(chuàng)建。一些類信息，常量，靜態(tài)變量等存儲在方法區(qū)。堆和方法區(qū)都是線程共享的。 GC機制是由JVM提供，用來清理需要清除的對象，...
閱讀 1629·2021-10-25 09:44
閱讀 3011·2021-09-04 16:48
閱讀 1699·2019-08-30 15:44
閱讀 2573·2019-08-30 15:44
閱讀 1789·2019-08-30 15:44
閱讀 2894·2019-08-30 14:14
閱讀 3025·2019-08-30 13:00
閱讀 2224·2019-08-30 11:09
