2. 程式人生 > >JVM GC之一找出不可達物件並回收

JVM GC之一找出不可達物件並回收

阿新 • • 發佈：2019-01-01
JAVA執行時資料區域   1、程式計數器：當前執行緒所執行的位元組碼的行號指示器。一個處理器只會執行一條執行緒中的指令，為了執行緒切換後能回覆到正確的執行位置，所以每條執行緒都需要一個獨立的計數器。各條執行緒之間互不影響，獨立儲存，屬於‘執行緒私有’記憶體。      2、java虛擬機器棧：描述的是JAVA方法執行的記憶體模型：每個方法執行的時候都會建立一個棧幀用於儲存區域性變量表、運算元棧、動態連結、方法出口等資訊。每個方法的被呼叫直至執行完成的過程，就對應著一個棧幀在虛擬機器中從入棧到出棧的過程。所以也是執行緒私有的。      3、本地方法棧：和java虛擬機器棧發揮的作用類似，只不過Java虛擬機器棧是為JAVA方法服務的，而本地方法棧是為Native方法服務。所以也是執行緒私有的。
      4、JAVA堆：JAVA堆是被所有執行緒共享的區域。所有的物件例項及陣列都要在堆上分配。      5、方法區：是各個執行緒共享的記憶體區域。主要儲存被虛擬機器載入的類資訊，常量、靜態變數、編譯後的位元組碼資料等。有一個別名：非堆。      6、執行時常量池：方法區的一部分，當然也是執行緒共享的咯。除了有類的版本、欄位、方法、介面等描述資訊外，還有一項資訊是常量池，用於存放各種字面量和符合引用。      7、直接記憶體：並不是虛擬機器執行時的資料區的一部分。是在NIO中基於通道和緩衝區的I/O方式，使用Native函式庫直接分配堆外記憶體。避免了JAVA堆和Native堆中來回複製資料。和（作業系統中記憶體頁的使用者空間和系統空間的虛擬映象類似）
 ======================================= 垃圾收集器      1、程式計數器、虛擬機器棧、本地方法棧三個區域隨執行緒而生，隨執行緒而滅。每一個棧幀中分配多少記憶體基本上是在類結構確定下來時就已知的，因此記憶體的分配和回收都具備確定性。因此不需要考慮回收問題，因為執行緒結束或者方法結束，記憶體自然就回收了。而Java堆和方法去不一樣，一個介面中的多個實現類需要的記憶體不一樣，一個方法中的多個分支也不一樣，只有在程式處於執行時才能知道建立哪些記憶體，所以這部分的記憶體的分配和回收都是動態的。      2、引用計數演算法 引用計數：每當被引用時引用計數加1，有引用斷開時引用計數減1.當引用計數為0時表示該物件可以被回收。
JVM並不是通過引用計數演算法來進行回收的，主要原因是很難解決物件之間的相互迴圈引用的問題。      3、根搜尋演算法：GC Roots JVM是通過根搜尋演算法判定物件演算法存活的。演算法的基本思路是：通過一系列的名為GC Roots （GC 根節點）的物件作為起始點，從這些節點開始向下搜尋，搜尋所走過的路徑，當一個物件到GC Roots沒有任何引用鏈相連（圖論說：從GC Roots到這個物件不可達）時， 證明此物件是不可用的。      4、可以作為GC Roots的物件      虛擬機器棧（棧幀中的本地變量表）中引用的物件。      方法區中的類靜態屬性引用的物件      方法區中的常量引用的物件      本地方法棧JNI中的引用的物件。 =========================================== 物件Life or death      1、根搜尋演算法中不可達的物件也並非是‘非死不可’的，暫時是‘緩刑’階段，要真正判斷一個物件死亡要經歷兩次標記過程：如果物件在進行根搜尋後發現物件不可達，那它將會進行被第一次標記並且進行篩選，篩選的條件是此物件是否有必要執行finalize()方法。當物件沒有覆蓋finalize()方法或者finalize()方法已經被虛擬機器掉用過，這兩種情況都視為‘沒有必要執行’。      如果物件被認為有必要執行finalize()方法，那麼這個方法會被放置在一個名為F-Queue的佇列之中，並在稍後由一條由虛擬機器自動建立的、低優先順序的Finalizer執行緒去執行。這裡的‘執行’也只是指虛擬機器會觸發這個方法，但並不承諾一定會執行。      finalize()方法是物件逃脫死亡命運的最後一次機會，稍後GC會對F-Queue中的物件進行第二次小規模的標記，如果物件在finalize()中重新與引用鏈上的任何一個物件建立了關聯，就會被移出‘即將回收’集合，如果沒有移出，那就真的離死亡不遠了。      finalize()方法只會被系統自動呼叫一次。 ============================================ 回收方法區（HotSpot虛擬機器中的永久代）      1、Java虛擬機器規範中說過可以不要求虛擬機器在方法區實行垃圾收集，在方法區進行垃圾回收的‘價效比’一般比較低。在堆中尤其是新生代中，常規的一次垃圾回收就可以回收70%--90%的空間，而永久代的垃圾收集效率遠低於此。      2、永久代的垃圾收集主要回收兩部分內容：廢棄常量和無用的類。   3、如果字串‘abc’進入了常量池，但是當前系統中沒有任何String物件引用‘abc’常量，也沒有其他地方引用了這個字面量，如果此時發生記憶體回收，而且必要的話 這個‘abc’常量就會被回收掉。      4、判斷無用的類必須同時滿足三個條件：           該類的所有例項都已經被回收，即JAVA堆中不存在該類的任何例項。           載入該類的ClassLoader已經被回收           載入該類的Class物件沒有任何地方引用，而且不能通過反射訪問。     5、在大量使用反射、動態代理、CGLib及動態生成JSP和頻繁自定義ClassLoader的場景需要虛擬機器自動解除安裝，以防止永久代不會溢位。 =================================================== 垃圾收集演算法：標記--清楚演算法、複製演算法、標記-整理演算法、分代收集演算法 1、標記--清除演算法      最基礎的演算法，分為標記和清除兩個階段：           標記：首先標記出需要清除的物件，標記的過程就是上面的物件Life or death。之所以說是基礎的演算法，是因為後續的演算法都是基於這個演算法改進的。      該演算法有兩個缺點：效率和空間問題（其實計算機最糾結的無外乎這兩個地方：時間和空間問題）。標記和清除的效率都不高。空間問題：標記清除之後會產生大量的碎片，可能會導致，當程式在以後的執行過程中需要分配較大的物件時無法找到足夠的連續記憶體而不得不提前觸發另一次收集動作。 2、複製演算法      複製演算法可以解決演算法1的效率問題。將可用記憶體按容量劃分成大小相等的兩塊，每次只使用其中的一塊。當這一塊的記憶體用完時，就吧還活著的物件複製到另一塊上面，然後再把已使用的記憶體一次性清楚乾淨。這樣使得每次都是對其中的一塊記憶體回收，記憶體分配時也不用考慮記憶體碎片問題，只要移動堆頂指標即可。但是代價是記憶體縮小為原來的一半。      現在的商業虛擬機器都採用這中演算法來回收新生代，因為IBM研究表明新生代的的物件98%都是朝生夕死的，所以不需要按照1:1的比例來劃分空間。      而是把記憶體分成一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden和其中的一塊Survivor空間。當回收時，把Eden和Survivor中還活著的物件一次性拷貝到Survivor空間中，最後清理掉Eden和Survivor空間。HotSpot預設Eden和Survivor空間的大小是8:1，這樣可以保證每次可用記憶體是90%（80%+10），只有10%是浪費的。      當Survivor空間不足時就要依賴老年代進行分配擔保（就是說 有大頭（老年代）在後面，才放心只留出10%來存放Eden和Survivor中活著的物件，萬一Survivor不足時還有老年代在後面撐腰）。 3、標記-整理演算法      複製演算法在物件存活率較高時就要執行交多的複製操作，效率會變低。重點是如果不想浪費掉50%的空間就需要有額外的空間進行擔保，以應對被使用的記憶體中有100%存活的極端情況，所以老年代一般不能直接使用這一演算法。因為老年代沒有其他的記憶體可擔保了。      根據老年代的特定，提出了 ‘標記--整理’演算法。原理是：標記過程仍然與‘標記--清除’演算法一樣，但是後續步驟不是直接對可回收物件進行清理，而是讓所有活著的物件都向一端移動，然後直接清理邊界以外的記憶體。 4、分代演算法      當前商業虛擬機器都採用這種演算法回收。沒有什麼新的思想，只是根據物件的存活週期把記憶體劃分成幾塊，一般是新生代和老生代。這樣可以根據各個年代的特定採用合適的演算法進行垃圾收集。      在新生代中，物件的存活週期較短，朝生夕死，採用複製演算法。只需要付出少量存活物件的複製成本就可以完成收集。      在老生代中，物件的存活率較高，沒有額外的空間對它進行分配擔保，必須使用‘標記--清除’或‘標記--整理’演算法進行回收。

相關推薦

JVM GC之一找出不可達物件並回收

JAVA執行時資料區域   1、程式計數器：當前執行緒所執行的位元組碼的行號指示器。一個處理器只會執行一條執行緒中的指令，為了執行緒切換後能回覆到正確的執行位置，所以每條執行緒都需要一個獨立的計數器

jvm原理四：利用可達性分析演算法GC怎麼判斷物件生存還是死亡，經過了幾次過濾，每次都做了什麼

經歷了2次標記過程，即2次過濾過程。第一次：如果物件在進行可達性分析後發現沒有GC Roots相連線的引用鏈，那它將會被第一次標記並且進行一次篩選，篩選的條件是此物件是否有必要執行finalize()方

GC roots如何判斷物件不可達

查詢記憶體中不再使用的物件 引用計數法 引用計數法就是如果一個物件沒有被任何引用指向，則可視之為垃圾。這種方法的缺點就是不能檢測到環的存在。 public class MyObject { public Object ref = nul

JVM快速找出耗記憶體大物件

問題 當我們的java應用執行時，突然出現記憶體佔用暴增，說明系統中存在長期佔用的物件無法回收，或者出現巨大的物件如何快速定位產生

JVM調優之jstack找出最耗cpu的線程並定位代碼

grep 輪詢 tin jstack stack ads OS 分享 bject jstack可以定位到線程堆棧，根據堆棧信息我們可以定位到具體代碼，所以它在JVM性能調優中使用得非常多。下面我們來一個實例找出某個Java進程中最耗費CPU的Java線程並定位堆棧信息，用到

【轉載】JVM系列二:GC策略&記憶體申請、物件衰老

  JVM裡的GC(Garbage Collection)的演算法有很多種，如標記清除收集器，壓縮收集器，分代收集器等等,詳見HotSpot VM GC 的種類        現在比較常用的是分代收集（generational colle

JVM GC回收策略 哪些物件可以被回收

GC需要解決三件事： 1、哪些物件可以被回收。 2、何時回收這些物件。 3、採用什麼樣的方式回收。 引用計數演算法： 應用案例：微軟的COM技術、使用Action Scrip3的FlashPlayer、Python語言及在遊戲指令碼領域被廣泛應用的Squirrel中。 描述：給物件中

JVM GC調優（2）-----GC演算法判定物件可以被回收（部分摘自深入理解Java虛擬機器）

這次我們介紹JVM中的GC演算法 引用計數法 可達性分析法 首先我們提出四個問題 哪裡的記憶體需要回收？ 什麼時候回收？ 如何回收？ Java與C++之間有一堵由記憶體動態分配和垃圾收集技術所圍成的“高牆”， 牆外面的人想進去， 牆裡面的人卻想出來。

使用LINQ、Lambda 表示式 、委託快速比較兩個集合，找出需要新增、修改、刪除的物件

本文需要對C#裡的LINQ、Lambda 表示式 、委託有一定了解。 在工作中，經常遇到需要對比兩個集合的場景，如： 頁面集合資料修改，需要儲存到資料庫 全量同步上游資料到本系統資料庫 在這些場景中，需要識別出需要新增、更新、刪除的資料，由於每次應用是，需要比較的物件型別不一致，因此寫了個相對通用的方

jvm學習筆記（3）——java物件的記憶體分配和物件的回收（GC）

引言：         之前的文章已經提過，java物件例項是存放在堆上的，至於是在伊甸區、存活區還是老年區，這些都是從物件回收（GC）角度來進行的邏輯劃分。所以我們先說物件的回收（GC），然後再依據GC的策略來說明新的物件具體在哪個區生成。 GC（Garbage C

JVM: 使用 jstack 命令找出 cpu 飆高的原因

首先新建一個springboot專案，新建一個controller @RestController public class DeadLockController { private Object lock1 = new Object(); private Objec

【轉】【JVM】JVM調優之jstack找出最耗cpu的執行緒並定位程式碼

jstack可以定位到執行緒堆疊，根據堆疊資訊我們可以定位到具體程式碼，所以它在JVM效能調優中使用得非常多。下面我們來一個例項找出某個Java程序中最耗費CPU的Java執行緒並定位堆疊資訊，用到的命令有ps、top、printf、jstack、grep。 第一步先找

JVM:GC-判斷物件是否可以回收？

今天開始GC，也就是垃圾回收。 GC主要做三個事情： 1、什麼物件可以回收 2、什麼時候進行回收 3、如何回收 jvm裡的垃圾就是物件，指無用的物件，在真正執行垃圾回收前，必須要判斷物件是否是無用，是否可以回收，那麼jvm是如何來判斷一個物件能否回收呢？ 今天就來探討一下。 引用計數演算

建立一個物件陣列，內放5個學生的資料（學號，成績），用指向物件的指標做函式引數，在max函式中找出5個學生中成績最高者，並輸出其學號。

原始碼如下：主要注意友元函式的宣告 #include <iostream> #include <string> using namespace std; class Student { public:     Student(string n,flo

python找出序列中出現次數最多的元素之Counter物件

解決此類問題我們將用到collections模組中的Counter類，並直接呼叫Counter類的most_common()方法或得答案。 用下面的例子來講解具體用法： 基本用法 from col

JVM調優之jstack找出最耗cpu的執行緒並定位程式碼

第一步：先找出java的程序Id(PID) 假設java應用名稱是zcg_commodity ps -ef|grep zcg_commodity 得到程序Id為32464 第二步：找出該程序內最消耗CPU的執行緒 top -Hp pid 輸入top

指令碼之找出佔用了Buffer Cache裡大量的buffer的資料庫物件

找出大量消耗（佔用）了Buffer Cache（裡的buffer的個數）的資料庫物件。下面的語句就可以完成這一工作： SQL> column c0 heading 'Owner'                     format a15 SQL> colum

java兩個list中儲存bean物件，找出其中某一屬性不同的元素

在java中運用List集合儲存物件，如果想找到兩個list中不同的部分，可以用ArrayList的contains方法，遍歷每一個物件,判斷是否是相等的，如下： public stati

找出list中的不同元素、刪除兩個list中相同的物件

package com.test; import java.util.ArrayList; import java.util.Arrays; import java.util.Collections; import java.util.List; /** * *

java jvm GC的基石 可達性演算法

在jvm中 任何堆中物件 與GC root set不可達就會被gc回收。 那麼gc root set是什麼呢？ 1.虛擬機器棧（棧幀中的本地變量表）中引用的物件。 2.方法區中類靜態屬性引用的物件。 3.方法區中常量引用的物件。 4.本地方法棧中JNI引用的物件。 如果物件