動態編譯技術百度百科
A. 了解什麼叫做jit compiling，與傳統的編譯技術有何不同
java 應用程序的性能經常成為開發社區中的討論熱點。因為該語言的設計初衷是使用解釋的方式支持應用程序的可移植性目標，早期
Java 運行時所提供的性能級別遠低於 C 和
C++
之類的編譯語言。盡管這些語言可以提供更高的性能，但是生成的代碼只能在有限的幾種系統上執行。在過去的十年中，Java
運行時供應商開發了一些復雜的動態編譯器，通常稱作即時（Just-in-time，JIT）編譯器。程序運行時，JIT
編譯器選擇將最頻繁執行的方法編譯成本地代碼。運行時才進行本地代碼編譯而不是在程序運行前進行編譯（用 C 或
C++ 編寫的程序正好屬於後一情形），保證了可移植性的需求。有些 JIT 編譯器甚至不使用解釋程序就能編譯所有的代碼，但是這些編譯器仍然通過在程序執行時進行一些操作來保持 Java 應用程序的可移植性。
由於動態編譯技術的多項改進，在很多應用程序中，現代的 JIT 編譯器可以產生與 C 或 C++
靜態編譯相當的應用程序性能。但是，仍然有很多軟體開發人員認為 —— 基於經驗或者傳聞 ——
動態編譯可能嚴重干擾程序操作，因為編譯器必須與應用程序共享 CPU。一些開發人員強烈呼籲對 Java
代碼進行靜態編譯，並且堅信那樣可以解決性能問題。對於某些應用程序和執行環境而言，這種觀點是正確的，靜態編譯可以極大地提高 Java
性能，或者說它是惟一的實用選擇。但是，靜態地編譯 Java 應用程序在獲得高性能的同時也帶來了很多復雜性。一般的
Java 開發人員可能並沒有充分地感受到 JIT 動態編譯器的優點。
本文考察了 Java 語言靜態編譯和動態編譯所涉及的一些問題，重點介紹了實時 (RT) 系統。簡要描述了 Java
語言解釋程序的操作原理並說明了現代 JIT 編譯器執行本地代碼編譯的優缺點。介紹了 IBM 在 WebSphere Real Time 中發布的
AOT 編譯技術和它的一些優缺點。然後比較了這兩種編譯策略並指出了幾種比較適合使用 AOT
編譯的應用程序領域和執行環境。要點在於這兩種編譯技術並不互斥：即使在使用這兩種技術最為有效的各種應用程序中，它們也分別存在一些影響應用程序的優缺
點。
執行 Java 程序
Java 程序最初是通過 Java SDK 的 javac程序編譯成本地的與平台無關的格式（類文件）。可將此格式看作 Java
平台，因為它定義了執行 Java 程序所需的所有信息。Java 程序執行引擎，也稱作 Java 運行時環境（JRE），包含了為特定的本地平台實現
Java 平台的虛擬機。例如，基於 Linux 的 Intel x86 平台、Sun Solaris 平台和 AIX 操作系統上運行的 IBM
System p 平台，每個平台都擁有一個 JRE。這些 JRE 實現實現了所有的本地支持，從而可以正確執行為
Java 平台編寫的程序。
事實上，操作數堆棧的大小有實際限制，但是編程人員極少編寫超出該限制的方法。JVM 提供了安全性檢查，對那些創建出此類方法的編程人員進行通知。
Java 平台程序表示的一個重要部分是位元組碼序列，它描述了 Java
類中每個方法所執行的操作。位元組碼使用一個理論上無限大的操作數堆棧來描述計算。這個基於堆棧的程序表示提供了平台無關性，因為它不依賴任何特定本地平台
的 CPU 中可用寄存器的數目。可在操作數堆棧上執行的操作的定義都獨立於所有本地處理器的指令集。Java
虛擬機（JVM）規范定義了這些位元組碼的執行（參見 參考資料）。執行 Java 程序時，用於任何特定本地平台的任何 JRE 都必須遵守 JVM
規范中列出的規則。
因為基於堆棧的本地平台很少（Intel X87 浮點數協處理器是一個明顯的例外），所以大多數本地平台不能直接執行 Java 位元組碼。為了解決這個問題，早期的 JRE 通過解釋位元組碼來執行 Java 程序。即 JVM 在一個循環中重復操作：
◆獲取待執行的下一個位元組碼；
◆解碼；
◆從操作數堆棧獲取所需的操作數；
◆按照 JVM 規范執行操作；
◆將結果寫回堆棧。
這種方法的優點是其簡單性：JRE 開發人員只需編寫代碼來處理每種位元組碼即可。並且因為用於描述操作的位元組碼少於 255 個，所以實現的成本比較低。當然，缺點是性能：這是一個早期造成很多人對 Java 平台不滿的問題，盡管擁有很多其他優點。
解決與 C 或 C++ 之類的語言之間的性能差距意味著，使用不會犧牲可移植性的方式開發用於 Java 平台的本地代碼編譯。
編譯 Java 代碼
盡管傳聞中 Java 編程的 「一次編寫，隨處運行」
的口號可能並非在所有情況下都嚴格成立，但是對於大量的應用程序來說情況確實如此。另一方面，本地編譯本質上是特定於平台的。那麼 Java
平台如何在不犧牲平台無關性的情況下實現本地編譯的性能？答案就是使用 JIT 編譯器進行動態編譯，這種方法已經使用了十年（參見圖 1）：
圖 1. JIT 編譯器
使用 JIT 編譯器時，Java
程序按每次編譯一個方法的形式進行編譯，因為它們在本地處理器指令中執行以獲得更高的性能。此過程將生成方法的一個內部表示，該表示與位元組碼不同但是其級
別要高於目標處理器的本地指令。（IBM JIT
編譯器使用一個表達式樹序列表示方法的操作。）編譯器執行一系列優化以提高質量和效率，最後執行一個代碼生成步驟將優化後的內部表示轉換成目標處理器的本
地指令。生成的代碼依賴運行時環境來執行一些活動，比如確保類型轉換的合法性或者對不能在代碼中直接執行的某些類型的對象進行分配。JIT
編譯器操作的編譯線程與應用程序線程是分開的，因此應用程序不需要等待編譯的執行。
圖 1 中還描述了用於觀察執行程序行為的分析框架，通過周期性地對線程取樣找出頻繁執行的方法。該框架還為專門進行分析的方法提供了工具，用來存儲程序的此次執行中可能不會改變的動態值。
因為這個 JIT 編譯過程在程序執行時發生，所以能夠保持平台無關性：發布的仍然是中立的 Java 平台代碼。C 和 C++ 之類的語言缺乏這種優點，因為它們在程序執行前進行本地編譯；發布給（本地平台）執行環境的是本地代碼。
挑戰
盡管通過 JIT 編譯保持了平台無關性，但是付出了一定代價。因為在程序執行時進行編譯，所以編譯代碼的時間將計入程序的執行時間。任何編寫過大型 C 或 C++ 程序的人都知道，編譯過程往往較慢。
為了克服這個缺點，現代的 JIT
編譯器使用了下面兩種方法的任意一種（某些情況下同時使用了這兩種方法）。第一種方法是：編譯所有的代碼，但是不執行任何耗時多的分析和轉換，因此可以快
速生成代碼。由於生成代碼的速度很快，因此盡管可以明顯觀察到編譯帶來的開銷，但是這很容易就被反復執行本地代碼所帶來的性能改善所掩蓋。第二種方法是：
將編譯資源只分配給少量的頻繁執行的方法（通常稱作熱方法）。低編譯開銷更容易被反復執行熱代碼帶來的性能優勢掩蓋。很多應用程序只執行少量的熱方法，因
此這種方法有效地實現了編譯性能成本的最小化。
動態編譯器的一個主要的復雜性在於權衡了解編譯代碼的預期獲益使方法的執行對整個程序的性能起多大作用。一個極端的例子是，程序執行後，您非常清楚哪些方
法對於這個特定的執行的性能貢獻最大，但是編譯這些方法毫無用處，因為程序已經完成。而在另一個極端，程序執行前無法得知哪些方法重要，但是每種方法的潛
在受益都最大化了。大多數動態編譯器的操作介於這兩個極端之間，方法是權衡了解方法預期獲益的重要程度。
Java 語言需要動態載入類這一事實對 Java
編譯器的設計有著重要的影響。如果待編譯代碼引用的其他類還沒有載入怎麼辦？比如一個方法需要讀取某個尚未載入的類的靜態欄位值。Java
語言要求第一次執行類引用時載入這個類並將其解析到當前的 JVM
中。直到第一次執行時才解析引用，這意味著沒有地址可供從中載入該靜態欄位。編譯器如何處理這種可能性？編譯器生成一些代碼，用於在沒有載入類時載入並解
析類。類一旦被解析，就會以一種線程安全的方式修改原始代碼位置以便直接訪問靜態欄位的地址，因為此時已獲知該地址。
IBM JIT
編譯器中進行了大量的努力以便使用安全而有效率的代碼補丁技術，因此在解析類之後，執行的本地代碼只載入欄位的值，就像編譯時已經解析了欄位一樣。另外一
種方法是生成一些代碼，用於在查明欄位的位置以前一直檢查是否已經解析欄位，然後載入該值。對於那些由未解析變成已解析並被頻繁訪問的欄位來說，這種簡單
的過程可能帶來嚴重的性能問題。
動態編譯的優點
動態地編譯 Java 程序有一些重要的優點，甚至能夠比靜態編譯語言更好地生成代碼，現代的 JIT 編譯器常常向生成的代碼中插入掛鉤以收集有關程序行為的信息，以便如果要選擇方法進行重編譯，就可以更好地優化動態行為。
關於此方法的一個很好的例子是收集一個特定 array操作的長度。如果發現每次執行操作時該長度基本不變，則可以為最頻繁使用的
array長度生成專門的代碼，或者可以調用調整為該長度的代碼序列。由於內存系統和指令集設計的特性，用於復制內存的最佳通用常式的執行速度通
常比用於復制特定長度的代碼慢。例如，復制 8
個位元組的對齊的數據可能需要一到兩條指令直接復制，相比之下，使用可以處理任意位元組數和任意對齊方式的一般復制循環可能需要 10 條指令來復制同樣的 8
個位元組。但是，即使此類專門的代碼是為某個特定的長度生成的，生成的代碼也必須正確地執行其他長度的復制。生成代碼只是為了使常見長度的操作執行得更快，
因此平均下來，性能得到了改進。此類優化對大多數靜態編譯語言通常不實用，因為所有可能的執行中長度恆定的操作比一個特定程序執行中長度恆定的操作要少得
多。
此類優化的另一個重要的例子是基於類層次結構的優化。例如，一個虛方法調用需要查看接收方對象的類調用，以便找出哪個實際目標實現了接收方對象的虛方法。
研究表明：大多數虛調用只有一個目標對應於所有的接收方對象，而 JIT
編譯器可以為直接調用生成比虛調用更有效率的代碼。通過分析代碼編譯後類層次結構的狀態，JIT
編譯器可以為虛調用找到一個目標方法，並且生成直接調用目標方法的代碼而不是執行較慢的虛調用。當然，如果類層次結構發生變化，並且出現另外的目標方法，
則 JIT
編譯器可以更正最初生成的代碼以便執行虛調用。在實踐中，很少需要作出這些更正。另外，由於可能需要作出此類更正，因此靜態地執行這種優化非常麻煩。
因為動態編譯器通常只是集中編譯少量的熱方法，所以可以執行更主動的分析來生成更好的代碼，使編譯的回報更高。事實上，大部分現代的
JIT
編譯器也支持重編譯被認為是熱方法的方法。可以使用靜態編譯器（不太強調編譯時間）中常見的非常主動的優化來分析和轉換這些頻繁執行的方法，以便生成更好
的代碼並獲得更高的性能。
這些改進及其他一些類似的改進所產生的綜合效果是：對於大量的 Java 應用程序來說，動態編譯已經彌補了與 C 和 C++ 之類語言的靜態本地編譯性能之間的差距，在某些情況下，甚至超過了後者的性能。
缺點
但是，動態編譯確實具有一些缺點，這些缺點使它在某些情況下算不上一個理想的解決方案。例如，因為識別頻繁執行的方法以及編譯這些方法需要時間，所以應用
程序通常要經歷一個准備過程，在這個過程中性能無法達到其最高值。在這個准備過程中出現性能問題有幾個原因。首先，大量的初始編譯可能直接影響應用程序的
啟動時間。不僅這些編譯延遲了應用程序達到穩定狀態的時間（想像 Web
伺服器經
歷一個初始階段後才能夠執行實際有用的工作），而且在准備階段中頻繁執行的方法可能對應用程序的穩定狀態的性能所起的作用也不大。如果 JIT
編譯會延遲啟動又不能顯著改善應用程序的長期性能，則執行這種編譯就非常浪費。雖然所有的現代 JVM
都執行調優來減輕啟動延遲，但是並非在所有情況下都能夠完全解決這個問題。
其次，有些應用程序完全不能忍受動態編譯帶來的延遲。如 GUI 介面之類互動式應用程序就是這樣的例子。在這種情況下，編譯活動可能對用戶使用造成不利影響，同時又不能顯著地改善應用程序的性能。
最後，用於實時環境並具有嚴格的任務時限的應用程序可能無法忍受編譯的不確定性性能影響或動態編譯器本身的內存開銷。
因此，雖然 JIT 編譯技術已經能夠提供與靜態語言性能相當（甚至更好）的性能水平，但是動態編譯並不適合於某些應用程序。在這些情況下，Java 代碼的提前（Ahead-of-time，AOT）編譯可能是合適的解決方案。
AOT Java 編譯
大致說來，Java 語言本地編譯應該是為傳統語言（如 C++ 或
Fortran）而開發的編譯技術的一個簡單應用。不幸的是，Java 語言本身的動態特性帶來了額外的復雜性，影響了 Java
程序靜態編譯代碼的質量。但是基本思想仍然是相同的：在程序執行前生成 Java 方法的本地代碼，以便在程序運行時直接使用本地代碼。目的在於避免
JIT 編譯器的運行時性能消耗或內存消耗，或者避免解釋程序的早期性能開銷。
挑戰
動態類載入是動態 JIT 編譯器面臨的一個挑戰，也是 AOT
編譯的一個更重要的問題。只有在執行代碼引用類的時候才載入該類。因為是在程序執行前進行 AOT
編譯的，所以編譯器無法預測載入了哪些類。就是說編譯器無法獲知任何靜態欄位的地址、任何對象的任何實例欄位的偏移量或任何調用的實際目標，甚至對直接調
用（非虛調用）也是如此。在執行代碼時，如果證明對任何這類信息的預測是錯誤的，這意味著代碼是錯誤的並且還犧牲了 Java 的一致性。
因為代碼可以在任何環境中執行，所以類文件可能與代碼編譯時不同。例如，一個 JVM
實例可能從磁碟的某個特定位置載入類，而後面一個實例可能從不同的位置甚至網路載入該類。設想一個正在進行 bug
修復的開發環境：類文件的內容可能隨不同的應用程序的執行而變化。此外，Java 代碼可能在程序執行前根本不存在：比如 Java
反射服務通常在運行時生成新類來支持程序的行為。
缺少關於靜態、欄位、類和方法的信息意味著嚴重限制了 Java 編譯器中優化框架的大部分功能。內聯可能是靜態或動態編譯器應用的最重要的優化，但是由於編譯器無法獲知調用的目標方法，因此無法再使用這種優化。
內聯
內聯是一種用於在運行時生成代碼避免程序開始和結束時開銷的技術，方法是將函數的調用代碼插入到調用方的函數中。但是內聯最大的益處可能是優化方可見的代碼的范圍擴大了，從而能夠生成更高質量的代碼。下面是一個內聯前的代碼示例：
int foo() { int x=2, y=3; return bar(x,y); }final int bar(int a, int b) { return a+b; }
如果編譯器可以證明這個 bar就是 foo()中調用的那個方法，則 bar中的代碼可以取代 foo()中對
bar()的調用。這時，bar()方法是 final類型，因此肯定是 foo()中調用的那個方法。甚至在一些虛調用例子中，動態 JIT
編譯器通常能夠推測性地內聯目標方法的代碼，並且在絕大多數情況下能夠正確使用。編譯器將生成以下代碼：
int foo() { int x=2, y=3; return x+y; }
在這個例子中，簡化前名為值傳播的優化可以生成直接返回
5的代碼。如果不使用內聯，則不能執行這種優化，產生的性能就會低很多。如果沒有解析
bar()方法（例如靜態編譯），則不能執行這種優化，而代碼必須執行虛調用。運行時，實際調用的可能是另外一個執行兩個數字相乘而不是相加的
bar方法。所以不能在 Java 程序的靜態編譯期間直接使用內聯。
AOT
代碼因此必須在沒有解析每個靜態、欄位、類和方法引用的情況下生成。執行時，每個這些引用必須利用當前運行時環境的正確值進行更新。這個過程可能直接影響
第一次執行的性能，因為在第一次執行時將解析所有引用。當然，後續執行將從修補代碼中獲益，從而可以更直接地引用實例、靜態欄位或方法目標。
另外，為 Java 方法生成的本地代碼通常需要使用僅在單個 JVM 實例中使用的值。例如，代碼必須調用 JVM
運行時中的某些運行時常式來執行特定操作，如查找未解析的方法或分配內存。這些運行時常式的地址可能在每次將 JVM 載入到內存時變化。因此 AOT
編譯代碼需要綁定到 JVM 的當前執行環境中，然後才能執行。其他的例子有字元串的地址和常量池入口的內部位置。
在 WebSphere Real Time 中，AOT 本地代碼編譯通過 jxeinajar工具（參見圖 2）來執行。該工具對 JAR 文件中所有類的所有方法應用本地代碼編譯，也可以選擇性地對需要的方法應用本地代碼編譯。結果被存儲到名為 Java eXEcutable (JXE) 的內部格式中，但是也可輕松地存儲到任意的持久性容器中。
您可能認為對所有的代碼進行靜態編譯是最好的方法，因為可以在運行時執行最大數量的本地代碼。但是此處可以作出一些權衡。編譯的方法越多，代碼佔用的內存
就越多。編譯後的本地代碼大概比位元組碼大 10 倍：本地代碼本身的密度比位元組碼小，而且必須包含代碼的附加元數據，以便將代碼綁定到 JVM
中，並且在出現異常或請求堆棧跟蹤時正確執行代碼。構成普通 Java 應用程序的 JAR
文件通常包含許多很少執行的方法。編譯這些方法會消耗內存卻沒有什麼預期收益。相關的內存消耗包括以下過程：將代碼存儲到磁碟上、從磁碟取出代碼並裝入
JVM，以及將代碼綁定到 JVM。除非多次執行代碼，否則這些代價不能由本地代碼相對解釋的性能優勢來彌補。
圖 2. jxeinajar
跟大小問題相違背的一個事實是：在編譯過的方法和解釋過的方法之間進行的調用（即編譯過的方法調用解釋過的方法，或者相反）可能比這兩類方法各自內部之間
進行的調用所需的開銷大。動態編譯器通過最終編譯所有由 JIT
編譯代碼頻繁調用的那些解釋過的方法來減少這項開銷，但是如果不使用動態編譯器，則這項開銷就不可避免。因此如果是選擇性地編譯方法，則必須謹慎操作以使
從已編譯方法到未編譯方法的轉換最小化。為了在所有可能的執行中都避免這個問題而選擇正確的方法會非常困難。
優點
雖然 AOT 編譯代碼具有上述的缺點和挑戰，但是提前編譯 Java 程序可以提高性能，尤其是在不能將動態編譯器作為有效解決方案的環境中。
可以通過謹慎地使用 AOT 編譯代碼加快應用程序啟動，因為雖然這種代碼通常比 JIT
編譯代碼慢，但是卻比解釋代碼快很多倍。此外，因為載入和綁定 AOT
編譯代碼的時間通常比檢測和動態編譯一個重要方法的時間少，所以能夠在程序執行的早期達到那樣的性能。類似地，互動式應用程序可以很快地從本地代碼中獲
益，無需使用引起較差響應能力的動態編譯。
RT 應用程序也能從 AOT 編譯代碼中獲得重要的收益：更具確定性的性能超過了解釋的性能。WebSphere Real Time
使用的動態 JIT 編譯器針對在 RT 系統中的使用進行了專門的調整。使編譯線程以低於 RT
任務的優先順序操作，並且作出了調整以避免生成帶有嚴重的不確定性性能影響的代碼。但是，在一些 RT 環境中，出現 JIT
編譯器是不可接受的。此類環境通常需要最嚴格的時限管理控制。在這些例子中，AOT
編譯代碼可以提供比解釋過的代碼更好的原始性能，又不會影響現有的確定性。消除 JIT
編譯線程甚至消除了啟動更高優先順序 RT 任務時發生的線程搶占所帶來的性能影響。
優缺點統計
動態（JIT）編譯器支持平台中立性，並通過利用應用程序執行的動態行為和關於載入的類及其層次結構的信息來生成高質量的代碼。但是
JIT
編譯器具有一個有限的編譯時預算，而且會影響程序的運行時性能。另一方面，靜態（AOT）編譯器則犧牲了平台無關性和代碼質量，因為它們不能利用程序的動
態行為，也不具有關於載入的類或類層次結構的信息。AOT 編譯擁有有效無限制的編譯時預算，因為 AOT
編譯時間不會影響運行時性能，但是在實踐中開發人員不會長期等待靜態編譯步驟的完成。
表 1 總結了本文討論的 Java 語言動態和靜態編譯器的一些特性：
表 1. 比較編譯技術
兩種技術都需要謹慎選擇編譯的方法以實現最高的性能。對動態編譯器而言，編譯器自身作出決策，而對於靜態編譯器，由開發人員作出選擇。讓
JIT 編譯器選擇編譯的方法是不是優點很難說，取決於編譯器在給定情形中推斷能力的好壞。在大多數情況下，我們認為這是一種優點。
因為它們可以最好地優化運行中的程序，所以 JIT 編譯器在提供穩定狀態性能方面更勝一籌，而這一點在大量的生產 Java
系統中最為重要。靜態編譯可以產生最佳的互動式性能，因為沒有運行時編譯行為來影響用戶預期的響應時間。通過調整動態編譯器可以在某種程度上解決啟動和確
定性性能問題，但是靜態編譯在需要時可提供最快的啟動速度和最高級別的確定性。表 2 在四種不同的執行環境中對這兩種編譯技術進行了比較：
表 2. 使用這些技術的最佳環境
圖 3 展示了啟動性能和穩定狀態性能的總體趨勢：
圖 3. AOT 和 JIT 的性能對比
使用 JIT 編譯器的初始階段性能很低，因為要首先解釋方法。隨著編譯方法的增多及 JIT
執行編譯所需時間的縮短，性能曲線逐漸升高最後達到性能峰值。另一方面，AOT 編譯代碼啟動時的性能比解釋的性能高很多，但是無法達到 JIT
編譯器所能達到的最高性能。將靜態代碼綁定到 JVM 實例中會產生一些開銷，因此開始時的性能比穩定狀態的性能值低，但是能夠比使用 JIT
編譯器更快地達到穩定狀態的性能水平。
沒有一種本地代碼編譯技術能夠適合所有的 Java
執行環境。某種技術所擅長的通常正是其他技術的弱項。出於這個原因，需要同時使用這兩種編譯技術以滿足 Java
應用程序開發人員的要求。事實上，可以結合使用靜態和動態編譯以便提供最大可能的性能提升 —— 但是必須具備平台無關性，它是 Java
語言的主要賣點，因此不成問題。
結束語
本文探討了 Java 語言本地代碼編譯的問題，主要介紹了 JIT 編譯器形式的動態編譯和靜態 AOT 編譯，比較了二者的優缺點。
雖然動態編譯器在過去的十年裡實現了極大的成熟，使大量的各種 Java 應用程序可以趕上或超過靜態編譯語言（如 C++ 或
Fortran）所能夠達到的性能。但是動態編譯在某些類型的應用程序和執行環境中仍然不太合適。雖然 AOT
編譯號稱動態編譯缺點的萬能解決方案，但是由於 Java 語言本身的動態特性，它也面臨著提供本地編譯全部潛能的挑戰。
這兩種技術都不能解決 Java 執行環境中本地代碼編譯的所有需求，但是反過來又可以在最有效的地方作為工具使用。這兩種技術可以相互補充。能夠恰當地使用這兩種編譯模型的運行時系統可以使很大范圍內的應用程序開發環境中的開發人員和用戶受益。
B. JAVA中反射是什麼
JAVA中反射是動態獲取信息以及動態調用對象方法的一種反射機制。
Java反射就是在運行狀態中，對於任意一個類，都能夠知道這個類的所有屬性和方法；對於任意一個對象，都能夠調用它的任意方法和屬性；並且能改變它的屬性。而這也是Java被視為動態語言的一個關鍵性質。
Java反射的功能是在運行時判斷任意一個對象所屬的類，在運行時構造任意一個類的對象，在運行時判斷任意一個類所具有的成員變數和方法，在運行時調用任意一個對象的方法，生成動態代理。
(2)動態編譯技術百度百科擴展閱讀：
JAVA中反射實例：
1、Class superClass=clazz.getSuperclass();//獲取父類。
System.out.println("getSuperclass："+superClass)。
2、Class[] interfaces=clazz.getInterfaces();//獲取實現介面。
System.out.println("getInterfaces:"+interfaces.length)。
3、Constructor[] cons=clazz.getConstructors();//構造方法。
System.out.println("getConstructors:"+cons.length)。
參考資料來源：網路： JAVA反射機制
C. NIO和TIJ是什麼
JDK 1.4版本(包括之後的版本)最顯著的新特性就是增加了NIO(New IO)，能夠以非阻塞的方式處理網路的請求，這就使得在Java中只需要少量的線程就能處理大量的並發請求了。但是使用NIO不是一件簡單的技術，它的一些特點使得編程的模型比原來阻塞的方式更為復雜。
在JDK 1.4的新特性中，NIO無疑是最顯著和鼓舞人心的。NIO的出現事實上意味著Java虛擬機的性能比以前的版本有了較大的飛躍。在以前的JVM的版本中，代碼的執行效率不高(在最原始的版本中Java是解釋執行的語言)，用Java編寫的應用程序通常所消耗的主要資源就是CPU，也就是說應用系統的瓶頸是CPU的計算和運行能力。在不斷更新的Java虛擬機版本中，通過動態編譯技術使得Java代碼執行的效率得到大幅度提高，幾乎和操作系統的本地語言(例如C/C++)的程序不相上下。在這種情況下，應用系統的性能瓶頸就從CPU轉移到IO操作了。尤其是伺服器端的應用，大量的網路IO和磁碟IO的操作，使得IO數據等待的延遲成為影響性能的主要因素。NIO的出現使得Java應用程序能夠更加緊密地結合操作系統，更加充分地利用操作系統的高級特性，獲得高性能的IO操作。
JIT Compiler(Just-in-time Compiler) 即時編譯 最早的Java建置方案是由一套轉譯程式（interpreter），將每個Java指令都轉譯成對等的微處理器指令，並根據轉譯後的指令先後次序依序執行，由於一個Java指令可能被轉譯成十幾或數十幾個對等的微處理器指令，這種模式執行的速度相當緩慢。 針對這個問題，業界首先開發出JIT（just in time）編譯器。當Java執行runtime環境時，每遇到一個新的類別（class：類別是Java程式中的功能群組），類別是Java程式中的功能群組－JIT編譯器在此時就會針對這個類別進行編譯（compile）作業。經過編譯後的程式，被優化成相當精簡的原生型指令碼（native code），這種程式的執行速度相當快。花費少許的編譯時間來節省稍後相當長的執行時間，JIT這種設計的確增加不少效率，但是它並未達到最頂尖的效能，因為某些極少執行到的Java指令在編譯時所額外花費的時間可能比轉譯器在執行時的時間還長，針對這些指令而言，整體花費的時間並沒有減少。 基於對JIT的經驗，業界發展出動態編譯器（dynamic compiler），動態編譯器僅針對較常被執行的程式碼進行編譯，其餘部分仍使用轉譯程式來執行。也就是說，動態編譯器會研判是否要編譯每個類別。動態編譯器擁有兩項利器：一是轉譯器，另一則是JIT，它透過智慧機制針對每個類別進行分析，然後決定使用這兩種利器的哪一種來達到最佳化的效果。動態編譯器針對程式的特性或者是讓程式執行幾個循環，再根據結果決定是否編譯這段程式碼。這個決定不見得絕對正確，但從統計數字來看，這個判斷的機制正確的機會相當高。事實上，動態編譯器會根據「歷史資料」做決策，所以程式執行的時間愈長，判斷正確的機率就愈高。以整個結果來看，動態編譯器產生的程式碼執行的速度超越以前的JIT技術，平均速度可提高至50%。
D. Java代碼的靜態編譯和動態編譯中的問題是什麼
Java代碼正常是靜態編譯成位元組碼，由對應平台的JVM載入執行，靜態編譯無法動態擴展功能。動態編譯有兩種方式實現：
從源碼編譯，需要調用Java Compiler，程序需要運行於JDK（而不是JRE）之上。
動態位元組碼生成技術（如CGLib、ASM）創建類。
動態編譯可以簡化代碼，增強類功能，但也帶來了代碼復雜度，線上不易維護。
E. 什麼是即時編譯
JIT（just-in-time compilation）指計算機領域里，即時編譯也被成為動態翻譯，是一種通過在運行時將位元組碼翻譯為機器碼，從而改善位元組碼編譯語言性能的技術。即時編譯前期的兩個運行時理論是位元組碼編譯和動態編譯。
在編譯為位元組碼的系統如 Limb 編程語言，Smalltalk, UCSD P-System, Perl, GNU CLISP, 和 Java 的早期版本中， 源代碼被翻譯為一種中間表示即位元組碼。 位元組碼不是任何特定計算機的機器碼， 它可以在多種計算機體系中移植。位元組碼被解釋著運行在虛擬機里。
動態編譯環境是一種在執行時使用編譯器的編譯環境。 例如， 多數 Common Lisp 系統有一個編譯函數，他可以編譯在運行時創建的函數。
F. 軟體工程和數字媒體技術哪個專業比較好
軟體工程和數字媒體技術比軟體工程的培養要求更嚴格、就業前景更廣，數字媒體技術核心課程更齊全。
一、培養要求
1、數字媒體技術：數字媒體技術要求學生掌握數字媒體技術相關專業理論與專業技能，具有較高藝術欣賞水準與創意思維、較強工科創新設計與實踐開發能力。培養要求更寬松。
2、軟體工程：軟體工程要求學生掌握掌握 計算科學基礎理論、軟體工程專業的基礎知識及應用知識，具有軟體開發能力以及軟體開發實踐 的初步經驗和項目組織的基本能力。培養要求更嚴格。
二、核心課程
1、數字媒體技術：數字媒體技術的核心課程有C語言、面向對象程序設計、數字媒體技術概論、程序設計、數據結構、計算機圖形學、數據可視化、影視後期與特效技術、數字圖像處理、人機交互技術、虛擬現實技術、人工智慧與新媒體、游戲架構與技術基礎。
移動游戲技術、Unity應用開發、數字媒體產業概論、動畫設計原理、三維動畫技術、Maya基礎與建模等。核心課程更齊全。
2、軟體工程：軟體工程的核心課程有程序設計語言、數據結構、離散數學、操作系統、編譯技術、軟體工程概論、統一建模語言、軟體體系結構、軟體需求、軟體項目管理。
離散數學、數據結構、演算法分析、面向對象程序設計、現代操作系統、資料庫原理與實現技術、編譯原理、軟體工程、軟體項目管理、計算機安全等課程等。核心課程更缺失。
三、就業前景
1、數字媒體技術：數字媒體技術可到互聯網企業、文化傳播機構、新聞傳媒或融媒體機構、影視、廣告或動漫公司、游戲或軟體公司、教育與培訓機構、機關事業單位等相關崗位，從事信息內容或交互平台的設計與開發及項目管理等工作，或自主創業。就業前景更窄。
2、軟體工程：軟體工程可以從事各級各類企事業單位的辦公自動化處理、計算機安裝與維護、網頁製作、計算機網路和專業伺服器的維護管理和開發工作、動態商務網站開發與管理、軟體測試與開發及計算機相關設備的商品貿易等方面的有關工作。就業前景更廣。
參考資料來源：
網路——數字媒體技術
網路——軟體工程
G. 動態鏈接，靜態鏈接 動態編譯，靜態編譯 動態鏈接庫，靜態鏈接庫 這些兩兩間的區別是什麼呢
有點兒亂……，分數少簡單扼要的說說吧。
————————————
首先，傳統的編譯，也就是靜態編譯是把 源文件 翻譯成目標文件，這個是一次性過程，也就是你所謂的靜態編譯。
後來的Java和.NET等語言，首先編譯成中間形式，然後運行過程中根據需要編譯成本地代碼（注意這個過程不是一次性的，下次運行重新編譯），這個就是JIT（即時編譯）技術，從即時編譯發展出了動態編譯技術
————————————
（傳統的）編譯完成後，像C/C++、Fortran、匯編等語言，可以把多個目標文件合並到一個庫文件中，這個就是靜態庫。比如常說的庫函數printf就是libc裡面的函數。
如果有了啟動函數（main），main裡面使用了printf，就可以通過靜態鏈接技術，從libc中提取出printf所在的文件加入到可執行文件中，如果printf還需要其它函數，就繼續搜索並加入列表，直到形成一個閉包。這個就是靜態鏈接。
可是靜態鏈接有個明顯的缺點，如果每個程序都需要printf，那麼printf這個函數的代碼就會同時存在在每個程序中，這樣也太佔地方了吧。所以發明了動態連接技術，其實有兩種形式。無論哪一種，都是首先記錄下需要調用printf這個函數以及所在的動態庫，等到運行的時候再載入動態庫，從動態庫中找到真正的printf去執行。
由於，動態鏈接技術需要一些額外的信息，傳統的靜態庫是不具備的，這些額外信息主要是重復載入和卸載時所需要的一些代碼，因此需要動態鏈接庫。
H. 什麼是虛擬化技術虛擬化技術有哪些分類和方法
要了解詳情，請加我的號，或照片上有我的照片，我們私聊。
可以免費試用的哦！！！！！！！！！
自從虛擬化提出以後，至今虛擬化技術分類有很多，方法也有很多，下面來一起了解下什麼是虛擬化技術，及分類和方法。
當今發達國家在設計、製造、加工技術等方面已經達到相當自動化的水平，其產品設計普遍採用CAD、CAM、CAE和計算機模擬等手段，企業管理也已採用了科學的規范化的管理方法和手段，目前其主要從製造系統自動化方面尋找出路，為此提出了一系列新的製造系統，如敏捷製造、並行工程、計算機集成製造系統等。近些年，從虛擬機的大量部署到成功案例逐漸涌現，越來越多的製造企業開始關注虛擬化技術給優化IT基礎架構，推動業務創新帶來的啟發，希望將其與業務相結合，找到掌握新技術、革新先進製造系統和先進製造模式的方法。虛擬化目前應用於製造業信息化主要體現在IT整合和節約成本，在其他方面很少，而實際上由於虛擬化技術的特點，其應用價值可以在遠程辦公、虛擬製造、工業控制等製造業相關領域都能得到體現。本文主要對虛擬化技術及其在製造業的應用現狀進行綜述，提出虛擬化在製造業的應用框架，為相關人員提供該領域的應用研究進展與發展趨勢方面的介紹。
1 虛擬化技術
虛擬化是指為運行的程序或軟體營造它所需要的執行環境，在採用虛擬化技術後，程序或軟體的運行不再獨享底層的物理計算資源，它只是運行在一個完全相同的物理計算資源中，而底層的影響可能與之前所運行的計算機結構完全不同。虛擬化的主要目的是對IT基礎設施和資源管理方式的簡化。虛擬化的消費者可以是最終用戶、應用程序、操作系統、訪問資源或與資源交互相關的其他服務。由於虛擬化能降低消費者與資源之間的耦合程度，消費者不再依賴於資源的特定實現，因此在對消費者的管理工作影響最小的基礎上，可以通過手工、半自動、或者服務級協定（SLA）等來實現對資源的管理。
1.1 虛擬化的分類
從虛擬化的目的來看，虛擬化技術主要分為以下幾個大類：
（1）平台虛擬化（Platform Virtualization），它是針對計算機和操作系統的虛擬化，又分成伺服器虛擬化和桌面虛擬化。伺服器虛擬化是一種通過區分資源的優先次序，並將伺服器資源分配給最需要它們的工作負載的虛擬化模式，它通過減少為單個工作負載峰值而儲備的資源來簡化管理和提高效率。桌面虛擬化是為提高人對計算機的操控力，降低計算機使用的復雜性，為用戶提供更加方便適用的使用環境的一種虛擬化模式。平台虛擬化主要通過CPU虛擬化、內存虛擬化和I/O介面虛擬化來實現。
（2）資源虛擬化（Resource Virtualization），針對特定的計算資源進行的虛擬化，例如，存儲虛擬化、網路資源虛擬化等。存儲虛擬化是指把操作系統有機地分布於若干內外存儲器，兩者結合成為虛擬存儲器。網路資源虛擬化最典型的是網格計算，網格計算通過使用虛擬化技術來管理網路上的數據，並在邏輯上將其作為一個系統呈現給消費者，它動態地提供了符合用戶和應用程序需求的資源，同時還將提供對基礎設施的共享和訪問的簡化。當前，有些研究人員提出利用軟體代理技術來實現計算網路空間資源的虛擬化，如Gaia，Net Chaser[21]，Spatial Agent。
（3）應用程序虛擬化（Application Virtualization），它包括模擬、模擬、解釋技術等。Java 虛擬機是典型的在應用層進行虛擬化。基於應用層的虛擬化技術，通過保存用戶的個性化計算環境的配置信息，可以實現在任意計算機上重現用戶的個性化計算環境。服務虛擬化是近年研究的一個熱點，服務虛擬化可以使業務用戶能按需快速構建應用的需求，通過服務聚合，可屏蔽服務資源使用的復雜性，使用戶更易於直接將業務需求映射到虛擬化的服務資源。現代軟體體系結構及其配置的復雜性阻礙了軟體開發生命周期，通過在應用層建立虛擬化的模型，可以提供最佳開發測試和運行環境。
（4）表示層虛擬化。在應用上與應用程序虛擬化類似，所不同的是表示層虛擬化中的應用程序運行在伺服器上，客戶機只顯示應用程序的UI界面和用戶操作。表示層虛擬化軟體主要有微軟的Windows 遠程桌面（包括終端服務）、Citrix Metaframe Presentation Server和Symantec PcAnywhere等。
1.2 虛擬化的方法
通常所說的虛擬化主要是指平台虛擬化，它通過控製程序隱藏計算平台的實際物理特性，為用戶提供抽象的、統一的、模擬的計算環境。通常虛擬化可以通過指令級虛擬化和系統級虛擬化來實現。
1.2.1 指令級虛擬化方法
在指令集層次上實現虛擬化，即將某個硬體平台上的二進制代碼轉換為另一個平台上的二進制代碼，實現不同指令集間的兼容，也被稱作「二進制翻譯」。二進制翻譯是通過模擬來實現的，即在一個具有某種介面和功能的系統上實現另一種與之具有不同介面和功能的系統。二進制翻譯的軟體方式，它可以有3 種方式實現：解釋執行、靜態翻譯、動態翻譯。
近年來，最新的二進制翻譯系統的研究主要在運行時編譯、自適應優化方面，由於動態翻譯和執行過程的時間開銷主要包括四部分：即磁碟訪問開銷、存儲訪問開銷、翻譯和優化開銷、目標代碼的執行開銷，所以要提高二進制翻譯系統的效率主要應減少後3個方面的開銷。目前典型的二進制翻譯系統主要有Daisy/BOA、Crusoe、Aeries、IA-32EL、Dynamo 動態優化系統和JIT編譯技術等。
1.2.2 系統級虛擬化方法
系統虛擬化是在一台物理機上虛擬出多個虛擬機。從系統架構看，虛擬機監控器（VMM）是整個虛擬機系統的核心，它承擔了資源的調度、分配和管理，保證多個虛擬機能夠相互隔離的同時運行多個客戶操作系統。系統級虛擬化要通過CPU虛擬化、內存虛擬化和I/O虛擬化實現。
（1）CPU虛擬化
CPU虛擬化為每個虛擬機提供一個或多個虛擬CPU，多個虛擬CPU分時復用物理CPU，任意時刻一個物理CPU只能被一個虛擬CPU使用。VMM必須為各虛擬CPU合理分配時間片並維護所有虛擬CPU的狀態，當一個虛擬CPU的時間片用完需要切換時，要保存當前虛擬CPU的狀態，將被調度的虛擬CPU的狀態載入物理CPU。X86 的CPU虛擬化方法主要有：二進制代碼動態翻譯（dynamic binary translation）、半虛擬化（para-virtualization）和預虛擬化技術。為了彌補處理器的虛擬化缺陷，現有的虛擬機系統都採用硬體輔助虛擬化技術。CPU虛擬化需要解決的問題是：①虛擬CPU的正確運行，虛擬CPU正確運行的關鍵是保證虛擬機指令正確執行，各虛擬機之間不互相影響，即指令的執行結果不改變其他虛擬機的狀態，目前主要是通過模擬執行和監控運行；②虛擬CPU的調度。虛擬CPU的調度是指由VMM決定當前哪一個虛擬CPU實際在物理CPU上運行，保證虛擬機之間的隔離性、虛擬CPU的性能、調度的公平。虛擬機環境的調度需求是要充分利用CPU資源、支持精確的CPU分配、性能隔離、考慮虛擬機之間的不對等、考慮虛擬機之間的依賴。常見的CPU調度演算法有BVT、SEDF、CB等。
（2）內存虛擬化
VMM通常採用分塊共享的思想來虛擬計算機的物理內存。VMM將機器的內存分配給各個虛擬機，並維護機器內存和虛擬機內存之間的映射關系，這些內存在虛擬機看來是一段從地址0 開始的、連續的物理地址空間。在進行內存虛擬化後，內存地址將有機器地址、偽物理地址和虛擬地址三種地址。在X86 的內存定址機制中，VMM能夠以頁面為單位建立虛擬地址到機器地址的映射關系，並利用頁面許可權設置實現不同虛擬機間內存的隔離和保護。為了提高地址轉換的性能，X86 處理器中加入TLB，緩存已經轉換過的虛擬地址，在每次虛擬地址空間切換時，硬體自動完成切塊TLB。為了實現虛擬地址到物理地址的高效轉換，通常採取復合映射的思想，通過MMU半虛擬化和影子頁表來實現頁表的虛擬化。虛擬機監控器的數據不能被虛擬機訪問，因此需要一種隔離機制，這種隔離機制主要通過修改客戶操作系統或段保護來實現。內存虛擬化的優化機制，包括按需取頁、虛擬存儲、內存共享等。
（3）I/O虛擬化
由於I/O設備具有異構性強，內部狀態不易控制等特點，VMM系統針對I/O設備虛擬化有全虛擬化、半虛擬化、軟體模擬和直接I/O訪問等設計思路。近年來，更多的學者將I/O虛擬化的研究放在共享的網路設備虛擬化研究，提出將IOVM結構映射到多核心伺服器平台。I/O設備除了增加吞吐量和固有的並行數據流、聯系串列特性以及基於分組的協議外，還應該考慮到傳統的PCI 兼容的PCI Express的硬體，建立相應的匯流排適配器，以彌補象單一主機無專門的驅動程序時的需要。有些研究人員專注於外存儲虛擬化的研究，提出讓存儲虛擬化系統上的SCSI目標模擬器運行在SAN上，存儲動態的目標主機的物理信息，並使用映射表方法來修改SCSI命令地址，使用點陣圖的技術來管理可用空間等思想。存儲虛擬化系統應提供諸如邏輯卷大小、各種功能、數據鏡像和快照，並兼容集群主機和多個操作系統。由於外存儲虛擬化能全面提升存儲區域網路的服務質量，而帶外虛擬化與帶內虛擬化相比具有性能高和擴展性好等優點，通過運用按序操作、Redo日誌以及日誌完整性鑒別，設計基於關系模型的磁碟上虛擬化元數據組織方式，可以形成一致持久的帶外虛擬化系統。
1.3 虛擬化的管理
虛擬化的管理主要指多虛擬機系統的管理，多虛擬機系統是指在對多計算系統資源抽象表示的基礎上，按照自己的資源配置構建虛擬計算系統，其主要包括虛擬機的動態遷移技術和虛擬機的管理技術。
（1）虛擬機之間的遷移
將虛擬化作為一種手段管理現有的資源和加強其在網路計算的利用率，通過構建分布式可重構的虛擬機，必要時在物理伺服器運行時遷移服務。通過移動代理技術、分布式虛擬機等提高資源利用率和服務可用性，通過尋找服務最優的策略在可重構和分布式虛擬機上遷移。為了將虛擬機運行的操作系統與應用程序從一個物理結點遷移到另外一個運行結點，同時保持客戶操作系統和應用程序不受干擾，有些研究者提出以數據為中心的可遷移的虛擬運行環境，使得用戶操作環境實現異地遷移、無縫重構；
也有研究人員提出程序執行環境的動態按需配置機制。在跨物理伺服器遷移虛擬機，進行自動化的虛擬伺服器的管理，必須考慮高層次的服務質量要求和資源管理成本。有些研究人員提出了通過管理程序控制的方法，以支持移動IP的實時遷移虛擬機在網路上，使虛擬機實時遷移其分布計算資源，從而改善遷移性能，降低網路恢復延遲，提供高可靠性和容錯。有些研究機構通過設計一個通用的硬體抽象層，實現多個虛擬機的移植，具有高效率執行環境中的移動設備。虛擬機的遷移步驟一般有啟動遷移、內存遷移、凍結虛擬機、虛擬機恢復執行。
（2）虛擬機的管理
對於多虛擬機來說，一個非常重要的方面是減少用戶對動態的和復雜的物理設備的管理和維護，通過軟體和工具來實現任務管理。當前典型的多虛擬機伺服器管理軟體是Virtual Infrastructure，它通過Virtual Center管理伺服器的虛擬機池，通過VMotion完成虛擬機的遷移，通過VMFS管理多虛擬機文件系統。其次，Parallax 是針對Xen 的多虛擬機管理器，它通過採用消除寫共享，增強客戶端的緩存等方式並利用模板映像來建立整個系統；同時使用快照（snapshot）以及寫時復制（-on-write）機制來實現塊級共享，並使用副本來保證可用性。虛擬機監控器直接控制parallax 使用的物理盤，它們運行物理設備驅動器，並給虛擬磁碟鏡像VDI 的本地虛擬機提供一個普通的塊介面。
2 虛擬化在製造業信息化中的應用
2.1 虛擬化在製造業信息化中的應用框架
當今製造業正朝著精密化、自動化、柔性化、集成化、網路化、信息化和智能化的方向發展，在這種趨勢下，誕生了許多先進製造技術和先進製造模式。這些先進製造技術和先進製造模式要求現有的IT基礎設施能提供更高的計算服務水平，因此在製造業信息化中，需要建立以虛擬化為導向的資源分配體系結構，提供客戶驅動的服務管理和計算風險管理，維持以服務水平協議（SLA）為導向的資源分配體系。虛擬化在製造業信息化中主要用於集中IT管理、應用整合、工業控制、虛擬製造等。
處在最底層的是製造業企業的虛擬計算資源池（VirtualCluster），它由多台物理伺服器（PhysicsMachine）形成，各物理伺服器上運行著虛擬化軟體（VMM），虛擬化軟體上運行著完成各種任務需求的虛擬機，虛擬計算資源池的虛擬化管理軟體（VMS）為IT環境提供集中化、操作自動化、資源優化的功能，可以快速部署向導和虛擬機模板。虛擬計算資源池中的虛擬機將不同類型的客戶操作系統（Guest OS）和運行其上的數據層、服務層應用程序（App）封裝在一起，形成一個企業協同設計製造的完整系統，為表示層的用戶提供多種形態的數據處理和顯示功能。在圖1 的框架中，虛擬計算資源池的動態資源調度（DRS）模塊可以跨越物理機不間斷地監控資源利用率，並根據反映業務需要和不斷變化的優先順序的預定規則，在多個虛擬機之間分配可用資源。在製造業信息化中，集中IT管理、應用整合、工業控制、虛擬製造等多種應用需求都將以各種服務的形式被封裝到了虛擬機中，例如製造任務協同服務、資源管理服務、信息訪問服務、WWW服務、工業控制服務、應用系統集成服務、數據管理服務、高效能計算服務、工具集服務等；同時支撐所有應用需求的資料庫也被封裝到了虛擬機中，例如企業模型資料庫、製造資源資料庫、產品模型資料庫、專業知識資料庫、用戶信息資料庫等。虛擬化特有的優點使它能確保所有虛擬機中的關鍵業務連續可靠地運行。
2.2 虛擬化在製造業信息化應用框架中的作用
虛擬化在製造業信息化中的應用主要有：
I. Cpython是什麼PyPy是什麼Python和這兩個東西有什麼關系
CPython：是用C語言實現Pyhon，是目前應用最廣泛的解釋器。最新的語言特性都是在這個上面先實現，基本包含了所有第三方庫支持，但是CPython有幾個缺陷，一是全局鎖使Python在多線程效能上表現不佳，二是CPython無法支持JIT（即時編譯），導致其執行速度不及Java和Javascipt等語言。於是出現了Pypy。
Pypy：是用Python自身實現的解釋器。針對CPython的缺點進行了各方面的改良，性能得到很大的提升。最重要的一點就是Pypy集成了JIT。但是，Pypy無法支持官方的C/Python API，導致無法使用例如Numpy，Scipy等重要的第三方庫。這也是現在Pypy沒有被廣泛使用的原因吧。
而PyPy與CPython的不同在於，別的一些python實現如CPython是使用解釋執行的方式，這樣的實現方式在性能上是很凄慘的。而PyPy使用了JIT(即時編譯)技術，在性能上得到了提升。