JVM虛擬機(jī)底層原理是什么

本篇內(nèi)容介紹了“JVM虛擬機(jī)底層原理是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

定義:

翻譯:首先是所有Java虛擬機(jī)線程共享的一塊區(qū)域,他存放了根類結(jié)構(gòu)相關(guān)的一些信息,
有類的變量,方法信息,構(gòu)造方法和構(gòu)造器信息,和一些特殊方法(主要指類構(gòu)造器)。
方法區(qū)在虛擬機(jī)啟動(dòng)時(shí)被創(chuàng)建,邏輯上來(lái)講是堆的一個(gè)組成部分,但是并不強(qiáng)制你的具體位置,(說(shuō)白了就是不同的JVM廠商在實(shí)現(xiàn)的時(shí)候不一定完全按照標(biāo)準(zhǔn)來(lái)創(chuàng)造)
最后對(duì)于內(nèi)存定義:方法區(qū)在內(nèi)存不足是也會(huì)拋出 OutOfMemoryError

解釋:

說(shuō)了半天可能有人聽(tīng)不懂了,那就來(lái)解釋一下!

拿oracle的hospost虛擬機(jī)舉例(也就是我們?nèi)粘Ｓ玫?

組成:

在JDK8之前hospost虛擬機(jī)對(duì)方法區(qū)的實(shí)現(xiàn),叫做永久代,永久代就是使用堆的一部分空間去做實(shí)現(xiàn)的

而在JDK8之后把永久代移除了,換了一個(gè)實(shí)現(xiàn),叫做元空間 元空間用的不是堆的內(nèi)存,而是本地內(nèi)存,也就是操作系統(tǒng)的內(nèi)存

所以不同的實(shí)現(xiàn)對(duì)于方法區(qū)的選擇位置也不同

方法區(qū)內(nèi)存溢出:

有人會(huì)疑問(wèn),方法區(qū)不就存放類的一些信息和實(shí)例嗎?大小也不足以內(nèi)存溢出啊,具體什么情況,拿個(gè)例子看下

/** 元空間
 * 演示元空間內(nèi)存溢出 java.lang.OutOfMemoryError: Metaspace
 * -XX:MaxMetaspaceSize=8m
 */
public class Demo1_8 extends ClassLoader { // ClassLoader可以用來(lái)加載類的二進(jìn)制字節(jié)碼
	public static void main(String[] args) {
		int j = 0;
		try {
			Demo1_8 test = new Demo1_8();
			for (int i = 0; i < 10000; i++, j++) {
				// ClassWriter 作用是生成類的二進(jìn)制字節(jié)碼
				ClassWriter cw = new ClassWriter(0);
				// 版本號(hào)， public， 類名, 包名, 父類， 接口
				cw.visit(Opcodes.V1_8, Opcodes.ACC_PUBLIC, "Class" + i, null, "java/lang/Object", null);
				// 返回 byte[]
				byte[] code = cw.toByteArray();
				// 執(zhí)行了類的加載
				test.defineClass("Class" + i, code, 0, code.length); // Class 對(duì)象
			}
		} finally {
			System.out.println(j);
		}
	}
}

代碼注釋都有,自行理解,由于電腦物理內(nèi)存大不方便演示效果,所以要加  -XX:MaxMetaspaceSize=8m 參數(shù)

JVM1.6執(zhí)行結(jié)果:永久代內(nèi)存溢出導(dǎo)致OutOfMemoryError

JVM1.8 之后會(huì)導(dǎo)致元空間內(nèi)存溢出 java.lang.OutOfMemoryError: Metaspace

雖然都是OutOfMemoryError 但是可以看到1.8之前是permGen space 1.8之后是Metaspace

這種場(chǎng)景是非常多的, 看過(guò)spring mybatis源碼的應(yīng)該了解 代碼使用不當(dāng)是很容易造成方法區(qū)內(nèi)存溢出的

運(yùn)行時(shí)常量池:

在明白運(yùn)行時(shí)常量池之前首先說(shuō)說(shuō)什么是常量池

• 常量池，就是一張表，虛擬機(jī)指令根據(jù)這張常量表找到要執(zhí)行的類名、方法名、參數(shù)類型、字面量等信息

• 運(yùn)行時(shí)常量池，常量池是 *.class 文件中的，當(dāng)該類被加載，它的常量池信息就會(huì)放入運(yùn)行時(shí)常量池，并把里面的符號(hào)地址變?yōu)檎鎸?shí)地址

了解運(yùn)行時(shí)常量池之后,不得不說(shuō)運(yùn)行時(shí)常量池的一個(gè)重要組成部分StringTable

說(shuō)StringTable先看幾道經(jīng)典面試題

String s1 = "a";
String s2 = "b"; 
String s3 = "a" + "b"; 
String s4 = s1 + s2; 
String s5 = "ab"; 
String s6 = s4.intern(); // 問(wèn) 
System.out.println(s3 == s4); 
System.out.println(s3 == s5); 
System.out.println(s3 == s6); 

String x2 = new String("c") + new String("d"); 
String x1 = "cd"; 
x2.intern();
// 問(wèn)，如果調(diào)換了【最后兩行代碼】的位置呢，如果是jdk1.6呢 
System.out.println(x1 == x2);

講解:
①   s3 == s4  //false
s3 = "a" + "b" 兩個(gè)字符串相加 stringtable會(huì)有編譯期優(yōu)化,結(jié)果就是 "ab"(字符串a(chǎn)b) 常量池沒(méi)有,順便入池。
s4 = s1 + s2 兩個(gè)變量拼接在運(yùn)行期使用stringbuilder拼接產(chǎn)生新的字符串 新的字符串相當(dāng)于new String("ab")出來(lái)的 所以在堆中
所以第一題為false  理由:一個(gè)在常量池中一個(gè)在堆內(nèi)存中

②   s3 == s5  //true
s5 = "ab" 是一個(gè)自變量會(huì)首先檢查常量池的內(nèi)容,結(jié)果常量池已經(jīng)有s3拼好的"ab"了,所以s5不會(huì)創(chuàng)建新的對(duì)象,會(huì)直接引用常量池以有的對(duì)象,因此s3和s5都是同一個(gè)對(duì)象 所以為true

③   s3 == s6 // true
s6又是調(diào)用s4.intern()方法 intern() 方法回去常量池先看有沒(méi)有這個(gè)對(duì)象,如果有就返回常量池的對(duì)象,如果沒(méi)有就嘗試將s4進(jìn)行入池,
顯然常量池已有ab,沒(méi)能入池成功,但他返回常量池中的對(duì)象,所以s6和s3就是一個(gè)對(duì)象 所以為true

④   x1 == x2  // false
x2 顯然是堆中的對(duì)象 new String("cd") ;  x1 顯然是常量池中的對(duì)象
x2調(diào)用intern方法嘗試將堆內(nèi)存中的x2進(jìn)行入池,但是常量池已經(jīng)有了,所以沒(méi)能入池成功,所以最終 x2是堆內(nèi)存中的對(duì)象 x1 是常量池中的對(duì)象 結(jié)果為false

StringTable 特性

• 常量池中的字符串僅是符號(hào)，第一次用到時(shí)才變?yōu)閷?duì)象

• 利用串池的機(jī)制，來(lái)避免重復(fù)創(chuàng)建字符串對(duì)象

• 字符串變量拼接的原理是 StringBuilder （1.8）

• 字符串常量拼接的原理是編譯期優(yōu)化

• 可以使用 intern 方法，主動(dòng)將串池中還沒(méi)有的字符串對(duì)象放入串池

• 1.8 將這個(gè)字符串對(duì)象嘗試放入串池，如果有則并不會(huì)放入，如果沒(méi)有則放入串池， 會(huì)把串池中的對(duì)象返回

• 1.6 將這個(gè)字符串對(duì)象嘗試放入串池，如果有則并不會(huì)放入，如果沒(méi)有會(huì)把此對(duì)象復(fù)制一份，放入串池， 會(huì)把串池中的對(duì)象返回

StringTable 位置

在JVM1.6之前stringtable在方法區(qū),具體實(shí)現(xiàn)也就是永久代的其中一塊空間 而在1.7 1.8之后 他的實(shí)現(xiàn)空間被移動(dòng)到堆內(nèi)存中

為什么更改? 原因是什么?

因?yàn)橛谰么鷥?nèi)存不足,而且永久代只有觸發(fā)FullGC時(shí)候才會(huì)執(zhí)行他的垃圾回收,但是FullGC只有等到整個(gè)老年代的空間不足才會(huì)觸發(fā),回收時(shí)間會(huì)很晚,間接的導(dǎo)致stringtable的回收效率并不高,所以1.6之后的JVM廠商對(duì)此作了優(yōu)化

“JVM虛擬機(jī)底層原理是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！