來自Wiki的困惑：C＃和Java被解釋了嗎？

Question

在EN維基上我讀到C＃和Java都是解釋型語言，但至少對於C＃我認爲這不是真的。

許多解釋語言首先編譯成某種形式的虛擬機 代碼，然後將其任一解釋或編譯在運行時 爲本地代碼。

從我的理解來看，它被編譯成CIL，運行時用JIT編譯成目標平臺。我也讀過JIT是一名口譯員，是真的嗎？ 或者他們被稱爲解釋，因爲他們正在使用中間代碼？我不明白。 謝謝

Answer 1

JIT是一種編譯本機（機器）代碼的形式。 通常（但不作爲必要），無論是CLI和JVM的實施方式在兩個步驟中被編譯：

• 的語言編譯器編譯代碼以執行一些中間（IL /字節碼）
• 的JIT編譯該到運行時的本地/機器代碼

但是，的解釋器確實存在。例如，Micro Framework作爲IL解釋器運行。同樣，像（在這裏看.NET）NGEN和「AOT」（單聲道）這樣的工具可以在開始時編譯爲本機/機器代碼。

Answer 2

它們被認爲是與解釋不同的JIT語言。 JIT在執行期間需要時編譯爲本機代碼。常用的策略是事先編譯成中間表示（字節碼），這使得JIT更快。

但是，沒有什麼能夠阻止它們被解釋，甚至是靜態編譯。語言只是語言 - 從語言的角度來看，語言的執行方式是無關緊要的。

Answer 3

在EN維基我讀的C＃和Java是解釋型語言

你能請提供的鏈接？

可能是解釋這個詞在這裏意味着不同。這或許意味着，這些語言的第一個解釋，將源代碼轉換成獨立於平臺的代碼。（VM具體）

是他們所謂的，因爲他們使用的是中間代碼

我也這麼認爲的解釋。

我也讀了JIT是一種解釋

JIT是一個編譯器。請參閱this

Answer 4

「解釋器」是否取決於討論的上下文。

從純粹抽象的視圖解釋器可以定義爲運行時存在的任何中間程序，它將用一種語言編寫的程序代碼動態地轉換爲其他語言的硬件/軟件的目標代碼。考慮在x86硬件上運行java字節碼，或者在CLR VM上運行Python，究竟IronPython是什麼。在這個視圖中，每個虛擬機都是某種解釋器。由於它是運行時的程序，它明顯不同於靜態編譯器或硬件實現的VM-s。

現在有許多不同的方法可以實現這種功能，其中口音是「動態」和「運行時存在」。

在虛擬機實現問題的討論中，人們明確區分了「經典」解釋器和JIT-ed解釋器。古典解釋器是託管程序的每個指令都發出目標代碼的例程。這種設計很容易構建，但很難優化。 JIT-ed設計讀取一堆原始代碼的指令，然後將所有這些指令轉換爲一個本地編譯的例程。所以它「更快地解釋」。它就像虛擬機中的微型靜態編譯器。有許多不同的方法可以完成標記爲JIT的行爲，然後還有其他方法（如跟蹤編譯器）。

像CLR，HotSpot和J9 JVM這樣的現代虛擬機比使用簡單標籤標記爲JIT或Interpreter更加複雜。它們可以同時處於靜態編譯器（AOT執行），經典解釋器和JIT-VM虛擬機。

例如，CLR可以編譯Ahead-Of-Time（靜態編譯器）代碼，並將本地代碼作爲一堆或多或少的可修改文件存儲在磁盤上，以便用於將來更快啓動託管程序。我相信「ngen」是Windows中用於此功能的AOT過程。如果未使用AOT，則CLR的行爲與JIT VM相同。

根據代碼分析和當前負載，J9和HotSpot可以在運行時在純粹解釋執行或JIT編輯之間進行切換。所以這是相當灰色的地方。 J9甚至具有類似於CLR的AOT功能。

像Maxine JVM或PyPy這樣的其他一些虛擬機稱爲「metacircular」虛擬機。這意味着它們（大部分）是以它們託管的相同語言實現的（Maxine是用Java編寫的JVM）。爲了提供良好的代碼，他們通常在主機語言中實現一些類似JIT的行爲，這些行爲比非常低的，接近機器的解釋器進行引導和優化。

因此，解釋者的實際定義因討論的環境而異。當使用像JIT這樣的標籤時，討論VM的實現細節就有了明顯的重點。