策略預編譯技術

① 了解什麼叫做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 執行環境中本地代碼編譯的所有需求，但是反過來又可以在最有效的地方作為工具使用。這兩種技術可以相互補充。能夠恰當地使用這兩種編譯模型的運行時系統可以使很大范圍內的應用程序開發環境中的開發人員和用戶受益。

② 運行策略編程和腳本編程有何異同

腳本語言：又被稱為擴建的語言，或者動態語言，是一種編程語言，用來控制軟體應用程序。 2、編程語言：一種計算機語言讓程序員能夠准確地定義計算機所需要使用的數據，並精確地定義在不同情況下所應當採取的行動。 二、特點不同 1、腳本語言：腳本通常以文本（如ASCII)保存，只在被調用時進行解釋或編譯。 2、編程語言：程序在運行時可以改變其結構，開發快速，接近自然語言，易於理解，更方便的代碼管理。 三、優缺點不同 1、腳本語言：腳本語言極大地簡化了「開發、部署、測試和調試」的周期過程。大多數腳本語言都能夠隨時部署，而不需要耗時的編譯/打包過程。 2、編程語言：任何編程語言的使用都需要確保編寫的程序能。
編程語言包含腳本語言的。 不過腳本語言和一般語言等的區別是 1、一般編程語言要編譯連接成可執行文件，才能執行。腳本語言直接解釋執行 2、一般語言用作系統程序或者應用程序開發，腳本語言常用來做系統管理 3、一般語言用起來麻煩，必須編譯才能運行，但是，一旦編譯後，可脫離環境運行，而腳本語言必須安裝對應的腳本環境 4、腳本語言相對系統管理方面比一般語言強大，而且便攜性好，其執行環境一般比較小，有的只是一個解釋器。 5、腳本語言便於交流 腳本語言包含: HTML通常用於格式化和鏈結文本。而編程語言通常用於向機器發出一系列復雜的指令。 2.腳本語言與編程語言也有很多相似地方，其函數與編程語言比較相象一些,其也涉及到變數。與編程語言之間最大的區別是編程語言的語法和規則更為嚴格和復雜一些. 3.與程序代碼的關系:腳本也是一種語言，其同樣由程序代碼組成。 註：腳本語言一般都有相應的腳本引擎來解釋執行。 他們一般需要解釋器才能運行。JAVASCRIPT,ASP,PHP,PERL都是腳本語言。C/C++編譯、鏈接後，可形成獨立執行的exe文件。

③ 並行處理技術的策略及定義

在並行處理技術中所使用的演算法主要遵循三種策略：
1．分而治之法：也就是把多個任務分解到多個處理器或多個計算機中，然後再按照一定的拓撲結構來進行求解。
2．重新排序法：分別採用靜態或動態的指令詞度方式。
3．顯式/隱式並行性結合：顯式指的是並行語言通過編譯形成並行程序，隱式指的是串列語言通過編譯形成並行程序，顯式/隱式並行性結合的關鍵就在於並行編譯，而並行編譯涉及到語句、程序段、進程以及各級程序的並行性。 利用計算機語言進行並行性描述的時候主要有三種方案：
1．語言擴展方案：也就是利用各種語言的庫函數來進行並行性功能的擴展。
2．編譯制導法：也稱為智能編譯，它是隱式並行策略的體現，主要是由並行編譯系統進行程序表示、控制流的分析、相關分析、優化分析和並行化劃分，由相關分析得到方法庫管理方案，由優化分析得到知識庫管理方案，由並行化劃分得到程序重構，從而形成並行程序。
3．新的語言結構法：這是顯式並行策略的體現。也就是建立一種全新的並行語言的體系，而這種並行語言通過編譯就能直接形成並行程序。

④ MD5是如何編譯的

MD5簡介

MD5的全稱是Message-Digest Algorithm 5，在90年代初由MIT的計算機科學實驗室和RSA Data Security Inc發明，經MD2、MD3和MD4發展而來。

Message-Digest泛指位元組串(Message)的Hash變換，就是把一個任意長度的位元組串變換成一定長的大整數。請注意我使用了「位元組串」而不是「字元串」這個詞，是因為這種變換只與位元組的值有關，與字元集或編碼方式無關。

MD5將任意長度的「位元組串」變換成一個128bit的大整數，並且它是一個不可逆的字元串變換演算法，換句話說就是，即使你看到源程序和演算法描述，也無法將一個MD5的值變換回原始的字元串，從數學原理上說，是因為原始的字元串有無窮多個，這有點象不存在反函數的數學函數。

MD5的典型應用是對一段Message(位元組串)產生fingerprint(指紋)，以防止被「篡改」。舉個例子，你將一段話寫在一個叫readme.txt文件中，並對這個readme.txt產生一個MD5的值並記錄在案，然後你可以傳播這個文件給別人，別人如果修改了文件中的任何內容，你對這個文件重新計算MD5時就會發現。如果再有一個第三方的認證機構，用MD5還可以防止文件作者的「抵賴」，這就是所謂的數字簽名應用。

MD5還廣泛用於加密和解密技術上，在很多操作系統中，用戶的密碼是以MD5值（或類似的其它演算法）的方式保存的，用戶Login的時候，系統是把用戶輸入的密碼計算成MD5值，然後再去和系統中保存的MD5值進行比較，而系統並不「知道」用戶的密碼是什麼。

一些黑客破獲這種密碼的方法是一種被稱為「跑字典」的方法。有兩種方法得到字典，一種是日常搜集的用做密碼的字元串表，另一種是用排列組合方法生成的，先用MD5程序計算出這些字典項的MD5值，然後再用目標的MD5值在這個字典中檢索。

即使假設密碼的最大長度為8，同時密碼只能是字母和數字，共26+26+10=62個字元，排列組合出的字典的項數則是P(62,1)+P(62,2)….+P(62,8)，那也已經是一個很天文的數字了，存儲這個字典就需要TB級的磁碟組，而且這種方法還有一個前提，就是能獲得目標賬戶的密碼MD5值的情況下才可以。

在很多電子商務和社區應用中，管理用戶的Account是一種最常用的基本功能，盡管很多Application Server提供了這些基本組件，但很多應用開發者為了管理的更大的靈活性還是喜歡採用關系資料庫來管理用戶，懶惰的做法是用戶的密碼往往使用明文或簡單的變換後直接保存在資料庫中，因此這些用戶的密碼對軟體開發者或系統管理員來說可以說毫無保密可言，本文的目的是介紹MD5的Java Bean的實現，同時給出用MD5來處理用戶的Account密碼的例子，這種方法使得管理員和程序設計者都無法看到用戶的密碼，盡管他們可以初始化它們。但重要的一點是對於用戶密碼設置習慣的保護。

有興趣的讀者可以從這里取得MD5也就是RFC 1321的文本。 http://www.ietf.org/rfc/rfc1321.txt

實現策略

MD5的演算法在RFC1321中實際上已經提供了C的實現，我們其實馬上就能想到，至少有兩種用Java實現它的方法，第一種是，用Java語言重新寫整個演算法，或者再說簡單點就是把C程序改寫成Java程序。第二種是，用JNI(Java Native Interface)來實現，核心演算法仍然用這個C程序，用Java類給它包個殼。

但我個人認為，JNI應該是Java為了解決某類問題時的沒有辦法的辦法（比如與操作系統或I/O設備密切相關的應用），同時為了提供和其它語言的互操作性的一個手段。使用JNI帶來的最大問題是引入了平台的依賴性，打破了SUN所鼓吹的「一次編寫到處運行」的Java好處。因此，我決定採取第一種方法，一來和大家一起嘗試一下「一次編寫到處運行」的好處，二來檢驗一下Java 2現在對於比較密集的計算的效率問題。

實現過程

限於這篇文章的篇幅，同時也為了更多的讀者能夠真正專注於問題本身，我不想就某一種Java集成開發環境來介紹這個Java Bean的製作過程，介紹一個方法時我發現步驟和命令很清晰，我相信有任何一種Java集成環境三天以上經驗的讀者都會知道如何把這些代碼在集成環境中編譯和運行。用集成環境講述問題往往需要配很多屏幕截圖，這也是我一直對集成環境很頭疼的原因。我使用了一個普通的文本編輯器，同時使用了Sun公司標準的JDK 1.3.0 for Windows NT。

其實把C轉換成Java對於一個有一定C語言基礎的程序員並不困難，這兩個語言的基本語法幾乎完全一致．我大概花了一個小時的時間完成了代碼的轉換工作，我主要作了下面幾件事：

把必須使用的一些#define的宏定義變成Class中的final static，這樣保證在一個進程空間中的多個Instance共享這些數據
刪去了一些無用的#if define，因為我只關心MD5，這個推薦的C實現同時實現了MD2 MD3和 MD4，而且有些#if define還和C不同編譯器有關
將一些計算宏轉換成final static 成員函數。
所有的變數命名與原來C實現中保持一致，在大小寫上作一些符合Java習慣的變化，計算過程中的C函數變成了private方法(成員函數)。
關鍵變數的位長調整
定義了類和方法
需要注意的是，很多早期的C編譯器的int類型是16 bit的，MD5使用了unsigned long int，並認為它是32bit的無符號整數。而在Java中int是32 bit的，long是64 bit的。在MD5的C實現中，使用了大量的位操作。這里需要指出的一點是，盡管Java提供了位操作，由於Java沒有unsigned類型，對於右移位操作多提供了一個無符號右移：>>>，等價於C中的 >> 對於unsigned 數的處理。

因為Java不提供無符號數的運算，兩個大int數相加就會溢出得到一個負數或異常，因此我將一些關鍵變數在Java中改成了long類型(64bit)。我個人認為這比自己去重新定義一組無符號數的類同時重載那些運算符要方便，同時效率高很多並且代碼也易讀，OO(Object Oriented)的濫用反而會導致效率低下。

限於篇幅，這里不再給出原始的C代碼，有興趣對照的讀者朋友可以去看RFC 1321。MD5.java源代碼

測試

在RFC 1321中，給出了Test suite用來檢驗你的實現是否正確：

MD5 ("") =

MD5 ("a") =

MD5 ("abc") =

MD5 ("message digest") =

MD5 ("abcdefghijklmnopqrstuvwxyz") =

……

這些輸出結果的含義是指：空字元串」」的MD5值是，字元串」a」的MD5值是……
編譯並運行我們的程序：
javac –d . MD5.java
java beartool.MD5
為了將來不與別人的同名程序沖突，我在我的程序的第一行使用了package beartool;

因此編譯命令javac –d . MD5.java 命令在我們的工作目錄下自動建立了一個beartool目錄，目錄下放著編譯成功的 MD5.class

我們將得到和Test suite同樣的結果。當然還可以繼續測試你感興趣的其它MD5變換，例如：

java beartool.MD5 1234

將給出1234的MD5值。

可能是我的計算機知識是從Apple II和Z80單板機開始的，我對大寫十六進制代碼有偏好，如果您想使用小寫的Digest String只需要把byteHEX函數中的A、B、C、D、E、F改成a、b、 c、d、e、f就可以了。

MD5據稱是一種比較耗時的計算，我們的Java版MD5一閃就算出來了，沒遇到什麼障礙，而且用肉眼感覺不出來Java版的MD5比C版的慢。

為了測試它的兼容性，我把這個MD5.class文件拷貝到我的另一台Linux+IBM JDK 1.3的機器上，執行後得到同樣結果，確實是「一次編寫到處運行了」。

Java Bean簡述

現在，我們已經完成並簡單測試了這個Java Class，我們文章的標題是做一個Java Bean。

其實普通的Java Bean很簡單，並不是什麼全新的或偉大的概念，就是一個Java的Class，盡管 Sun規定了一些需要實現的方法，但並不是強制的。而EJB(Enterprise Java Bean)無非規定了一些必須實現（非常類似於響應事件）的方法，這些方法是供EJB Container使用(調用)的。

在一個Java Application或Applet里使用這個bean非常簡單，最簡單的方法是你要使用這個類的源碼工作目錄下建一個beartool目錄，把這個class文件拷貝進去，然後在你的程序中import beartool.MD5就可以了。最後打包成.jar或.war是保持這個相對的目錄關系就行了。

Java還有一個小小的好處是你並不需要摘除我們的MD5類中那個main方法，它已經是一個可以工作的Java Bean了。Java有一個非常大的優點是她允許很方便地讓多種運行形式在同一組代碼中共存，比如，你可以寫一個類，它即是一個控制台Application和GUI Application，同時又是一個Applet，同時還是一個Java Bean，這對於測試、維護和發布程序提供了極大的方便，這里的測試方法main還可以放到一個內部類中，有興趣的讀者可以參考： http://www.cn.ibm.com/developerWorks/java/jw-tips/tip106/index.shtml

這里講述了把測試和示例代碼放在一個內部靜態類的好處，是一種不錯的工程化技巧和途徑。

把Java Bean裝到JSP里

正如我們在本文開頭講述的那樣，我們對這個MD5 Bean的應用是基於一個用戶管理，這里我們假設了一個虛擬社區的用戶login過程，用戶的信息保存在資料庫的個名為users的表中。這個表有兩個欄位和我們的這個例子有關，userid :char(20)和pwdmd5 :char(32)，userid是這個表的Primary Key，pwdmd5保存密碼的MD5串，MD5值是一個128bit的大整數，表示成16進制的ASCII需要32個字元。

這里給出兩個文件，login.html是用來接受用戶輸入的form，login.jsp用來模擬使用MD5 Bean的login過程。

為了使我們的測試環境簡單起見，我們在JSP中使用了JDK內置的JDBC-ODBC Bridge Driver，community是ODBC的DSN的名字，如果你使用其它的JDBC Driver，替換掉login.jsp中的
Connection con= DriverManager.getConnection("jdbc:odbc:community", "", "");
即可。

login.jsp的工作原理很簡單，通過post接收用戶輸入的UserID和Password，然後將Password變換成MD5串，然後在users表中尋找UserID和pwdmd5，因為UserID是users表的Primary Key，如果變換後的pwdmd5與表中的記錄不符，那麼SQL查詢會得到一個空的結果集。

這里需要簡單介紹的是，使用這個Bean只需要在你的JSP應用程序的WEB-INF/classes下建立一個beartool目錄，然後將MD5.class拷貝到那個目錄下就可以了。如果你使用一些集成開發環境，請參考它們的deploy工具的說明。在JSP使用一個java Bean關鍵的一句聲明是程序中的第2行：

<jsp:useBean id='oMD5' scope='request' class='beartool.MD5'/>
這是所有JSP規范要求JSP容器開發者必須提供的標准Tag。

id=實際上是指示JSP Container創建Bean的實例時用的實例變數名。在後面的<%和%>之間的Java程序中，你可以引用它。在程序中可以看到，通過 pwdmd5=oMD5.getMD5ofStr (password)引用了我們的MD5 Java Bean提供的唯一一個公共方法: getMD5ofStr。

Java Application Server執行.JSP的過程是先把它預編譯成.java（那些Tag在預編譯時會成為java語句），然後再編譯成.class。這些都是系統自動完成和維護的，那個.class也稱為Servlet。當然，如果你願意，你也可以幫助Java Application Server去干本該它乾的事情，自己直接去寫Servlet，但用Servlet去輸出HTML那簡直是回到了用C寫CGI程序的惡夢時代。

如果你的輸出是一個復雜的表格，比較方便的方法我想還是用一個你所熟悉的HTML編輯器編寫一個「模板」，然後在把JSP代碼「嵌入」進去。盡管這種JSP代碼被有些專家指責為「空心粉」，它的確有個缺點是代碼比較難管理和重復使用，但是程序設計永遠需要的就是這樣的權衡。我個人認為，對於中、小型項目，比較理想的結構是把數據表示（或不嚴格地稱作WEB界面相關）的部分用JSP寫，和界面不相關的放在Bean裡面，一般情況下是不需要直接寫Servlet的。

如果你覺得這種方法不是非常的OO(Object Oriented)，你可以繼承（extends）它一把，再寫一個bean把用戶管理的功能包進去。

到底能不能兼容？

我測試了三種Java應用伺服器環境，Resin 1.2.3、Sun J2EE 1.2、IBM WebSphere 3.5，所幸的是這個Java Bean都沒有任何問題，原因其實是因為它僅僅是個計算程序，不涉及操作系統，I/O設備。其實用其它語言也能簡單地實現它的兼容性的，Java的唯一優點是，你只需提供一個形態的運行碼就可以了。請注意「形態」二字，現在很多計算結構和操作系統除了語言本身之外都定義了大量的代碼形態，很簡單的一段C語言核心代碼，轉換成不同形態要考慮很多問題，使用很多工具，同時受很多限制，有時候學習一種新的「形態」所花費的精力可能比解決問題本身還多。比如光Windows就有EXE、Service、的普通DLL、COM DLL以前還有OCX等等等等，在Unix上雖說要簡單一些，但要也要提供一個.h定義一大堆宏，還要考慮不同平台編譯器版本的位長度問題。我想這是Java對我來說的一個非常重要的魅力吧。

MD5演算法說明

一、補位
二、補數據長度
三、初始化MD5參數
四、處理位操作函數
五、主要變換過程
六、輸出結果

補位：
MD5演算法先對輸入的數據進行補位，使得數據位長度LEN對512求余的結果是448。即數據擴展至K*512+448位。即K*64+56個位元組，K為整數。
具體補位操作：補一個1，然後補0至滿足上述要求。
補數據長度：
用一個64位的數字表示數據的原始長度B，把B用兩個32位數表示。這時，數
據就被填補成長度為512位的倍數。
初始化MD5參數：
四個32位整數 (A,B,C,D) 用來計算信息摘要，初始化使用的是十六進製表
示的數字
A=0X01234567
B=0X89abcdef
C=0Xfedcba98
D=0X76543210

處理位操作函數：
X，Y，Z為32位整數。
F(X,Y,Z) = X&Y|NOT(X)&Z
G(X,Y,Z) = X&Z|Y?(Z)
H(X,Y,Z) = X xor Y xor Z
I(X,Y,Z) = Y xor (X|not(Z))

主要變換過程：
使用常數組T[1 ... 64]， T[i]為32位整數用16進製表示，數據用16個32位
的整數數組M[]表示。
具體過程如下：

/* 處理數據原文 */
For i = 0 to N/16-1 do

/*每一次，把數據原文存放在16個元素的數組X中. */
For j = 0 to 15 do
Set X[j] to M[i*16+j].
end /結束對J的循環

/* Save A as AA, B as BB, C as CC, and D as DD.
*/
AA = A
BB = B
CC = C
DD = D

/* 第1輪*/
/* 以 [abcd k s i]表示如下操作
a = b + ((a + F(b,c,d) + X[k] + T[i]) <<< s). */

/* Do the following 16 operations. */
[ABCD 0 7 1] [DABC 1 12 2] [CDAB 2 17 3] [BCDA 3
22 4]
[ABCD 4 7 5] [DABC 5 12 6] [CDAB 6 17 7] [BCDA 7
22 8]
[ABCD 8 7 9] [DABC 9 12 10] [CDAB 10 17 11] [BCDA
11 22 12]
[ABCD 12 7 13] [DABC 13 12 14] [CDAB 14 17 15]
[BCDA 15 22 16]

/* 第2輪* */
/* 以 [abcd k s i]表示如下操作
a = b + ((a + G(b,c,d) + X[k] + T[i]) <<< s). */
/* Do the following 16 operations. */
[ABCD 1 5 17] [DABC 6 9 18] [CDAB 11 14 19] [BCDA
0 20 20]
[ABCD 5 5 21] [DABC 10 9 22] [CDAB 15 14 23]
[BCDA 4 20 24]
[ABCD 9 5 25] [DABC 14 9 26] [CDAB 3 14 27] [BCDA
8 20 28]
[ABCD 13 5 29] [DABC 2 9 30] [CDAB 7 14 31] [BCDA
12 20 32]

/* 第3輪*/
/* 以 [abcd k s i]表示如下操作
a = b + ((a + H(b,c,d) + X[k] + T[i]) <<< s). */
/* Do the following 16 operations. */
[ABCD 5 4 33] [DABC 8 11 34] [CDAB 11 16 35]
[BCDA 14 23 36]
[ABCD 1 4 37] [DABC 4 11 38] [CDAB 7 16 39] [BCDA
10 23 40]
[ABCD 13 4 41] [DABC 0 11 42] [CDAB 3 16 43]
[BCDA 6 23 44]
[ABCD 9 4 45] [DABC 12 11 46] [CDAB 15 16 47]
[BCDA 2 23 48]

/* 第4輪*/
/* 以 [abcd k s i]表示如下操作
a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */
/* Do the following 16 operations. */
[ABCD 0 6 49] [DABC 7 10 50] [CDAB 14 15 51]
[BCDA 5 21 52]
[ABCD 12 6 53] [DABC 3 10 54] [CDAB 10 15 55]
[BCDA 1 21 56]
[ABCD 8 6 57] [DABC 15 10 58] [CDAB 6 15 59]
[BCDA 13 21 60]
[ABCD 4 6 61] [DABC 11 10 62] [CDAB 2 15 63]
[BCDA 9 21 64]

/* 然後進行如下操作 */
A = A + AA
B = B + BB
C = C + CC
D = D + DD

end /* 結束對I的循環*/

輸出結果。

⑤ statement和preparedsteament的區別

Java中PreparedStatement和Statement的用法區別
1、 PreparedStatement介面繼承Statement， PreparedStatement 實例包含已編譯的 SQL 語句，所以其執行速度要快於 Statement 對象。

2、作為 Statement 的子類，PreparedStatement 繼承了 Statement 的所有功能。三種方法execute、 executeQuery 和 executeUpdate 已被更改以使之不再需要參數。

3、在JDBC應用中，如果已經是稍有水平開發者，就應該始終以PreparedStatement代替Statement。也就是說，在任何時候都不要使用Statement。基於以下的原因:
一、代碼的可讀性和可維護性。
雖然用PreparedStatement來代替Statement會使代碼多出幾行，但這樣的代碼無論從可讀性還是可維護性上來說，都比直接用Statement的代碼高很多檔次：
stmt.executeUpdate("insert into tb_name (col1,col2,col2,col4) values ('"+var1+"','"+var2+"',"+var3+",'"+var4+"')");//stmt是Statement對象實例

perstmt = con.prepareStatement("insert into tb_name (col1,col2,col2,col4) values (?,?,?,?)");
perstmt.setString(1,var1);
perstmt.setString(2,var2);
perstmt.setString(3,var3);
perstmt.setString(4,var4);
perstmt.executeUpdate(); //prestmt是 PreparedStatement 對象實例

二、PreparedStatement盡最大可能提高性能。
語句在被DB的編譯器編譯後的執行代碼被緩存下來，那麼下次調用時只要是相同的預編譯語句就不需要編譯，只要將參數直接傳入編譯過的語句執行代碼中(相當於一個涵數)就會得到執行。這並不是說只有一個Connection中多次執行的預編譯語句被緩存，而是對於整個DB中，只要預編譯的語句語法和緩存中匹配。那麼在任何時候就可以不需要再次編譯而可以直接執行。而statement的語句中，即使是相同一操作，而由於每次操作的數據不同所以使整個語句相匹配的機會極小，幾乎不太可能匹配。比如:
insert into tb_name (col1,col2) values ('11','22');
insert into tb_name (col1,col2) values ('11','23');

即使是相同操作但因為數據內容不一樣，所以整個個語句本身不能匹配，沒有緩存語句的意義。事實是沒有資料庫會對普通語句編譯後的執行代碼緩存。

當然並不是所以預編譯語句都一定會被緩存，資料庫本身會用一種策略，比如使用頻度等因素來決定什麼時候不再緩存已有的預編譯結果。以保存有更多的空間存儲新的預編譯語句。

三、最重要的一點是極大地提高了安全性。

即使到目前為止，仍有一些人連基本的惡義SQL語法都不知道。
String sql = "select * from tb_name where name= '"+varname+"' and passwd='"+varpasswd+"'";
如果我們把[' or '1' = '1]作為varpasswd傳入進來，用戶名隨意，看看會成為什麼?

select * from tb_name = '隨意' and passwd = '' or '1' = '1';
因為'1'='1'肯定成立,所以可以任何通過驗證.更有甚者:
把[';drop table tb_name;]作為varpasswd傳入進來,則:
select * from tb_name = '隨意' and passwd = '';drop table tb_name;有些資料庫是不會讓你成功的，但也有很多資料庫就可以使這些語句得到執行。

而如果你使用預編譯語句，傳入的任何內容就不會和原來的語句發生任何匹配的關系，只要全使用預編譯語句，就用不著對傳入的數據做任何過慮。而如果使用普通的statement，有可能要對drop等做費盡心機的判斷和過慮。

⑥ 為什麼要學習編譯原理(轉）

大學課程為什麼要開設編譯原理呢？這門課程關注的是編譯器方面的產生原理和技術問題，似乎和計算機的基礎領域不沾邊，可是編譯原理卻一直作為大學本科的必修課程，同時也成為了研究生入學考試的必考內容。編譯原理及技術從本質上來講就是一個演算法問題而已，當然由於這個問題十分復雜，其解決演算法也相對復雜。我們學的數據結構與演算法分析也是講演算法的，不過講的基礎演算法，換句話說講的是演算法導論，而編譯原理這門課程講的就是比較專註解決一種的演算法了。在20世紀50年代，編譯器的編寫一直被認為是十分困難的事情，第一Fortran的編譯器據說花了18年的時間才完成。在人們嘗試編寫編譯器的同時，誕生了許多跟編譯相關的理論和技術，而這些理論和技術比一個實際的編譯器本身價值更大。就猶如數學家們在解決著名的哥德巴赫猜想一樣，雖然沒有最終解決問題，但是其間誕生不少名著的相關數論。 推薦參考書 雖然編譯理論發展到今天，已經有了比較成熟的部分，但是作為一個大學生來說，要自己寫出一個像TurbocC,Java那樣的編譯器來說還是太難了。不僅寫編譯器困難，學習編譯原理這門課程也比較困難。 第一本書的原名叫《CompilersPrinciples,Techniques,andTools》,另外一個響亮的名字就是龍書。原因是這本書的封面上有條紅色的龍，也因為獗臼樵詒嘁朐?砘?嘴域確實?忻?所以很多國外的學者都直接取名為龍書。最近機械工業出版社已經出版了此書的中文版，名字就叫《編譯原理》。該書出的比較早，大概是在85或86年編寫完成的，作者之一還是著名的貝爾實驗室的科學家。裡面講解的核心編譯原理至今都沒有變過，所以一直到今天，它的價值都非凡。這本書最大的特點就是一開始就通過一個實際的小例子，把編譯原理的大致內容羅列出來，讓很多編譯原理的初學者很快心裡有了個底,也知道為什麼會有這些理論，怎麼運用這些理論。而這一點是我感覺國內的教材缺乏的東西，所以國內的教材都不是寫給願意自學的讀者，總之讓人看了半天，卻不知道裡面的東西有什麼用。 第二本書的原名叫《ModernCompilerDesign》,中文名字叫做《現代編譯程序設計》。該書由人民郵電出版社所出。此書比較關注的是編譯原理的實踐，書中給出了不少的實際程序代碼，還有很多實際的編譯技術問題等等。此書另外一個特點就是其現代而字。在傳統的編譯原理教材中，你是不可能看到如同Java中的垃圾回收等演算法的。因為Java這樣的解釋執行語言是在近幾年才流行起來的東西。如果你想深入學習編譯原理的理論知識，那麼你肯定得看前面那本龍書，如果你想自己動手做一個先進的編譯器，那麼你得看這本《現代編譯程序設計》。 第三本書就是很多國內的編譯原理學者都推薦的那本《編譯原理及實踐》。或許是這本書引入國內比較早吧，我記得我是在高中就買了這本書，不過也是在前段時間才把整本書看完。此書作為入門教程也的確是個不錯的選擇。書中給出的編譯原理講解也相當細致，雖然不如前面的龍書那麼深入，但是很多地方都是點到為止，作為大學本科教學已經是十分深入了。該書的特點就是注重實踐，不過感覺還不如前面那本《現代編譯程序設計》的實踐味道更重。此書的重點還是在原理上的實踐，而非前面那本那樣的技術實踐。《編譯原理及實踐》在講解編譯原理的各個部分的同時，也在逐步實踐一個現代的編譯器TinyC.等你把整本書看完，差不多自己也可以寫一個TinyC了。作者還對Lex和Yacc這兩個常用的編譯相關的工具進行了很詳細的說明，這一點也是很難在國內的教材中看到的。 推薦了這三本教材，都有英文版和中文版的。很多英文好的同學只喜歡看原版的書，不我的感覺是這三本書的翻譯都很不錯，沒有必要特別去買英文版的。理解理論的實質比理解表面的文字更為重要。 編譯原理的實質 幾乎每本編譯原理的教材都是分成詞法分析，語法分析（LL演算法，遞歸下降演算法，LR演算法），語義分析，運行時環境，中間代碼，代碼生成，代碼優化這些部分。其實現在很多編譯原理的教材都是按照85,86出版的那本龍書來安排教學內容的，所以那本龍書的內容格式幾乎成了現在編譯原理教材的定式，包括國內的教材也是如此。一般來說，大學裡面的本科教學是不可能把上面的所有部分都認真講完的，而是比較偏重於前面幾個部分。像代碼優化那部分東西，就像個無底洞一樣，如果要認真講，就是單獨開一個學期的課也不可能講得清楚。所以，一般對於本科生，對詞法分析和語法分析掌握要求就相對要高一點了。 詞法分析相對來說比較簡單。可能是詞法分析程序本身實現起來很簡單吧，很多沒有學過編譯原理的人也同樣可以寫出各種各樣的詞法分析程序。不過編譯原理在講解詞法分析的時候，重點把正則表達式和自動機原理加了進來，然後以一種十分標準的方式來講解詞法分析程序的產生。這樣的做法道理很明顯，就是要讓詞法分析從程序上升到理論的地步。 語法分析部分就比較麻煩一點了。現在一般有兩種語法分析演算法，LL自頂向下演算法和LR自底向上演算法。LL演算法還好說，到了LR演算法的時候，困難就來了。很多自學編譯原理的都是遇到LR演算法的理解成問題後就放棄了自學。其實這些東西都是只要大家理解就可以了，又不是像詞法分析那樣非得自己寫出來才算真正的會。像LR演算法的語法分析器，一般都是用工具Yacc來生成，實踐中完全沒有比較自己來實現。對於LL演算法中特殊的遞歸下降演算法，因為其實踐十分簡單，那麼就應該要求每個學生都能自己寫。當然，現在也有不少好的LL演算法的語法分析器，不過要是換在非C平台，比如Java,Delphi,你不能運用YACC工具了，那麼你就只有自己來寫語法分析器。 等學到詞法分析和語法分析時候，你可能會出現這樣的疑問：詞法分析和語法分析到底有什麼？就從編譯器的角度來講，編譯器需要把程序員寫的源程序轉換成一種方便處理的數據結構（抽象語法樹或語法樹）,那麼這個轉換的過程就是通過詞法分析和語法分析的。其實詞法分析並非一開始就被列入編譯器的必備部分，只是我們為了簡化語法分析的過程，就把詞法分析這種繁瑣的工作單獨提取出來，就成了現在的詞法分析部分。除了編譯器部分，在其它地方，詞法分析和語法分析也是有用的。比如我們在DOS,Unix,Linux下輸入命令的時候，程序如何分析你輸入的命令形式，這也是簡單的應用。總之，這兩部分的工作就是把不規則的文本信息轉換成一種比較好分析好處理的數據結構。那麼為什麼編譯原理的教程都最終把要分析的源分析轉換成樹這種數據結構呢？數據結構中有Stack,Line,List這么多數據結構，各自都有各自的特點。但是Tree這種結構有很強的遞歸性，也就是說我們可以把Tree的任何結點Node提取出來後，它依舊是一顆完整的Tree。這一點符合我們現在編譯原理分析的形式語言，比如我們在函數裡面使用函樹，循環中使用循環，條件中使用條件等等，那麼就可以很直觀地表示在Tree這種數據結構上。同樣，我們在執行形式語言的程序的時候也是如此的遞歸性。在編譯原理後面的代碼生成的部分，就會介紹一種堆棧式的中間代碼，我們可以根據分析出來的抽象語法樹，很容易，很機械地運用遞歸遍歷抽象語法樹就可以生成這種指令代碼。而這種代碼其實也被廣泛運用在其它的解釋型語言中。像現在流行的Java,.NET，其底層的位元組碼bytecode,可以說就是這中基於堆棧的指令代碼的。 關於語義分析，語法制導翻譯，類型檢查等等部分，其實都是一種完善前面得到的抽象語法樹的過程。比如說，我們寫C語言程序的時候，都知道，如果把一個浮點數直接賦值給一個整數，就會出現類型不匹配，那麼C語言的編譯器是怎麼知道的呢？就是通過這一步的類型檢查。像C++語言這中支持多態函數的語言，這部分要處理的問題就更多更復雜了。大部編譯原理的教材在這部分都是講解一些比較好的處理策略而已。因為新的問題總是在發生，舊的辦法不見得足夠解決。 本來說，作為一個編譯器，起作用的部分就是用戶輸入的源程序到最終的代碼生成。但是在講解最終代碼生成的時候，又不得不講解機器運行環境等內容。因為如果你不知道機器是怎麼執行最終代碼的，那麼你當然無法知道如何生成合適的最終代碼。這部分內容我自我感覺其意義甚至超過了編譯原理本身。因為它會把一個計算機的程序的運行過程都通通排在你面前，你將來可能不會從事編譯器的開發工作，但是只要是和計算機軟體開發相關的領域,都會涉及到程序的執行過程。運行時環境的講解會讓你更清楚一個計算機程序是怎麼存儲，怎麼裝載，怎麼執行的。關於部分的內容，我強烈建議大家看看龍書上的講解，作者從最基本的存儲組織，存儲分配策略，非局部名字的訪問，參數傳遞，符號表到動態存儲分配(malloc,new)都作了十分詳細的說明。這些東西都是我們編寫平常程序的時候經常要做的事情，但是我們卻少去探求其內部是如何完成。 關於中間代碼生成，代碼生成,代碼優化部分的內容就實在不好說了。國內很多教材到了這部分都會很簡單地走馬觀花講過去，學生聽了也只是作為了解，不知道如何運用。不過這部分內容的東西如果要認真講，單獨開一學期的課程都講不完。在《編譯原理及實踐》的書上，對於這部分的講解就恰到好處。作者主要講解的還是一種以堆棧為基礎的指令代碼，十分通俗易懂，讓人看了後，很容易模仿，自己下來後就可以寫自己的代碼生成。當然，對於其它代碼生成技術，代碼優化技術的講解就十分簡單了。如果要仔細研究代碼生成技術，其實另外還有本叫做《》,那本書現在由機械工業出版社引進的，十分厚重，而且是英文原版。不過這本書我沒有把它列為推薦書給大家，畢竟能把龍書的內容搞清楚，在中國已經就算很不錯的高手了，到那個時候再看這本《》也不遲。代碼優化部分在大學本科教學中還是一個不太重要的部分，就是算是實踐過程中，相信大家也不太運用得到。畢竟，自己做的編譯器能正確生成執行代碼已經很不錯了，還談什麼優化呢？ 編譯原理的課程畢竟還只是講解原理的課程，不是專門的編譯技術課程。這兩門課程是有很大的區別的。編譯技術更關注實際的編寫編譯器過程中運用到的技術，而原理的課

⑦ C語言位元組對齊怎麼操作

成為一名合格的IT人才

⑧ 從事IT行業，或者簡單的說是編程，常用的術語有哪些呢

字元串、變數、入棧出棧、堆、庫函數、遞歸、循環、聲明語句、預編譯、編譯器、解釋執行、測試、運行、頭文件、進程、多線程、客戶-伺服器、源代碼、演算法、數據結構、協議、套接字、提交表單、頁面、文檔說明、進程間通信、系統調用、標准庫、控制項、文件系統、環境變數、終端、空指針、分配內存空間、文件鎖、信號量、消息隊列、調度策略、前端、後台、資料庫、好多好多哦。。。。。