修改jvm代碼重新編譯

Ⅰ 如何用maven將java8寫的代碼編譯為java6平台的

在一般的Java應用開發過程中，開發人員使用Java的方式比較簡單。打開慣用的IDE，編寫Java源代碼，再利用IDE提供的功能直接運行Java 程序就可以了。這種開發模式背後的過程是：開發人員編寫的是Java源代碼文件（.java），IDE會負責調用Java的編譯器把Java源代碼編譯成平台無關的位元組代碼（byte code），以類文件的形式保存在磁碟上（.class）。Java虛擬機（JVM）會負責把Java位元組代碼載入並執行。Java通過這種方式來實現其「編寫一次，到處運行（Write once, run anywhere）」 的目標。Java類文件中包含的位元組代碼可以被不同平台上的JVM所使用。Java位元組代碼不僅可以以文件形式存在於磁碟上，也可以通過網路方式來下載，還可以只存在於內存中。JVM中的類載入器會負責從包含位元組代碼的位元組數組（byte[]）中定義出Java類。在某些情況下，可能會需要動態的生成 Java位元組代碼，或是對已有的Java位元組代碼進行修改。這個時候就需要用到本文中將要介紹的相關技術。首先介紹一下如何動態編譯Java源文件。
動態編譯Java源文件
在一般情況下，開發人員都是在程序運行之前就編寫完成了全部的Java源代碼並且成功編譯。對有些應用來說，Java源代碼的內容在運行時刻才能確定。這個時候就需要動態編譯源代碼來生成Java位元組代碼，再由JVM來載入執行。典型的場景是很多演算法競賽的在線評測系統（如PKU JudgeOnline），允許用戶上傳Java代碼，由系統在後台編譯、運行並進行判定。在動態編譯Java源文件時，使用的做法是直接在程序中調用Java編譯器。
JSR 199引入了Java編譯器API。如果使用JDK 6的話，可以通過此API來動態編譯Java代碼。比如下面的代碼用來動態編譯最簡單的Hello World類。該Java類的代碼是保存在一個字元串中的。
01 public class CompilerTest {
02 public static void main(String[] args) throws Exception {
03 String source = "public class Main { public static void main(String[] args) {System.out.println(\"Hello World!\");} }";
04 JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
05 StandardJavaFileManager fileManager = compiler.getStandardFileManager(null, null, null);
06 StringSourceJavaObject sourceObject = newCompilerTest.StringSourceJavaObject("Main", source);
07 Iterable< extends JavaFileObject> fileObjects = Arrays.asList(sourceObject);
08 CompilationTask task = compiler.getTask(null, fileManager, null,null, null, fileObjects);
09 boolean result = task.call();
10 if (result) {
11 System.out.println("編譯成功。");
12 }
13 }
14
15 static class StringSourceJavaObject extends SimpleJavaFileObject {
16
17 private String content = null;
18 public StringSourceJavaObject(String name, String content) ??throwsURISyntaxException {
19 super(URI.create("string:///" + name.replace('.','/') + Kind.SOURCE.extension), Kind.SOURCE);
20 this.content = content;
21 }
22
23 public CharSequence getCharContent(boolean ignoreEncodingErrors) ??throws IOException {
24 return content;
25 }
26 }
27 }
如果不能使用JDK 6提供的Java編譯器API的話，可以使用JDK中的工具類com.sun.tools.javac.Main，不過該工具類只能編譯存放在磁碟上的文件，類似於直接使用javac命令。
另外一個可用的工具是Eclipse JDT Core提供的編譯器。這是Eclipse Java開發環境使用的增量式Java編譯器，支持運行和調試有錯誤的代碼。該編譯器也可以單獨使用。Play框架在內部使用了JDT的編譯器來動態編譯Java源代碼。在開發模式下，Play框架會定期掃描項目中的Java源代碼文件，一旦發現有修改，會自動編譯 Java源代碼。因此在修改代碼之後，刷新頁面就可以看到變化。使用這些動態編譯的方式的時候，需要確保JDK中的tools.jar在應用的 CLASSPATH中。
下面介紹一個例子，是關於如何在Java裡面做四則運算，比如求出來(3+4)*7-10的值。一般的做法是分析輸入的運算表達式，自己來模擬計算過程。考慮到括弧的存在和運算符的優先順序等問題，這樣的計算過程會比較復雜，而且容易出錯。另外一種做法是可以用JSR 223引入的腳本語言支持，直接把輸入的表達式當做JavaScript或是JavaFX腳本來執行，得到結果。下面的代碼使用的做法是動態生成Java源代碼並編譯，接著載入Java類來執行並獲取結果。這種做法完全使用Java來實現。
01 private static double calculate(String expr) throws CalculationException {
02 String className = "CalculatorMain";
03 String methodName = "calculate";
04 String source = "public class " + className
05 + " { public static double " + methodName + "() { return " + expr +"; } }";
06 //省略動態編譯Java源代碼的相關代碼，參見上一節
07 boolean result = task.call();
08 if (result) {
09 ClassLoader loader = Calculator.class.getClassLoader();
10 try {
11 Class<?> clazz = loader.loadClass(className);
12 Method method = clazz.getMethod(methodName, new Class<?>[] {});
13 Object value = method.invoke(null, new Object[] {});
14 return (Double) value;
15 } catch (Exception e) {
16 throw new CalculationException("內部錯誤。");
17 }
18 } else {
19 throw new CalculationException("錯誤的表達式。");
20 }
21 }
上面的代碼給出了使用動態生成的Java位元組代碼的基本模式，即通過類載入器來載入位元組代碼，創建Java類的對象的實例，再通過Java反射API來調用對象中的方法。
Java位元組代碼增強
Java 位元組代碼增強指的是在Java位元組代碼生成之後，對其進行修改，增強其功能。這種做法相當於對應用程序的二進制文件進行修改。在很多Java框架中都可以見到這種實現方式。Java位元組代碼增強通常與Java源文件中的註解（annotation）一塊使用。註解在Java源代碼中聲明了需要增強的行為及相關的元數據，由框架在運行時刻完成對位元組代碼的增強。Java位元組代碼增強應用的場景比較多，一般都集中在減少冗餘代碼和對開發人員屏蔽底層的實現細節上。用過JavaBeans的人可能對其中那些必須添加的getter/setter方法感到很繁瑣，並且難以維護。而通過位元組代碼增強，開發人員只需要聲明Bean中的屬性即可，getter/setter方法可以通過修改位元組代碼來自動添加。用過JPA的人，在調試程序的時候，會發現實體類中被添加了一些額外的 域和方法。這些域和方法是在運行時刻由JPA的實現動態添加的。位元組代碼增強在面向方面編程（AOP）的一些實現中也有使用。

Ⅱ 如何解決Unsupported major.minor version 52.0問題

一：要解決的問題

我們在嘗鮮 JDK1.5 的時候，相信不少人遇到過 Unsupported major.minor version 49.0 錯誤，當時定會茫然不知所措。因為剛開始那會兒，網上與此相關的中文資料還不多，現在好了，網上一找就知道是如何解決，大多會告訴你要使用 JDK 1.4 重新編譯。那麼至於為什麼，那個 major.minor 究竟為何物呢？這就是本篇來講的內容，以使未錯而先知。

我覺得我是比較幸運的，因為在遇到那個錯誤之前已研讀過《深入 Java 虛擬機》第二版，英文原書名為《Inside the Java Virtual Machine》( Second Edition)，看時已知曉 major.minor 藏匿於何處，但沒有切身體會，待到與 Unsupported major.minor version 49.0 真正會面試，正好是給我驗證了一個事實。

首先我們要對 Unsupported major.minor version 49.0 建立的直接感覺是：JDK1.5 編譯出來的類不能在 JVM 1.4 下運行，必須編譯成 JVM 1.4 下能運行的類。(當然，也許你用的還是 JVM 1.3 或 JVM 1.2，那麼就要編譯成目標 JVM 能認可的類)。這也解決問題的方向。

二：major.minor 棲身於何處

何謂 major.minor，且又居身於何處呢？先感性認識並找到 major.minor 來。

寫一個 Java Hello World! 代碼，然後用 JDK 1.5 的編譯器編譯成，HelloWorld.java

package com.unmi;

public class HelloWorld
{
public static void main(String[] args)
{
System.out.println("Hello, World!");
}
}
package com.unmi;public class HelloWorld{ public static void main(String[] args) { System.out.println("Hello, World!"); }}

用 JDK 1.5 的 javac -d . HelloWorld.java 編譯出來的位元組碼 HelloWorld.class 用 UltraEdit 打開來的內容如圖所示：

從上圖中我們看出來了什麼是 major.minor version 了，它相當於一個軟體的主次版本號，只是在這里是標識的一個 Java Class 的主版本號和次版本號，同時我們看到 minor_version 為 0x0000，major_version 為 0x0031，轉換為十制數分別為0 和 49，即 major.minor 就是 49.0 了。

三：何謂 major.minor 以及何用

Class 文件的第 5-8 位元組為 minor_version 和 major_version。Java class 文件格式可能會加入新特性。class 文件格式一旦發生變化，版本號也會隨之變化。對於 JVM 來說，版本號確定了特定的 class 文件格式，通常只有給定主版本號和一系列次版本號後，JVM 才能夠讀取 class 文件。如果 class 文件的版本號超出了 JVM 所能處理的有效范圍，JVM 將不會處理該 class 文件。

在 Sun 的 JDK 1.0.2 發布版中，JVM 實現支持從 45.0 到 45.3 的 class 文件格式。在所有 JDK 1.1 發布版中的 JVM 都能夠支持版本從 45.0 到 45.65535 的 class 文件格式。在 Sun 的 1.2 版本的 SDK 中，JVM 能夠支持從版本 45.0 到46.0 的 class 文件格式。

1.0 或 1.2 版本的編譯器能夠產生版本號為 45.3 的 class 文件。在 Sun 的 1.2 版本 SDK 中，Javac 編譯器默認產生版本號為 45.3 的 class 文件。但如果在 javac 命令行中指定了 -target 1.2 標志，1.2 版本的編譯器將產生版本號為 46.0 的 class 文件。1.0 或 1.1 版本的 JVM 上不能運行使用-target 1.2 標志所產生的 class 文件。

JVM 實現的 第二版中修改了對 class 文件主版本號和次版本號的解釋。對於第二版而言，class 文件的主版本號與 Java 平台主發布版的版本號保持一致(例如：在 Java 2 平台發布版上，主版本號從 45 升至 46)，次版本號與特定主平台發布版的各個發布版相關。因此，盡管不同的 class 文件格式可以由不同的版本號表示，但版本號不一樣並不代表 class 文件格式不同。版本號不同的原因可能只是因為 class 文件由不同發布版本的 java 平台產生，可能 class 文件的格式並沒有改變。

上面三段節選自《深入 Java 虛擬機》，啰嗦一堆，JDK 1.2 開啟了 Java 2 的時代，但那個年代仍然離我們很遠，我們當中很多少直接跳在 JDK 1.4 上的，我也差不多，只是項目要求不得不在一段時間里委屈在 JDK 1.3 上。不過大致我們可以得到的信息就是每個版本的 JDK 編譯器編譯出的 class 文件中都帶有一個版本號，不同的 JVM 能接受一個范圍 class 版本號，超出范圍則要出錯。不過一般都是能向後兼容的，知道 Sun 在做 Solaris 的一句口號嗎？保持對先前版本的 100% 二進制兼容性，這也是對客戶的投資保護。

四：其他確定 class 的 major.minor version 辦法

1）Eclipse 中查看

Eclipse 3.3 加入的新特徵，當某個類沒有關聯到源代碼，打開它會顯示比較詳細的類信息，當然還未到源碼級別了，看下圖是打開 2.0 spring.jar 中 .class 顯示的信息

2）命令 javap -verbose

對於編譯出的 class 文件用 javap -verbose 能顯示出類的 major.minor 版本，見下圖：

3) MANIFEST 文件

把 class 打成的 JAR 包中都會有文件 META-INF\MANIFEST，這個文件一般會有編譯器的信息，下面列幾個包的 META-INF\MANIFEST 文件內容大家看看

·Velocity-1.5.jar 的 META-INFO\MANIFEST 部份內容

Manifest-Version: 1.0

Ant-Version: Apache Ant 1.7.0

Created-By: Apache Ant

Package: org.apache.velocity

Build-Jdk: 1.4.2_08

Extension-Name: velocity

我們看到是用 ant 打包，構建用的JDK是 1.4.2_08，用 1.4 編譯的類在 1.4 JVM 中當然能運行。如果那人用 1.5 的 JDK 來編譯，然後用 JDK 1.4+ANT 來打包就太無聊了。

·2.0 spring.jar 的 META-INFO\MANIFEST 部份內容

Manifest-Version: 1.0

Ant-Version: Apache Ant 1.6.5

Created-By: 1.5.0_08-b03 (Sun Microsystems Inc.)

Implementation-Title: Spring Framework

這下要注意啦，它是用的 JDK 1.5 來編譯的，那麼它是否帶了 -target 1.4 或 -target 1.3 來編譯的呢？確實是的，可以查看類的二進制文件，這是最保險的。所在 spring-2.0.jar 也可以在 1.4 JVM 中載入執行。

·自已一個項目中用 ant 打的 jar 包的 META-INFO\MANIFEST

Manifest-Version: 1.0

Ant-Version: Apache Ant 1.7.0

Created-By: 1.4.2-b28 (Sun Microsystems Inc.)

用的是 JDK 1.4 構建打包的。

第一第二種辦法能明確知道 major.minor version，而第三種方法應該也沒問題，但是碰到變態構建就難說了，比如誰把那個 META-INFO\MANIFEST 打包後換了也未可知。直接查看類的二進制文件的方法可以萬分保證，准確無誤，就是工具篡改我也認了。

五：編譯器比較及症節之所在

現在不妨從 JDK 1.1 到 JDK 1.7 編譯器編譯出的 class 的默認 minor.major version 吧。（又走到 Sun 的網站上翻騰出我從來都沒用過的古董來）

JDK 編譯器版本 target 參數 十六進制 minor.major 十進制 minor.major
jdk1.1.8 不能帶 target 參數 00 03 00 2D 45.3
jdk1.2.2 不帶(默認為 -target 1.1) 00 03 00 2D 45.3
jdk1.2.2 -target 1.2 00 00 00 2E 46.0
jdk1.3.1_19 不帶(默認為 -target 1.1) 00 03 00 2D 45.3
jdk1.3.1_19 -target 1.3 00 00 00 2F 47.0
j2sdk1.4.2_10 不帶(默認為 -target 1.2) 00 00 00 2E 46.0
j2sdk1.4.2_10 -target 1.4 00 00 00 30 48.0
jdk1.5.0_11 不帶(默認為 -target 1.5) 00 00 00 31 49.0
jdk1.5.0_11 -target 1.4 -source 1.4 00 00 00 30 48.0
jdk1.6.0_01 不帶(默認為 -target 1.6) 00 00 00 32 50.0
jdk1.6.0_01 -target 1.5 00 00 00 31 49.0
jdk1.6.0_01 -target 1.4 -source 1.4 00 00 00 30 48.0
jdk1.7.0 不帶(默認為 -target 1.6) 00 00 00 32 50.0
jdk1.7.0 -target 1.7 00 00 00 33 51.0
jdk1.7.0 -target 1.4 -source 1.4 00 00 00 30 48.0
Apache Harmony 5.0M3 不帶(默認為 -target 1.2) 00 00 00 2E 46.0
Apache Harmony 5.0M3 -target 1.4 00 00 00 30 48.0
上面比較是 Windows 平台下的 JDK 編譯器的情況，我們可以此作些總結：

1) -target 1.1 時 有次版本號，target 為 1.2 及以後都只用主版本號了，次版本號為 0

2) 從 1.1 到 1.4 語言差異比較小，所以 1.2 到 1.4 默認的 target 都不是自身相對應版本

3) 1.5 語法變動很大，所以直接默認 target 就是 1.5。也因為如此用 1.5 的 JDK 要生成目標為 1.4 的代碼，光有 -target 1.4 不夠，必須同時帶上 -source 1.4，指定源碼的兼容性，1.6/1.7 JDk 生成目標為 1.4 的代碼也如此。

4) 1.6 編譯器顯得較為激進，默認參數就為 -target 1.6。因為 1.6 和 1.5 的語法無差異，所以用 -target 1.5 時無需跟著 -source 1.5。

5) 注意 1.7 編譯的默認 target 為 1.6

6) 其他第三方的 JDK 生成的 Class 文件格式版本號同對應 Sun 版本 JDK

7) 最後一點最重要的，某個版本的 JVM 能接受 class 文件的最大主版本號不能超過對應 JDK 帶相應 target 參數編譯出來的 class 文件的版本號。

上面那句話有點長，一口氣讀過去不是很好理解，舉個例子：1.4 的 JVM 能接受最大的 class 文件的主版本號不能超過用 1.4 JDK 帶參數 -target 1.4 時編譯出的 class 文件的主版本號，也就是 48。

因為 1.5 JDK 編譯時默認 target 為 1.5，出來的位元組碼 major.minor version 是 49.0，所以 1.4 的 JVM 是無法接受的，只有拋出錯誤。

那麼又為什麼從 1.1 到 1.2、從 1.2 到 1.3 或者從 1.3 到 1.4 的 JDK 升級不會發生 Unsupported major.minor version 的錯誤呢，那是因為 1.2/1.3/1.4 都保持了很好的二進制兼容性，看看 1.2/1.3/1.4 的默認 target 分別為 1.1/1.1/1.2 就知道了，也就是默認情況下1.4 JDK 編譯出的 class 文件在 JVM 1.2 下都能載入執行，何況於 JVM 1.3 呢？（當然要去除使用了新版本擴充的 API 的因素）

六：找到問題解決的方法

那麼現在如果碰到這種問題該知道如何解決了吧，還會像我所見到有些兄弟那樣，去找個 1.4 的 JDK 下載安裝，然後用其重新編譯所有的代碼嗎？其實大可不必如此費神，我們一定還記得 javac 還有個 -target 參數，對啦，可以繼續使用 1.5 JDK，編譯時帶上參數 -target 1.4 -source 1.4 就 OK 啦，不過你一定要對哪些 API 是 1.5 JDK 加入進來的了如指掌，不能你的 class 文件拿到 JVM 1.4 下就會 method not found。目標 JVM 是 1.3 的話，編譯選項就用 -target 1.3 -source 1.3 了。

相應的如果使用 ant ，它的 javac 任務也可對應的選擇 target 和 source

<javac target="1.4" source="1.4" ............................/>

如果是在開發中，可以肯定的是現在真正算得上是 JAVA IDE 對於工程也都有編譯選項設置目標代碼的。例如 Eclipse 的項目屬性中的 Java Compiler 設置，如圖

自已設定編譯選項，你會看到選擇不同的 compiler compliance level 是，Generated class files compatibility 和 Source compatibility 也在變，你也可以手動調整那兩項，手動設置後你就不用很在乎用的什麼版本的編譯器了，只要求他生成我們希望的位元組碼就行了，再引申一下就是即使源代碼是用 VB 寫的，只要能編譯成 JVM 能執行的位元組碼都不打緊。在其他的 IDE 也能找到相應的設置對話框的。

其他時候，你一定要知道當前的 JVM 是什麼版本，能接受的位元組碼主版本號是多少（可對照前面那個表）。獲息當前 JVM 版本有兩種途徑：

第一：如果你是直接用 java 命令在控制台執行程序，可以用 java -version 查看當前的 JVM 版本，然後確定能接受的 class 文件版本

第二：如果是在容器中執行，而不能明確知道會使用哪個 JVM，那麼可以在容器中執行的程序中加入代碼System.getProperty("java.runtime.version"); 或 System.getProperty("java.class.version")，獲得 JVM 版本和能接受的 class 的版本號。

最後一絕招，如果你不想針對低版本的 JVM 用 target 參數重新編譯所有代碼；如果你仍然想繼續在代碼中用新的 API 的話；更有甚者，你還用了 JDK 1.5 的新特性，譬如泛型、自動拆裝箱、枚舉等的話，那你用 -target 1.4 -source 1.4 就沒法編譯通過，不得不重新整理代碼。那麼告訴你最後一招，不需要再從源代碼著手，直接轉換你所正常編譯出的位元組碼，繼續享用那些新的特性，新的 API，那就是：請參考之前的一篇日誌：Retrotranslator讓你用JDK1.5的特性寫出的代碼能在JVM1.4中運行 ，我就是這么用的，做好測試就不會有問題的。

七：再議一個實際發生的相關問題

這是一個因為拷貝 Tomcat 而產生的 Unsupported major.minor version 49.0 錯誤。情景是：我本地安裝的是 JDK 1.5，然後在網上找了一個 EXE 的 Tomcat 安裝文件安裝了並且可用。後來同事要一個 Tomcat，不想下載或安裝，於是根據我以往的經驗是把我的 Tomcat 整個目錄拷給他應該就行了，結果是拿到他那裡瀏覽 jsp 文件都出現 Unsupported major.minor version 49.0 錯誤，可以確定的是他安裝的是 1.4 的 JDK，但我還是有些納悶，先前對這個問題還頗有信心的我傻眼了。慣性思維是編譯好的 class 文件拿到低版本的 JVM 會出現如是異常，可現並沒有用已 JDK 1.5 編譯好的類要執行啊。

後來仔細看異常信息，終於發現了 %TOMCAT_HOME%\common\lib\tools.jar 這一眉目，因為 jsp 文件需要依賴它來編譯，打來這個 tools.jar 中的一個 class 文件來看看，49.0，很快我就明白原來這個文件是在我的機器上安裝 Tomcat 時由 Tomcat 安裝程序從 %JDK1.5%\lib 目錄拷到 Tomcat 的 lib 目錄去的，造成在同事機器上編譯 JSP 時是 1.4 的 JVM 配搭著 49.0 的 tools.jar，那能不出錯，於是找來 1.4 JDK 的 tools.jar 替換了 Tomcat 的就 OK 啦。

八：小結

其實理解 major.minor 就像是我們可以這么想像，同樣是微軟體的程序，32 位的應用程序不能拿到 16 位系統中執行那樣。

如果我們發布前了解到目標 JVM 版本，知道怎麼從 java class 文件中看出 major.minor 版本來，就不用等到伺服器報出異常才著手去解決，也就能預知到可能發生的問題。

其他時候遇到這個問題應具體解決，總之問題的根由是低版本的 JVM 無法載入高版本的 class 文件造成的，找到高版本的 class 文件處理一下就行了

Ⅲ 簡述JAVA程序的編輯編譯和運行過程

第一步(編譯): 創建完源文件之後，程序會先被編譯為.class文件。Java編譯一個類時，如果這個類所依賴的類還沒有被編譯，編譯器就會先編譯這個被依賴的類，然後引用，否則直接引用，這個有點象make。

如果java編譯器在指定目錄下找不到該類所其依賴的類的.class文件或者.java源文件的話，編譯器話報「cant find symbol」的錯誤。

第二步（運行）：java類運行的過程大概可分為兩個過程：1、類的載入 2、類的執行。需要說明的是：JVM主要在程序第一次主動使用類的時候，才會去載入該類。也就是說，JVM並不是在一開始就把一個程序就所有的類都載入到內存中，而是到不得不用的時候才把它載入進來，而且只載入一次。

特別說明：java類中所有public和protected的實例方法都採用動態綁定機制，所有私有方法、靜態方法、構造器及初始化方法<clinit>都是採用靜態綁定機制。而使用動態綁定機制的時候會用到方法表，靜態綁定時並不會用到。

(3)修改jvm代碼重新編譯擴展閱讀：

Java整個編譯以及運行的過程相當繁瑣，本文通過一個簡單的程序來簡單的說明整個流程。

Java代碼編譯:是由Java源碼編譯器來完成;

Java位元組碼的執行:是由JVM執行引擎來完成

Java程序從源文件創建到程序運行要經過兩大步驟：

1、源文件由編譯器編譯成位元組碼（ByteCode）

2、位元組碼由java虛擬機解釋運行。因為java程序既要編譯同時也要經過JVM的解釋運行，所以說Java被稱為半解釋語言（ "semi-interpreted" language）。

Ⅳ 誰能簡單闡述下java編譯執行的過程

Java虛擬機(JVM)是可運行Java代碼的假想計算機。

只要根據JVM規格描述將解釋器移植到特定的計算機上，就能保證經過編譯的任何Java代碼能夠在該系統上運行。

本文首先簡要介紹從Java文件的編譯到最終執行的過程，隨後對JVM規格描述作一說明。

一.Java源文件的編譯、下載、解釋和執行

Java應用程序的開發周期包括編譯、下載、解釋和執行幾個部分。

Java編譯程序將Java源程序翻譯為JVM可執行代碼?位元組碼。

這一編譯過程同C/C++的編譯有些不同。

當C編譯器編譯生成一個對象的代碼時，該代碼是為在某一特定硬體平台運行而產生的。

因此，在編譯過程中，編譯程序通過查表將所有對符號的引用轉換為特定的內存偏移量，以保證程序運行。

Java編譯器卻不將對變數和方法的引用編譯為數值引用，也不確定程序執行過程中的內存布局，而是將這些符號引用信息保留在位元組碼中，由解釋器在運行過程中創立內存布局，然後再通過查表來確定一個方法所在的地址。

這樣就有效的保證了Java的可移植性和安全性。

運行JVM位元組碼的工作是由解釋器來完成的。

解釋執行過程分三部進行：代碼的裝入、代碼的校驗和代碼的執行。

裝入代碼的工作由"類裝載器"（classloader）完成。

類裝載器負責裝入運行一個程序需要的所有代碼，這也包括程序代碼中的類所繼承的類和被其調用的類。

當類裝載器裝入一個類時，該類被放在自己的名字空間中。

除了通過符號引用自己名字空間以外的類，類之間沒有其他辦法可以影響其他類。

在本台計算機上的所有類都在同一地址空間內，而所有從外部引進的類，都有一個自己獨立的名字空間。

這使得本地類通過共享相同的名字空間獲得較高的運行效率，同時又保證它們與從外部引進的類不會相互影響。

當裝入了運行程序需要的所有類後，解釋器便可確定整個可執行程序的內存布局。

解釋器為符號引用同特定的地址空間建立對應關系及查詢表。

通過在這一階段確定代碼的內存布局，Java很好地解決了由超類改變而使子類崩潰的問題，同時也防止了代碼對地址的非法訪問。

隨後，被裝入的代碼由位元組碼校驗器進行檢查。

校驗器可發現操作數棧溢出，非法數據類型轉化等多種錯誤。

通過校驗後，代碼便開始執行了。

Java位元組碼的執行有兩種方式：

1.即時編譯方式：解釋器先將位元組碼編譯成機器碼，然後再執行該機器碼。

2.解釋執行方式：解釋器通過每次解釋並執行一小段代碼來完成Java位元組碼程序的所有操作。

通常採用的是第二種方法。

由於JVM規格描述具有足夠的靈活性，這使得將位元組碼翻譯為機器代碼的工作

具有較高的效率。

對於那些對運行速度要求較高的應用程序，解釋器可將Java位元組碼即時編譯為機器碼，從而很好地保證了Java代碼的可移植性和高性能。

二.JVM規格描述

JVM的設計目標是提供一個基於抽象規格描述的計算機模型，為解釋程序開發人員提很好的靈活性，同時也確保Java代碼可在符合該規范的任何系統上運行。

JVM對其實現的某些方面給出了具體的定義，特別是對Java可執行代碼，即位元組碼(Bytecode)的格式給出了明確的規格。

這一規格包括操作碼和操作數的語法和數值、標識符的數值表示方式、以及Java類文件中的Java對象、常量緩沖池在JVM的存儲映象。

這些定義為JVM解釋器開發人員提供了所需前散的信息和開發環境。

Java的設計者希望給開發人員以隨心所欲使用Java的自由。

JVM定義了控制Java代碼解釋執行纖悔碼和具體實現的五種規格，它們是：

JVM指令系統

JVM寄存器

JVM棧結構

JVM碎片回收堆

JVM存儲區

2.1JVM指令系統

JVM指令系統同其他計算機的指令系統極其相似。

Java指令也是由操作碼和操作數兩部分組成。

操作碼為8位二進制數，操作數進緊隨在操作碼的後面，其長度根據需要而不同。

操作毀哪碼用於指定一條指令操作的性質（在這里我們採用匯編符號的形式進行說明），如iload表示從存儲器中裝入一個整數，anewarray表示為一個新數組分配空間，iand表示兩個整數的"與"，ret用於流程式控制制，表示從對某一方法的調用中返回。

當長度大於8位時，操作數被分為兩個以上位元組存放。

JVM採用了"bigendian"的編碼方式來處理這種情況，即高位bits存放在低位元組中。

這同Motorola及其他的RISCCPU採用的編碼方式是一致的，而與Intel採用的"littleendian"的編碼方式即低位bits存放在低位位元組的方法不同。

Java指令系統是以Java語言的實現為目的設計的，其中包含了用於調用方法和監視多先程系統的指令。

Java的8位操作碼的長度使得JVM最多有256種指令，目前已使用了160多種操作碼。

2.2JVM指令系統

所有的CPU均包含用於保存系統狀態和處理器所需信息的寄存器組。

如果虛擬機定義較多的寄存器，便可以從中得到更多的信息而不必對棧或內存進行訪問，這有利於提高運行速度。

然而，如果虛擬機中的寄存器比實際CPU的寄存器多，在實現虛擬機時就會佔用處理器大量的時間來用常規存儲器模擬寄存器，這反而會降低虛擬機的效率。

針對這種情況，JVM只設置了4個最為常用的寄存器。

它們是：

pc程序計數器

optop操作數棧頂指針

frame當前執行環境指針

vars指向當前執行環境中第一個局部變數的指針

所有寄存器均為32位。

pc用於記錄程序的執行。

optop,frame和vars用於記錄指向Java棧區的指針。

2.3JVM棧結構

作為基於棧結構的計算機，Java棧是JVM存儲信息的主要方法。

當JVM得到一個Java位元組碼應用程序後，便為該代碼中一個類的每一個方法創建一個棧框架，以保存該方法的狀態信息。

每個棧框架包括以下三類信息：

局部變數

執行環境

操作數棧

局部變數用於存儲一個類的方法中所用到的局部變數。

vars寄存器指向該變數表中的第一個局部變數。

執行環境用於保存解釋器對Java位元組碼進行解釋過程中所需的信息。

它們是：上次調用的方法、局部變數指針和操作數棧的棧頂和棧底指針。

執行環境是一個執行一個方法的控制中心。

例如：如果解釋器要執行iadd(整數加法)，首先要從frame寄存器中找到當前執行環境，而後便從執行環境中找到操作數棧，從棧頂彈出兩個整數進行加法運算，最後將結果壓入棧頂。

操作數棧用於存儲運算所需操作數及運算的結果。

2.4JVM碎片回收堆

Java類的實例所需的存儲空間是在堆上分配的。

解釋器具體承擔為類實例分配空間的工作。

解釋器在為一個實例分配完存儲空間後，便開始記錄對該實例所佔用的內存區域的使用。

一旦對象使用完畢，便將其回收到堆中。

在Java語言中，除了new語句外沒有其他方法為一對象申請和釋放內存。

對內存進行釋放和回收的工作是由Java運行系統承擔的。

這允許Java運行系統的設計者自己決定碎片回收的方法。

在SUN公司開發的Java解釋器和HotJava環境中，碎片回收用後台線程的方式來執行。

這不但為運行系統提供了良好的性能，而且使程序設計人員擺脫了自己控制內存使用的風險。

2.5JVM存儲區

JVM有兩類存儲區：常量緩沖池和方法區。

常量緩沖池用於存儲類名稱、方法和欄位名稱以及串常量。

方法區則用於存儲Java方法的位元組碼。

對於這兩種存儲區域具體實現方式在JVM規格中沒有明確規定。

這使得Java應用程序的存儲布局必須在運行過程中確定，依賴於具體平台的實現方式。

JVM是為Java位元組碼定義的一種獨立於具體平台的規格描述，是Java平 *** 立性的基礎。

目前的JVM還存在一些限制和不足，有待於進一步的完善，但無論如何，JVM的思想是成功的。

對比分析：如果把Java原程序想像成我們的C++原程序，Java原程序編譯後生成的位元組碼就相當於C++原程序編譯後的80x86的機器碼（二進製程序文件），JVM虛擬機相當於80x86計算機系統,Java解釋器相當於80x86CPU。

在80x86CPU上運行的是機器碼，在Java解釋器上運行的是Java位元組碼。

Java解釋器相當於運行Java位元組碼的「CPU」,但該「CPU」不是通過硬體實現的，而是用軟體實現的。

Java解釋器實際上就是特定的平台下的一個應用程序。

只要實現了特定平台下的解釋器程序，Java位元組碼就能通過解釋器程序在該平台下運行，這是Java跨平台的根本。

當前，並不是在所有的平台下都有相應Java解釋器程序，這也是Java並不能在所有的平台下都能運行的原因，它只能在已實現了Java解釋器程序的平台下運行。

Ⅳ 寫個編譯器，把C++代碼編譯到JVM的位元組碼可不可行

Java是平台無關的語言是指用Java寫的應用程序不用修改就可在不同的軟硬體平台上運行。平台無關有兩種：源代碼級和目標代碼級。C和C++具有一定程度的源代碼級平台無關，表明用C或C++寫的應用程序不用修改只需重新編譯就可以在不同平台上運行。

Java主要靠Java虛擬機（JVM）在目標碼級實現平台無關性。JVM是一種抽象機器，它附著在具體操作系統之上，本身具有一套虛機器指令，並有自己的棧、寄存器組等。但JVM通常是在軟體上而不是在硬體上實現。（目前，SUN系統公司已經設計實現了Java晶元，主要使用在網路計算機NC上。另外，Java晶元的出現也會使Java更容易嵌入到家用電器中。）JVM是Java平台無關的基礎，在JVM上，有一個Java解釋器用來解釋Java編譯器編譯後的程序。Java編程人員在編寫完軟體後，通過Java編譯器將Java源程序編譯為JVM的位元組代碼。任何一台機器只要配備了Java解釋器，就可以運行這個程序，而不管這種位元組碼是在何種平台上生成的（過程如圖1所示）。另外，Java採用的是基於IEEE標準的數據類型。通過JVM保證數據類型的一致性，也確保了Java的平台無關性。

Ⅵ idea設置springboot啟動jvm參數

idea設置springboot啟動jvm參數，設置方式，通過ldea設置，編輯配置文件。參數說明參數說明-Xms初始化堆內存大小，eg.-Xms1G-Xmx堆內存最大值，eg.-Xms1G，通常與-Xms設置相同的值-XX：ReservedCodeCacheSize代碼緩存，它是用來存儲已編譯方法生成的本地代碼。代碼緩存確實很少引起性能問題，但是一旦發生其影響可能是毀滅性的。如果代碼緩存被占滿，JVM會列印出一條警告消息，並切換到interpreted-only模式：JIT編譯器被停用，位元組碼將不再會被編譯成機器碼。因此，應用程序將繼續運行，但運行速度會降低一個數量級，直到有人注意到這個問題。就像其他內存區域一樣，我們可以自定義代碼緩存的大小。它們的參數都eg.-XX：ReservedCodeCacheSize=240m-XX：InitialC查看更多。