cms垃圾收集器初始標記

1、怎麼看我當前運行的是哪個垃圾收集器

【問題描述】：查找系統中佔用空間較大的文件【原因分析】：需要刪除無用文件,進行系統瘦身【簡易步驟】：【360安全衛士】—【電腦清理】—【查找大文件】【解決方案】：1. 首先打開【360安全衛士】—【電腦清理】—【查找大文件】,選擇需要掃描的磁碟或者目錄,點擊掃描大文件（如圖1）圖12.勾選要刪除的文件,點擊刪除（如圖2）圖2

2、JVM的垃圾演算法有哪幾種

一、垃圾收集器概述

如上圖所示，垃圾回收演算法一共有7個，3個屬於年輕代、三個屬於年老代，G1屬於橫跨年輕代和年老代的演算法。

JVM會從年輕代和年老代各選出一個演算法進行組合，連線表示哪些演算法可以組合使用

二、各個垃圾收集器說明

1、Serial(年輕代）

年輕代收集器，可以和Serial Old、cms組合使用

採用復制演算法

使用單線程進行垃圾回收，回收時會導致Stop The World，用戶進程停止

client模式年輕代默認演算法

GC日誌關鍵字：DefNew(Default New Generation)

圖示（Serial+Serial Old)

2、ParNew(年輕代）

新生代收集器，可以和Serial Old、CMS組合使用

採用復制演算法

使用多線程進行垃圾回收，回收時會導致Stop The World，其它策略和Serial一樣

server模式年輕代默認演算法

使用-XX:ParallelGCthreads參數來限制垃圾回收的線程數

GC日誌關鍵字：ParNew(Parallel New Generation)

圖示（ParNew + Serail Old）

3、Paralle Scavenge(年輕代）

新生代收集器，可以和Serial Old、Parallel組合使用，不能和CMS組合使用

採用復制演算法

使用多線程進行垃圾回收，回收時會導致Stop The World

關注系統吞吐量

-XX:MaxGCPauseMillis：設置大於0的毫秒數，收集器盡可能在該時間內完成垃圾回收

-XX:GCTimeRatio：大於0小於100的整數，即垃圾回收時間占總時間的比率，設置越小則希望垃圾回收所佔時間越小，CPU能花更多的時間進行系統操作，提高吞吐量

-XX:UseAdaptiveSizePolicy：參數開關，啟動後系統動態自適應調節各參數，如-Xmn、-XX：SurvivorRatio等參數，這是和ParNew收集器重要的區別

GC日誌關鍵字：PSYoungGen

4、Serial Old(年老代）

年老代收集器，可以和所有的年輕代收集器組合使用(Serial收集器的年老代版本）

採用 」標記-整理「演算法，會對垃圾回收導致的內存碎片進行整理

使用單線程進行垃圾回收，回收時會導致Stop The World，用戶進程停止

GC日誌關鍵字：Tenured

圖示（Serial+Serial Old)

5、Parallel Old(年老代）

年老代收集器，只能和Parallel Scavenge組合使用(Parallel Scavenge收集器的年老代版本）

採用 」標記-整理「演算法，會對垃圾回收導致的內存碎片進行整理

關注吞吐量的系統可以將Parallel Scavenge+Parallel Old組合使用

GC日誌關鍵字：ParOldGen

圖示(Parallel Scavenge+Parallel Old)

6、CMS(Concurrent Mark Sweep年老代）

年老代收集器，可以和Serial、ParNew組合使用

採用 」標記-清除「演算法，可以通過設置參數在垃圾回收時進行內存碎片的整理
1、：默認開啟，FullGC時進行內存碎片整理，整理時用戶進程需停止，即發生Stop The World
2、CMSFullGCsBeforeCompaction：設置執行多少次不壓縮的Full GC後，執行一個帶壓縮的（默認為0，表示每次進入Full GC時都進行碎片整理）

CMS是並發演算法，表示垃圾回收和用戶進行同時進行，但是不是所有階段都同時進行，在初始標記、重新標記階段還是需要Stop the World。CMS垃圾回收分這四個階段
1、初始標記（CMS Initial mark）  Stop the World 僅僅標記一下GC Roots能直接關聯到的對象，速度快
2、並發標記（CMS concurrent mark） 進行GC Roots Tracing，時間長，不發生用戶進程停頓
3、重新標記（CMS remark）  Stop the World 修正並發標記期間因用戶程序繼續運行導致標記變動的那一部分對象的標記記錄，停頓時間較長，但遠比並發標記時間短
4、並發清除（CMS concurrent sweep） 清除的同時用戶進程會導致新的垃圾，時間長，不發生用戶進程停頓

適合於對響應時間要求高的系統

GC日誌關鍵字：CMS-initial-mark、CMS-concurrent-mark-start、CMS-concurrent-mark、CMS-concurrent-preclean-start、CMS-concurrent-preclean、CMS-concurrent-sweep、CMS-concurrent-reset等等

缺點
1、對CPU資源非常敏感
2、CMS收集器無法處理浮動垃圾，即清除時用戶進程同時產生的垃圾，只能等到下次GC時回收
3、因為是使用「標記-清除」演算法，所以會產生大量碎片

圖示

7、G1

G1收集器由於沒有使用過，所以從網上找了一些教程供大家了解

並行與並發

分代收集

空間整合

可預測的停頓

3、java cms 初始標記 為什麼 停止 應用線程

。表面上看起來是相同的任務，其實是不相同的
boolean runflag=true; 這個標志每個對象都有一個，你改變了其中一個以後，其它線程並不會受到影響；

4、cms垃圾回收演算法在gc過程中哪幾個階段會暫停

P

5、如何指定定java cms垃圾回收

如果你的JAVA應用程序有以下幾個特點，那麼可以使用Concurrent Mark Sweep (CMS) 垃圾收集器。
希望JAVA垃圾回收器回收垃圾的時間盡可能短；
應用運行在多CPU的機器上，有足夠的CPU資源；
有比較多生命周期長的對象；
希望應用的響應時間短。

6、cms垃圾回收演算法在gc過程中哪幾個階段會暫停應用縣城

中間調整過幾次，先搞了幾台機器做了驗證，後來逐步推廣的。
1、調大heap區，由原來的4g，調整到5g，young區的大小不變，還是2g，這時候old區就由2g變為3g了（這樣保證old區有足夠的空間）；
2、設置-XX：UseCMSInitiatingOccupancyOnly，其實這個不關這個問題，只是發現半夜CMS進行的有點頻繁，就禁止掉了悲觀策略；
3、設置CMS區回收的比例，從80%調整到75%，讓old區盡早的進行，有足夠的空間剩餘；

為什麼要有GC（垃圾回收）？

JVM通過GC來回收堆和方法區中的內存，GC的基本原理就是找到程序中不再被使用的對象，然後回收掉這些對象佔用的內存。

主要的收集器有哪些？
引用計數器和跟蹤計數器兩種。
引用計數器記錄對象是否被引用，當計數器為零時，說明對象已經不再被使用，可以進行回收。java中的對象有復雜的引用關系，不是很適合引用計數器，所以sun jdk中並沒有實現這種GC方式。
跟蹤收集器，全局記錄數據的引用狀態，基於一定的條件觸發。執行的時候，從根集合開始掃描對象的引用關系，主要有復制（copying）、標記-清除（Mark-Sweep）、標記-壓縮(Mark-Compact)那種演算法。

7、java垃圾收集器收集標准

Java垃圾收集器與類的finalize()方法總結

1．垃圾收集器的工作目標是回收已經無用的對象的內存空間，從而避免內存滲漏體的產生，節省內存資源，避免程序代碼的崩潰。

2．垃圾收集器判斷一個對象的內存空間是否無用的標準是：如果該對象不能再被程序中任何一個"活動的部分"所引用，此時我們就說，該對象的內存空間已經無用。所謂"活動的部分"，是指程序中某部分參與程序的調用，正在執行過程中，尚未執行完畢。

3．垃圾收集器線程雖然是作為低優先順序的線程運行，但在系統可用內存量過低的時候，它可能會突發地執行來挽救內存資源。當然其執行與否也是不可預知的。

4．垃圾收集器不可以被強制執行，但程序員可以通過調用System. gc方法來建議執行垃圾收集器。
5．不能保證一個無用的對象一定會被垃圾收集器收集，也不能保證垃圾收集器在一段Java語言代碼中一定會執行。因此在程序執行過程中被分配出去的內存空間可能會一直保留到該程序執行完畢，除非該空間被重新分配或被其他方法回收。由此可見，完全徹底地根絕內存滲漏體的產生也是不可能的。但是請不要忘記，Java的垃圾收集器畢竟使程序員從手工回收內存空間的繁重工作中解脫了出來。設想一個程序員要用C或C++來編寫一段10萬行語句的代碼，那麼他一定會充分體會到Java的垃圾收集器的優點！

6．同樣沒有辦法預知在一組均符合垃圾收集器收集標準的對象中，哪一個會被首先收集。

7．循環引用對象不會影響其被垃圾收集器收集。

8．可以通過將對象的引用變數（reference variables，即句柄handles）初始化為null值，來暗示垃圾收集器來收集該對象。但此時，如果該對象連接有事件監聽器（典型的 AWT組件），那它還是不可以被收集。所以在設一個引用變數為null值之前，應注意該引用變數指向的對象是否被監聽，若有，要首先除去監聽器，然後才可以賦空值。

9．每一個對象都有一個finalize( )方法，這個方法是從Object類繼承來的。

10．finalize( )方法用來回收內存以外的系統資源，就像是文件處理器和網路連接器。該方法的調用順序和用來調用該方法的對象的創建順序是無關的。換句話說，書寫程序時該方法的順序和方法的實際調用順序是不相乾的。請注意這只是finalize( )方法的特點。

11．每個對象只能調用finalize( )方法一次。如果在finalize( )方法執行時產生異常（exception），則該對象仍可以被垃圾收集器收集。

12．垃圾收集器跟蹤每一個對象，收集那些不可到達的對象（即該對象沒有被程序的任何"活的部分"所調用），回收其佔有的內存空間。但在進行垃圾收集的時候，垃圾收集器會調用finalize( )方法，通過讓其他對象知道它的存在，而使不可到達的對象再次"復甦"為可到達的對象。既然每個對象只能調用一次finalize( )方法，所以每個對象也只可能"復甦"一次。

13．finalize( )方法可以明確地被調用，但它卻不能進行垃圾收集。

14．finalize( )方法可以被重載（overload），但只有具備初始的finalize( )方法特點的方法才可以被垃圾收集器調用。

15．子類的finalize( )方法可以明確地調用父類的finalize( )方法，作為該子類對象的最後一次適當的操作。但Java編譯器卻不認為這是一次覆蓋操作（overriding），所以也不會對其調用進行檢查。

16．當finalize( )方法尚未被調用時，System. runFinalization( )方法可以用來調用finalize( )方法，並實現相同的效果，對無用對象進行垃圾收集。

17．當一個方法執行完畢，其中的局部變數就會超出使用范圍，此時可以被當作垃圾收集，但以後每當該方法再次被調用時，其中的局部變數便會被重新創建。

18．Java語言使用了一種"標記交換區的垃圾收集演算法"。該演算法會遍歷程序中每一個對象的句柄，為被引用的對象做標記，然後回收尚未做標記的對象。所謂遍歷可以簡單地理解為"檢查每一個"。

19．Java語言允許程序員為任何方法添加finalize( )方法，該方法會在垃圾收集器交換回收對象之前被調用。但不要過分依賴該方法對系統資源進行回收和再利用，因為該方法調用後的執行結果是不可預知的。 通過以上對垃圾收集器特點的了解，你應該可以明確垃圾收集器的作用，和垃圾收集器判斷一塊內存空間是否無用的標准。簡單地說，當你為一個對象賦值為null並且重新定向了該對象的引用者，此時該對象就符合垃圾收集器的收集標准。

8、C#中關於垃圾收集器的問題

該對象已經被析構。

ObjectReliveTest.Program.relived = this; //復活
執行了對象復甦。但是，該對象已經被執行了終止化，使用他可能會導致不可預期的結果。（參考《.net框架程序設計》，p489）

如果被析構，那麼，為什麼CLR允許無意義的對象調用方法，而不是拋出異常？

既然是「不可預期的結果」，所以必須通過大量實驗來進行觀察。你可以多測試幾次，你會發現某幾次clr會拋出nullreference異常。

----------------------------------------------------------
~Reliver()
{
Console.WriteLine("正在析構復活類");
ObjectReliveTest.Program.relived = this; //復活
}
當對象的析構函數（finalize方法）被執行時，該對象的一個引用被放入了一個根中，從而使其又成為應用程序得一個可達對象。對象重新復甦以後，垃圾收集器不會再將其認為是可收集的對象，應用程序也可以自由的使用該對象。但是，該對象已經被執行了終止化，使用他可能會導致不可預期的結果。
換句話說，在對象執行了finalize方法以後，它的成員仍然可能被訪問。
因此應該這樣回答你這個問題：對象確實已經被析構，但是clr執行的這個析構，不是將對象從內存中抹掉，而是對它進行了特殊的標記，以便於在某一代齡的內存空間不足時流出空間，在此之前，應用程序仍然能夠訪問這個對象。 從這里也可以看出.net語言和c++的一些區別。

9、G1會成為新的默認垃圾收集器嗎？

Java只有一個垃圾收集器，而事實上它有4個。Java9中，仍有一個運行提議，關於替換由Java7引入的G1默認垃圾收集器（並行/吞吐量收集）的討論。
通常來說，G1被設計來更好地支持大於4GB的堆，並且不會造成頻繁的GC暫停，但當暫停發生時，往往會處理更長時間。