在java中，GraalVM是jvm的未來嗎？給我一個有力的回答。結(jié)論是，graalvm希望成為“終極”虛擬機。大多數(shù)腳本語言或具有動態(tài)效果的語言都需要語言虛擬機來運行，如Cpython、Lua、Er

在java中，GraalVM是jvm的未來嗎？

給我一個有力的回答。結(jié)論是，graalvm希望成為“終極”虛擬機。

大多數(shù)腳本語言或具有動態(tài)效果的語言都需要語言虛擬機來運行，如Cpython、Lua、Erlang、Java、ruby、R、JS、PHP、Perl、APL等。但這些語言的虛擬機層次，是的，是具體實現(xiàn)。例如，Cpython的VM不忍直視，但JVM的hotspot VM、C#的CLR和JS的V8都是最先進的，我們不能用這些虛擬機來運行最先進的技術嗎？

答案基本上是肯定的。首先，Java、Scala和groovy最初是基于JVM的語言。沒有壓力。直接轉(zhuǎn)到JVM。對于Cpython、R、ruby、PHP甚至我們自己編寫的一種新語言，讓我們回顧一下我們的一般做法：首先將源代碼解析為ast，然后編寫一個ast解釋器->；當一些人使用這種語言時，語言設計者可能會繼續(xù)迭代并實現(xiàn)一個虛擬機，包括GC、runtime等。，而且代碼執(zhí)行仍然是ast解釋器->更多的人使用它，然后如果語言社區(qū)有足夠的資金和人力，它可以編寫JIT編譯器，提高GC性能等等。大多數(shù)語言都達不到這一步。我們希望ast解釋器節(jié)點中的語言性能足夠好。我們不需要在性能優(yōu)化上花費太多的精力和金錢。這就是truffle語言框架的動機。Truffle是一個Java框架，它自然地在JVM上運行。在此框架下，用戶只需實現(xiàn)特定語言的ast解釋器，工作量相對較小，性能也足夠好。

Java能不能像C語言不通過JVM虛擬機直接編譯成二進制機器碼，讓計算機直接運行？

從語言設計的角度看，可以通過重新設計編譯器來實現(xiàn)，但從工程實踐的角度看是不可行的。

首先，Java語言最大的特點是跨平臺的可移植性，一次開發(fā)，一次編譯，多平臺執(zhí)行。這個特性是通過JVM（Java虛擬機）實現(xiàn)的。如果重寫編譯器直接編譯成C語言這樣的可執(zhí)行程序，它將失去跨平臺特性。

其次，Java語言在設計之初就被設計成嚴重依賴JRE（Java運行時環(huán)境）的語言。一些語言設計缺陷必須依靠JVM來解決，比如GC（垃圾收集）。我們知道Java語言沒有內(nèi)存恢復能力，所以我們不得不依賴JVM。在工程實踐中，如果軟件不能進行內(nèi)存恢復，后果將是災難性的。

第三，Java語言是面向?qū)ο蟮?，不同于同樣面向?qū)ο蟮腃語言，Java還具有動態(tài)特性。

它允許程序動態(tài)加載運行過程中所需的類，這在面向?qū)ο缶幊讨惺荂語言無法實現(xiàn)的。在C語言編程過程中，每次向類中添加實例變量或成員函數(shù)時，引用該類的所有子類都必須重新編譯，否則會導致程序崩潰。Java從以下幾個方面采取措施來解決這個問題。java編譯器沒有將對實例變量和成員函數(shù)的引用編譯成數(shù)值引用，而是將符號引用信息保存在字節(jié)碼中并傳遞給解釋器，解釋器在動態(tài)連接類后將符號引用信息轉(zhuǎn)換成數(shù)值偏移量。這樣，在內(nèi)存中生成的對象不會在編譯期間確定，而是延遲到運行時并由解釋器確定。這樣，更新類中的變量和方法不會影響現(xiàn)有代碼。在解釋和執(zhí)行字節(jié)碼時，只有在出現(xiàn)新名稱時才執(zhí)行一次符號信息的搜索和轉(zhuǎn)換，然后才能全速執(zhí)行代碼。在運行時確定引用的好處是可以使用更新的類，而不用擔心影響原始代碼。如果程序連接到網(wǎng)絡中另一個系統(tǒng)中的類，則該類的所有者可以自由更新該類，而不會使引用該類的任何程序崩潰。這完全取決于JRE。

以上幾點決定了Java不能像C語言那樣直接編譯成機器代碼。當然，還有其他一些因素，但我認為以上幾點是最重要的。