這篇文章主要講解了“如何理解JVM和垃圾回收”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“如何理解JVM和垃圾回收”吧！

在蓬江等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè) 網(wǎng)站設(shè)計(jì)制作按需網(wǎng)站策劃,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站制作,全網(wǎng)營銷推廣,外貿(mào)網(wǎng)站制作,蓬江網(wǎng)站建設(shè)費(fèi)用合理。

JVM的發(fā)展

就跟我們用三方庫一樣，同樣的功能有不同的實(shí)現(xiàn)。JVM也是一樣的，第一款JVM是Sun公司的Classic VM，JDK1.2之前JVM都是采用的Classic VM，而之后，逐漸被我們都知道的HotSpot給替代，直到JDK1.4，Classic VM才完全被棄用。

HotSpot應(yīng)該是目前使用最廣泛的虛擬機(jī)（自信點(diǎn)，把應(yīng)該去掉），也是OpenJDK中所帶的虛擬機(jī)。但是你可能不知道，HotSpot最開始并不是由Sun公司開發(fā)，而是由一家小公司設(shè)計(jì)并實(shí)現(xiàn)的，而且最初也不是為Java語言設(shè)計(jì)的。Sun公司看到了這個(gè)虛擬機(jī)在JIT上的優(yōu)勢，于是就收購了這家公司，從而獲得了HotSpot VM。

運(yùn)行時(shí)內(nèi)存區(qū)域

可能你經(jīng)歷過被靈魂拷問是什么滋味，如果線上發(fā)生了OOM（Out Of Memory），該怎么排查？如果要你來對(duì)一個(gè)JVM的運(yùn)行參數(shù)進(jìn)行調(diào)優(yōu)，你該怎么做？

不像C++可以自己來主宰內(nèi)存，同時(shí)扮演上帝和最底層勞工的角色，Java里我們把內(nèi)存管理交給了JVM，如果我們不能了解其中具體的運(yùn)行時(shí)內(nèi)存分布以及垃圾回收的原理，那等到問題真正出現(xiàn)了，很可能就無從查起。這也是要深入的了解JVM的必要性。

Java在運(yùn)行時(shí)會(huì)將內(nèi)存分成如下幾個(gè)區(qū)域進(jìn)行管理，堆、方法區(qū)、虛擬機(jī)棧、本地方法棧和程序計(jì)數(shù)器。

堆

堆（Java Heap）是JVM所管理的內(nèi)存中最大的一塊了。我們平常開發(fā)中使用new關(guān)鍵字來進(jìn)行實(shí)例化的對(duì)象幾乎都會(huì)在堆中分配內(nèi)存，所有線程都可以共享被分配在堆上的對(duì)象。

堆也是JVM垃圾回收的主要區(qū)域，正因?yàn)槔厥盏姆执鷻C(jī)制，其實(shí)堆中還可以分為更細(xì)的新生代、老年代。GC這塊后面會(huì)細(xì)講。

那為什么是幾乎呢？在JVM本身的規(guī)范中是規(guī)定了所有的對(duì)象都會(huì)在堆上分配內(nèi)存的，但是隨著JIT（Just In Time）編譯器和逃逸分析技術(shù)的成熟，所有對(duì)象都在堆上分配內(nèi)存就變得沒有那么絕對(duì)了。

JIT編譯器

不知道你有沒有聽說過，二八定律在我們的程序中也同樣適用，那就是20%的代碼占用了系統(tǒng)運(yùn)行中80%的資源。在我們寫的代碼中，就可能會(huì)存在一些熱點(diǎn)代碼，頻繁的被調(diào)用。除了被頻繁的調(diào)用的代碼，還有被執(zhí)行多次的循環(huán)體也算熱點(diǎn)代碼。

那此時(shí)JIT編譯器就會(huì)對(duì)這部分的代碼進(jìn)行優(yōu)化，將它們編譯成Machine Code，并做一些對(duì)應(yīng)的優(yōu)化。不熟悉的同學(xué)可能會(huì)說，我們的代碼不都已經(jīng)被編譯成了字節(jié)碼了嗎？怎么又被編譯成了Machine Code？

因?yàn)樽止?jié)碼只是一個(gè)中間狀態(tài)，真正的運(yùn)行是JVM在運(yùn)行的時(shí)候，就跟解釋型語言一樣將字節(jié)碼逐條的翻譯成了Machine Code，這個(gè)Machine Code才是操作系統(tǒng)能夠識(shí)別直接運(yùn)行的指令。而JIT就會(huì)把編譯好的熱點(diǎn)代碼所對(duì)應(yīng)的Machine Code保存下來， 下載再調(diào)用時(shí)就省去了從字節(jié)碼編譯到Machine Code的過程，效率自然也就提高了。

逃逸分析

我們剛剛提到過，Java中幾乎所有的對(duì)象都在堆上分配空間，堆中的內(nèi)存空間是所有線程共享的，所以在多線程下才需要去考慮同步的相關(guān)問題。那如果這個(gè)變量是個(gè)局部變量，只會(huì)在某個(gè)函數(shù)中被訪問到呢？

這種局部變量就是未逃逸的變量，而這個(gè)變量如果在其他的地方也能被訪問到呢？這說明這個(gè)變量逃逸出了當(dāng)前的作用域。通過逃逸分析我們可以知道哪些變量沒有逃逸出當(dāng)前作用域，那這個(gè)對(duì)象內(nèi)存就可以在棧中分配，隨著調(diào)用的結(jié)束，隨著線程的繼續(xù)執(zhí)行完成，棧空間被回收，這個(gè)局部變量分配的內(nèi)存也會(huì)一起被回收。

方法區(qū)

方法區(qū)存放了被加載的Class信息、常量、靜態(tài)變量和JIT編譯之后的結(jié)果等數(shù)據(jù)，與堆一樣，方法區(qū)也是被所有線程共享的內(nèi)存區(qū)域。但與堆不同，相對(duì)于堆的GC力度，這塊的垃圾回收力度可以說是小了非常多，但是仍然有針對(duì)常量的GC。

虛擬機(jī)棧

虛擬機(jī)棧是線程私有的，所以在多線程下不需要做同步的操作，是線程安全的。當(dāng)每個(gè)方法執(zhí)行時(shí)，就會(huì)在當(dāng)前線程中虛擬機(jī)棧中創(chuàng)建一個(gè)棧幀，每個(gè)方法從調(diào)用到結(jié)束的過程，就對(duì)應(yīng)了棧幀在虛擬機(jī)棧中的入棧、出棧的過程。那自然而然，棧幀中應(yīng)該存放的就是方法的局部變量、操作數(shù)棧、動(dòng)態(tài)鏈接和對(duì)應(yīng)的返回信息。

不知道你遇到過在方法內(nèi)寫遞歸時(shí)，由于退出條件一直沒有達(dá)到，導(dǎo)致程序陷入了無限循環(huán)，然后就會(huì)看到程序拋出了一個(gè)StackOverflow的錯(cuò)誤。其所對(duì)應(yīng)的棧就是上面提到的操作數(shù)棧。

當(dāng)然這是在內(nèi)存足夠的情況下，如果內(nèi)存不夠，則會(huì)直接拋出OutOfMemory，也就是常說的OOM。

本地方法棧

本地方法棧的功能與虛擬機(jī)棧類似，區(qū)別在于虛擬機(jī)棧是服務(wù)于JVM中的Java方法，而本地方法棧則服務(wù)于Native的方法。

GC

其實(shí)堆中的區(qū)域還可以劃分為新生代和老年代，再分割的細(xì)一點(diǎn)，可以到Eden、From Survivor、To Survivor。首先分配的對(duì)象實(shí)例會(huì)到Eden區(qū)，在新生代這塊區(qū)域一般是最大的，與From Survivor的比例是8:1，當(dāng)然這個(gè)比例可以通過JVM參數(shù)來改變。而且當(dāng)分配的對(duì)象實(shí)體很大的時(shí)候?qū)?huì)直接進(jìn)入到老年代。

為什么要對(duì)堆進(jìn)行更加細(xì)致的內(nèi)存區(qū)域劃分，其實(shí)是為了讓垃圾回收更加的高效。

垃圾識(shí)別機(jī)制

那JVM是如何判斷哪些對(duì)象是“垃圾”需要被回收呢？我們就需要來了解一下JVM是如何來判斷哪些內(nèi)存需要進(jìn)行回收的。

引用計(jì)數(shù)

實(shí)現(xiàn)的思路是，給每個(gè)對(duì)象添加一個(gè)引用計(jì)數(shù)器，每當(dāng)有其他的對(duì)象引用了這個(gè)對(duì)象，就把引用計(jì)數(shù)器的值+1，如果一個(gè)對(duì)象的引用計(jì)數(shù)為0則說明沒有對(duì)象引用它。

乍一看是沒有問題的，那為什么Java并沒有采取這種呢？

想象一下這個(gè)場景，一個(gè)函數(shù)中定義了兩個(gè)對(duì)象O1和O2，然后O1引用了O2，O1又引用了O1，這樣一來，兩個(gè)對(duì)象的引用計(jì)數(shù)器都不為0，但是實(shí)際上這兩個(gè)對(duì)象再也不會(huì)被訪問到了。

所以我們需要另外一種方案來解決這個(gè)問題。

可達(dá)性分析

可達(dá)性分析可以理解為一棵樹的遍歷，根節(jié)點(diǎn)是一個(gè)對(duì)象，而其子節(jié)點(diǎn)是引用了當(dāng)前對(duì)象的對(duì)象。從根節(jié)點(diǎn)開始做遍歷，如果發(fā)現(xiàn)從所有根節(jié)點(diǎn)出發(fā)的遍歷都已經(jīng)完成了，但是仍然有對(duì)象沒有被訪問到，那么說明這些對(duì)象是不可用的，需要將內(nèi)存回收掉。

這些根節(jié)點(diǎn)有個(gè)名字叫做GC Roots，哪些資源可以被當(dāng)作GC Roots呢？

• 棧幀中的局部變量所引用的對(duì)象

• 方法區(qū)中類靜態(tài)屬性所引用的對(duì)象

• 方法區(qū)中常量所引用的對(duì)象

• 本地方法棧所引用的對(duì)象

我們剛剛聊過，在引用計(jì)數(shù)中，如果其引用計(jì)數(shù)器的值為0，則占用的內(nèi)存會(huì)被回收掉。而在可達(dá)性分析中，如果沒有某個(gè)對(duì)象沒有任何引用，它也不一定會(huì)被回收掉。

垃圾回收算法

聊完了JVM如何判斷一個(gè)對(duì)象是否需要回收，接下來我們?cè)倭囊幌翵VM是如何進(jìn)行回收的。

標(biāo)記-清除

顧名思義，其過程分為兩個(gè)階段，分別是標(biāo)記和清除。首先標(biāo)記出所有需要回收的對(duì)象，然后統(tǒng)一對(duì)標(biāo)記的對(duì)象進(jìn)行回收。這個(gè)算法的十分的局限，首先標(biāo)記和清除的兩個(gè)過程效率都不高，而且這樣的清理方式會(huì)產(chǎn)生大量的內(nèi)存碎片，什么意思呢？

就是雖然總體看起來還有足夠的剩余內(nèi)存空間，但是他們都是以一塊很小的內(nèi)存分散在各個(gè)地方。如果此時(shí)需要為一個(gè)大對(duì)象申請(qǐng)空間，即使總體上的內(nèi)存空間足夠，但是JVM無法找到一塊這么大的連續(xù)內(nèi)存空間，就會(huì)導(dǎo)致觸發(fā)一次GC。

復(fù)制

其大致的思路是，將現(xiàn)有的內(nèi)存空間分為兩半A和B，所有的新對(duì)象的內(nèi)存都在A中分配，然后當(dāng)A用完了之后，就開始對(duì)象存活判斷，將A中還存活的對(duì)象復(fù)制到B去，然后一次性將A中的內(nèi)存空間回收掉。

這樣一來就不會(huì)出現(xiàn)使用標(biāo)記-清除所造成的內(nèi)存碎片的問題了。但是，它仍然有自己的不足。那就是以內(nèi)存空間縮小了一半為代價(jià)，而在某些情況下，這種代價(jià)其實(shí)是很高的。

堆中新生代就是采用的復(fù)制算法。剛剛提到過，新生代被分為了Eden、From Survivor、To Survivor，由于幾乎所有的新對(duì)象都會(huì)在這里分配內(nèi)存，所以Eden區(qū)比Survivor區(qū)要大很多。因此Eden區(qū)和Survivor區(qū)就不需要按照復(fù)制算法默認(rèn)的1:1的來分配內(nèi)存。

在HotSpot中Eden和Survivor的比例默認(rèn)是8:1，也就意味著只有10%的空間會(huì)被浪費(fèi)掉。

看到這你可能會(huì)發(fā)現(xiàn)一個(gè)問題。

既然你的Eden區(qū)要比Survivor區(qū)大這么多，要是一次GC之后的存活對(duì)象的大小大于Survivor區(qū)的總大小該怎么處理？

的確，在新生代GC時(shí)，最壞的情況就是Eden區(qū)的所有對(duì)象都是存活的，那這個(gè)JVM會(huì)怎么處理呢？這里需要引入一個(gè)概念叫做內(nèi)存分配擔(dān)保。

當(dāng)發(fā)生了上面這種情況，新生代需要老年代的內(nèi)存空間來做擔(dān)保，把Survivor存放不下的對(duì)象直接存進(jìn)老年代中。

標(biāo)記-整理

標(biāo)記-整理其GC的過程與標(biāo)記-清楚是一樣的，只不過會(huì)讓所有的存活對(duì)象往同一邊移動(dòng)，這樣一來就不會(huì)像標(biāo)記-整理那樣留下大量的內(nèi)存碎片。

分代收集

這也是當(dāng)前主流虛擬機(jī)所采用的算法，其實(shí)就是針對(duì)不同的內(nèi)存區(qū)域的特性，使用上面提到過的不同的算法。

例如新生代的特性是大部分的對(duì)象都是需要被回收掉的，只有少量對(duì)象會(huì)存活下來。所以新生代一般都是采用復(fù)制算法。

而老年代屬于對(duì)象存活率都很高的內(nèi)存空間，則采用標(biāo)記-清除和標(biāo)記-整理算法來進(jìn)行垃圾回收。

垃圾收集器

新生代收集器

聊完了垃圾回收的算法，我們需要再了解一下GC具體是通過什么落地的， 也就是上面的算法的實(shí)際應(yīng)用。

Serial

Serial采用的是復(fù)制算法的垃圾收集器，而且是單線程運(yùn)作的。也就是說，當(dāng)Serial進(jìn)行垃圾收集時(shí)，必須要暫停其他所有線程的工作，直到垃圾收集完成，這個(gè)動(dòng)作叫STW（Stop The World） 。Golang中的GC也會(huì)存在STW，在其標(biāo)記階段的準(zhǔn)備過程中會(huì)暫停掉所有正在運(yùn)行的Goroutine。

而且這個(gè)暫停動(dòng)作對(duì)用戶來說是不可見的，用戶可能只會(huì)知道某個(gè)請(qǐng)求執(zhí)行了很久，沒有經(jīng)驗(yàn)的話是很難跟GC掛上鉤的。

但是從某些方面來看，如果你的系統(tǒng)就只有單核，那么Serial就不會(huì)存在線程之間的交互的開銷，可以提高GC的效率。這也是為什么Serial仍然是Client模式下的默認(rèn)新生代收集器。

ParNew

ParNew與Serial只有一個(gè)區(qū)別，那就是ParNew是多線程的，而Serial是單線程的。除此之外，其使用的垃圾收集算法和收集行為完全一樣。

該收集器如果在單核的環(huán)境下，其性能可能會(huì)比Serial更差一些，因?yàn)閱魏藷o法發(fā)揮多線程的優(yōu)勢。在多核環(huán)境下，其默認(rèn)的線程與CPU數(shù)量相同。

Parallel Scavenge

Parallel Scavenge是一個(gè)多線程的收集器，也是在server模式下的默認(rèn)垃圾收集器。上面的兩種收集器關(guān)注的重點(diǎn)是如何減少STW的時(shí)間，而Parallel Scavenge則更加關(guān)注于系統(tǒng)的吞吐量。

例如JVM已經(jīng)運(yùn)行了100分鐘，而GC了1分鐘，那么此時(shí)系統(tǒng)的吞吐量為(100 - 1)/100 = 99% 。

吞吐量和短停頓時(shí)間其側(cè)重的點(diǎn)不一樣，需要根據(jù)自己的實(shí)際情況來判斷。

高吞吐量

GC的總時(shí)間越短，系統(tǒng)的吞吐量則越高。換句話說，高吞吐量則意味著，STW的時(shí)間可能會(huì)比正常的時(shí)間多一點(diǎn)，也就更加適合那種不存在太多交互的后臺(tái)的系統(tǒng)，因?yàn)閷?duì)實(shí)時(shí)性的要求不是很高，就可以高效率的完成任務(wù)。

短停頓時(shí)間

STW的時(shí)間短，則說明對(duì)系統(tǒng)的響應(yīng)速度要求很高，因?yàn)橐脩纛l繁的交互。因?yàn)榈晚憫?yīng)時(shí)間會(huì)帶來較高的用戶體驗(yàn)。

老年代收集器

Serial Old

Serial Old是Serial的老年代版本，使用的標(biāo)記-整理算法， 其實(shí)從這看出來，新生代和老年代收集器的一個(gè)差別。

新生代：大部分的資源都是需要被回收

老年代：大部分的資源都不需要被回收

所以，新生代收集器基本都是用的復(fù)制算法，老年代收集器基本都是用的標(biāo)記-整理算法。

Serial Old也是給Client模式下JVM使用的。

Parallel Old

Parallel Old是Parallel Scavenge的老年代版本，也是一個(gè)多線程的、采用標(biāo)記-整理算法的收集器，剛剛討論過了系統(tǒng)吞吐量，那么在對(duì)CPU的資源十分敏感的情況下， 可以考慮Parallel Scavenge和Parallel Old這個(gè)新生代-老年代的垃圾收集器組合。

CMS

CMS全稱（Concurrent Mark Sweep），使用的是標(biāo)記-清除的收集算法。重點(diǎn)關(guān)注于最低的STW時(shí)間的收集器，如果你的應(yīng)用非常注重與響應(yīng)時(shí)間，那么就可以考慮使用CMS。

從圖中可以看出其核心的步驟：

• 首先會(huì)進(jìn)行初始標(biāo)記，標(biāo)記從GCRoots出發(fā)能夠關(guān)聯(lián)到的所有對(duì)象，此時(shí)需要STW，但是不需要很多時(shí)間

• 然后會(huì)進(jìn)行并發(fā)標(biāo)記，多線程對(duì)所有對(duì)象通過GC Roots Tracing進(jìn)行可達(dá)性分析，這個(gè)過程較為耗時(shí)

• 完成之后會(huì)重新標(biāo)記，由于在并發(fā)標(biāo)記的過程中，程序還在正常運(yùn)行，此時(shí)有些對(duì)象的狀態(tài)可能已經(jīng)發(fā)生了變化，所以需要STW，來進(jìn)行重新標(biāo)記，所用的時(shí)間大小關(guān)系為初始標(biāo)記 < 重新標(biāo)記 < 并發(fā)標(biāo)記。

• 標(biāo)記階段完成之后，開始執(zhí)行并發(fā)清楚。

CMS是一個(gè)優(yōu)點(diǎn)很明顯的的垃圾收集器，例如可以多線程的進(jìn)行GC，且擁有較低的STW的時(shí)間。但是同樣的，CMS也有很多缺點(diǎn)。

缺點(diǎn)

我們開篇也提到過，使用標(biāo)記-清除算法會(huì)造成不連續(xù)的內(nèi)存空間，也就是內(nèi)存碎片。如果此時(shí)需要給較大的對(duì)象分配空間，會(huì)發(fā)現(xiàn)內(nèi)存不足，重新觸發(fā)一次Full GC。

其次，由于CMS可能會(huì)比注重吞吐量的收集器占用更多的CPU資源，但是如果應(yīng)用程序本身就已經(jīng)對(duì)CPU資源很敏感了，就會(huì)導(dǎo)致GC時(shí)的可用CPU資源變少，GC的整個(gè)時(shí)間就會(huì)變長，那么就會(huì)導(dǎo)致系統(tǒng)的吞吐量降低。

G1

G1全稱Garbage First，業(yè)界目前對(duì)其評(píng)價(jià)很高，JDK9中甚至提議將其設(shè)置為默認(rèn)的垃圾收集器。我們前面講過，Parallel Scavenge更加關(guān)注于吞吐量，而CMS更加關(guān)注于更短的STW時(shí)間，那么G1就是在實(shí)現(xiàn)高吞吐的同時(shí)，盡可能的減少STW的時(shí)間。

我們知道，上面聊過的垃圾收集器都會(huì)把連續(xù)的堆內(nèi)存空間分為新生代、老年代，新生代則被劃分的更加的細(xì)，有Eden和兩個(gè)較小的Survivor空間，而且都是連續(xù)的內(nèi)存空間。而G1則與眾不同，它引入了新的概念，叫Region。

Region是一堆大小相等但是不連續(xù)的內(nèi)存空間，同樣是采用了分代的思想，但是不存在其他的收集器的物理隔離，屬于新生代和老年代的region分布在堆的各個(gè)地方。

上面H則代表大對(duì)象，也叫Humongous Object。為了防止大對(duì)象的頻繁拷貝，會(huì)直接的將其放入老年代。G1相比于其他的垃圾收集器有什么特點(diǎn)呢？

從宏觀上來看，其采用的是標(biāo)記-整理算法， 而從region到region來看，其采用的是復(fù)制算法的，所以G1在運(yùn)行期間不會(huì)像CMS一樣產(chǎn)生內(nèi)存碎片。

除此之外，G1還可以通過多個(gè)CPU，來縮短STW的時(shí)間，與用戶線程并發(fā)的執(zhí)行。并且可以建立可預(yù)測的停頓時(shí)間模型，讓使用者知道在某個(gè)時(shí)間片內(nèi)，消耗在GC上的時(shí)間不得超過多少毫秒。之所以G1能夠做到這點(diǎn)，是因?yàn)闆]像其余的收集器一樣收集整個(gè)新生代和老年代，而是在有計(jì)劃的避免對(duì)整個(gè)堆進(jìn)行全區(qū)域的垃圾收集。

總結(jié)

這個(gè)圖來自于參考中的博客，總結(jié)的很到位。

收集器	串行、并行or并發(fā)	新生代/老年代	算法	目標(biāo)	適用場景
Serial	串行	新生代	復(fù)制算法	響應(yīng)速度優(yōu)先	單CPU環(huán)境下的Client模式
Serial Old	串行	老年代	標(biāo)記-整理	響應(yīng)速度優(yōu)先	單CPU環(huán)境下的Client模式、CMS的后備預(yù)案
ParNew	并行	新生代	復(fù)制算法	響應(yīng)速度優(yōu)先	多CPU環(huán)境時(shí)在Server模式下與CMS配合
Parallel Scavenge	并行	新生代	復(fù)制算法	吞吐量優(yōu)先	在后臺(tái)運(yùn)算而不需要太多交互的任務(wù)
Parallel Old	并行	老年代	標(biāo)記-整理	吞吐量優(yōu)先	在后臺(tái)運(yùn)算而不需要太多交互的任務(wù)
CMS	并發(fā)	老年代	標(biāo)記-清除	響應(yīng)速度優(yōu)先	集中在互聯(lián)網(wǎng)站或B/S系統(tǒng)服務(wù)端上的Java應(yīng)用
G1	并發(fā)	both	標(biāo)記-整理+復(fù)制算法	響應(yīng)速度優(yōu)先	面向服務(wù)端應(yīng)用，將來替換CMS

感謝各位的閱讀，以上就是“如何理解JVM和垃圾回收”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)如何理解JVM和垃圾回收這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

文章標(biāo)題：如何理解JVM和垃圾回收
網(wǎng)址分享：http://vcdvsql.cn/article4/jhgeoe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站策劃、虛擬主機(jī)、網(wǎng)站制作、Google、App開發(fā)、網(wǎng)站排名

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)