您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關JVM的工作原理是什么,小編覺得挺實用的,因此分享給大家做個參考,希望大家閱讀完這篇文章后可以有所收獲。
在JDK1.7及其以前我們所使用的都是Sun公司的HotSpot,但由于Sun公司和BEA公司都被oracle收購,jdk1.8將采用Sun公司的HotSpot和BEA公司的JRockit兩個JVM中精華形成jdk1.8的JVM。
我們都知道java一直宣傳的口號是:一次編譯,到處運行。那么它如何實現的呢?我們看下圖:
我們先看一段代碼:
public class HelloWorld {
public static void main(String[] args) {
System.out.print("Hello world");
}
}
這段程序從編譯到運行,最終打印出“Hello world”中間經過了哪些步驟呢?我們直接上圖:
這里我們先不討論類加載的問題。
JVM的生命周期
1.啟動。啟動一個Java程序,一個JVM實例就產生。擁有public static void main(String[] args)函數的class可以作為JVM實例運行的起點。
2.運行。main()作為程序初始線程的起點,任何其他線程均可由該線程啟動。JVM內部有兩種線程:守護線程和非守護線程,main()屬于非守護線程,守護線程通常由JVM使用,程序可以指定創建的線程為守護線程。
3.消亡。當程序中的所有非守護線程都終止時,JVM才退出;若安全管理器允許,程序也可以使用Runtime類或者System.exit()來退出。
JVM執行引擎實例則對應了屬于用戶運行程序線程它是線程級別的。
JVM的體系結構
JVM的數據運行區
JVM調優主要就是優化 Heap堆 和 Method Area 方法區。
Method Area方法區
方法區是被所有線程共享,所有字段和方法字節碼,以及一些特殊方法如構造函數,接口代碼也在此定義。簡單說,所有定義的方法的信息都保存在該區域,此區域屬于共享區間。
靜態變量+常量+類信息+運行時常量池存在方法區中,實例變量存在堆內存中。
Stack 棧
棧中的數據都是以棧幀(Stack Frame)的格式存在,棧幀是一個內存區塊,是一個數據集,是一個有關方法和運行期數據的數據集,當一個方法A被調用時就產生了一個棧幀F1,并被壓入到棧中,A方法又調用了B方法,于是產生棧幀F2也被壓入棧,B方法又調用了C方法,于是產生棧幀F3也被壓入棧…… 依次執行完畢后,先彈出后進......F3棧幀,再彈出F2棧幀,再彈出F1棧幀。
遵循“先進后出”/“后進先出”原則。
Heap 堆
堆這塊區域是JVM中最大的,應用的對象和數據都是存在這個區域,這塊區域也是線程共享的,也是 gc 主要的回收區,一個 JVM 實例只存在一個堆類存,堆內存的大小是可以調節的。類加載器讀取了類文件后,需要把類、方法、常變量放到堆內存中,以方便執行器執行,堆內存分為三部分:
① 新生區
新生區是類的誕生、成長、消亡的區域,一個類在這里產生,應用,最后被垃圾回收器收集,結束生命。新生區又分為兩部分:伊甸區(Eden space)和幸存者區(Survivor pace),所有的類都是在伊甸區被new出來的。幸存區有兩個:0區(Survivor 0 space)和1區(Survivor 1 space)。當伊甸園的空間用完時,程序又需要創建對象,JVM的垃圾回收器將對伊甸園進行垃圾回收(Minor GC),將伊甸園中的剩余對象移動到幸存0區。若幸存0區也滿了,再對該區進行垃圾回收,然后移動到1區。那如果1去也滿了呢?再移動到養老區。若養老區也滿了,那么這個時候將產生Major GC(FullGCC),進行養老區的內存清理。若養老區執行Full GC 之后發現依然無法進行對象的保存,就會產生OOM異常“OutOfMemoryError”。
如果出現java.lang.OutOfMemoryError: Java heap space異常,說明Java虛擬機的堆內存不夠。原因有二:
a.Java虛擬機的堆內存設置不夠,可以通過參數-Xms、-Xmx來調整。
b.代碼中創建了大量大對象,并且長時間不能被垃圾收集器收集(存在被引用)。
② 養老區
養老區用于保存從新生區篩選出來的 JAVA 對象,一般池對象都在這個區域活躍。
③ 永久區
永久存儲區是一個常駐內存區域,用于存放JDK自身所攜帶的 Class,Interface 的元數據,也就是說它存儲的是運行環境必須的類信息,被裝載進此區域的數據是不會被垃圾回收器回收掉的,關閉 JVM 才會釋放此區域所占用的內存。
如果出現java.lang.OutOfMemoryError: PermGen space,說明是Java虛擬機對永久代Perm內存設置不夠。原因有二:
a. 程序啟動需要加載大量的第三方jar包。例如:在一個Tomcat下部署了太多的應用。
b. 大量動態反射生成的類不斷被加載,最終導致Perm區被占滿。
JVM垃圾回收
(一)引用計數(Reference Counting):
比較古老的回收算法。原理是此對象有一個引用,即增加一個計數,刪除一個引用則減少一個計數。垃圾回收時,只用收集計數為0的對象。此算法最致命的是無法處理循環引用的問題。
(二)標記-清除(Mark-Sweep):
此算法執行分兩階段。第一階段從引用根節點開始標記所有被引用的對象,第二階段遍歷整個堆,把未標記的對象清除。此算法需要暫停整個應用,同時,會產生內存碎片。
(三)復制(Copying):
此算法把內存空間劃為兩個相等的區域,每次只使用其中一個區域。垃圾回收時,遍歷當前使用區域,把正在使用中的對象復制到另外一個區域中。算法每次只處理正在使用中的對象,因此復制成本比較小,同時復制過去以后還能進行相應的內存整理,不會出現“碎片”問題。當然,此算法的缺點也是很明顯的,就是需要兩倍內存空間。
(四)標記-整理(Mark-Compact):
此算法結合了“標記-清除”和“復制”兩個算法的優點。也是分兩階段,第一階段從根節點開始標記所有被引用對象,第二階段遍歷整個堆,清除未標記對象并且把存活對象“壓縮”到堆的其中一塊,按順序排放。此算法避免了“標記-清除”的碎片問題,同時也避免了“復制”算法的空間問題。
關于“JVM的工作原理是什么”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,使各位可以學到更多知識,如果覺得文章不錯,請把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。