代碼編譯的結果是從本地機器碼轉爲字節碼的,是存儲格式發展的一小步,卻是編程語言發展的一大步.
7.1 概述
虛擬機把描述類的數據從Class文件加載到內存，並對數據進行校驗、轉換解析和初始化，最終形成可以被虛擬機直接使用的Java類型，這就是虛擬機的類加載機制
與那些在編譯時需要進行連接工作的語言不同，在Java語言裏面，類型的加載、連接和初始化過程都是在程序運行期間完成的，這種策略雖然會令類加載時稍微增加一些性能開銷，但是會爲Java應用程序提供高度的靈活性，Java裏天生可以動態擴展的語言特性就是依賴運行期動態加載和動態連接這個特點實現的。例如，如果編寫一個面向接口的應用程序，可以等到運行時再指定其實際的實現類；用戶可以通過Java預定義的和自定義類加載器，讓一個本地的應用程序可以在運行時從網絡或其他地方加載一個二進制流作爲程序代碼的一部分，這種組裝應用程序的方式目前已廣泛應用於Java程序之中。從最基礎的Applet、JSP到相對複雜的OSGi技術，都使用了Java語言運行期類加載的特性
7.2 類加載的時機
類從被加載到虛擬機內存中開始，到卸載出內存爲止，它的整個生命週期包括：加載（Loading）、驗證（Verification）、準備（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸載（Unloading）7個階段。其中驗證、準備、解析3個部分統稱爲連接（Linking），這7個階段的發生順序如圖7-1所示
圖7-1中，加載、驗證、準備、初始化和卸載這5個階段的順序是確定的，類的加載過程必須按照這種順序按部就班地開始，而解析階段則不一定：它在某些情況下可以在初始化階段之後再開始，這是爲了支持Java語言的運行時綁定（也稱爲動態綁定或晚期綁定）。注意，這裏筆者寫的是按部就班地“開始”，而不是按部就班地“進行”或“完成”，強調這點是因爲這些階段通常都是互相交叉地混合式進行的，通常會在一個階段執行的過程中調用、激活另外一個階段。
什麼情況下需要開始類加載過程的第一個階段：加載？Java虛擬機規範中並沒有進行強制約束，這點可以交給虛擬機的具體實現來自由把握。但是對於初始化階段，虛擬機規範則是嚴格規定了有且只有5種情況必須立即對類進行“初始化”（而加載、驗證、準備自然需要在此之前開始）：
- 遇到new、getstatic、putstatic或invokestatic這4條字節碼指令時，如果類沒有進行過初始化，則需要先觸發其初始化。生成這4條指令的最常見的Java代碼場景是：使用new關鍵字實例化對象的時候、讀取或設置一個類的靜態字段（被final修飾、已在編譯期把結果放入常量池的靜態字段除外）的時候，以及調用一個類的靜態方法的時候
- 使用java.lang.reflect包的方法對類進行反射調用的時候，如果類沒有進行過初始化，則需要先觸發其初始化
- 當初始化一個類的時候，如果發現其父類還沒有進行過初始化，則需要先觸發其父類的初始化
- 當使用JDK 1.7的動態語言支持時，如果一個java.lang.invoke.MethodHandle實例最後的解析結果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，並且這個方法句柄所對應的類沒有進行過初始化，則需要先觸發其初始化。
對應的類沒有進行過初始化，則需要先觸發其初始化。對於這5種會觸發類進行初始化的場景，虛擬機規範中使用了一個很強烈的限定語：“有且只有”，這5種場景中的行爲稱爲對一個類進行主動引用。除此之外，所有引用類的方式都不會觸發初始化，稱爲被動引用.
上述代碼運行之後，只會輸出“SuperClass init!”，而不會輸出“SubClass init!”。對於靜態字段，只有直接定義這個字段的類纔會被初始化，因此通過其子類來引用父類中定義的靜態字段，只會觸發父類的初始化而不會觸發子類的初始化。至於是否要觸發子類的加載和驗證，在虛擬機規範中並未明確規定，這點取決於虛擬機的具體實現。對於Sun HotSpot虛擬機來說，可通過-XX:+TraceClassLoading參數觀察到此操作會導致子類的加載。
爲了節省版面，這段代碼複用了代碼清單7-1中的SuperClass，運行之後發現沒有輸出“SuperClass init!”，說明並沒有觸發類org.fenixsoft.classloading.SuperClass的初始化階段。但是這段代碼裏面觸發了另外一個名爲“[Lorg.fenixsoft.classloading.SuperClass”的類的初始化階段，對於用戶代碼來說，這並不是一個合法的類名稱，它是一個由虛擬機自動生成的、直接繼承於java.lang.Object的子類，創建動作由字節碼指令newarray觸發
上述代碼運行之後，也沒有輸出“ConstClass init!”，這是因爲雖然在Java源碼中引用了ConstClass類中的常量HELLOWORLD，但其實在編譯階段通過常量傳播優化，已經將此常量的值“hello world”存儲到了NotInitialization類的常量池中，以後NotInitialization對常量ConstClass.HELLOWORLD的引用實際都被轉化爲NotInitialization類對自身常量池的引用了。也就是說，實際上NotInitialization的Class文件之中並沒有ConstClass類的符號引用入口，這兩個類在編譯成Class之後就不存在任何聯繫了。
接口的加載過程與類加載過程稍有一些不同，針對接口需要做一些特殊說明：接口也有初始化過程，這點與類是一致的，上面的代碼都是用靜態語句塊“static{}”來輸出初始化信息的，而接口中不能使用“static{}”語句塊，但編譯器仍然會爲接口生成“<clinit>()”類構造器[插圖]，用於初始化接口中所定義的成員變量。接口與類真正有所區別的是前面講述的5種“有且僅有”需要開始初始化場景中的第3種：當一個類在初始化時，要求其父類全部都已經初始化過了，但是一個接口在初始化時，並不要求其父接口全部都完成了初始化，只有在真正使用到父接口的時候（如引用接口中定義的常量）纔會初始化。
7.3 類加載的過程
接下來我們詳細講解一下Java虛擬機中類加載的全過程，也就是加載、驗證、準備、解析和初始化這5個階段所執行的具體動作。
7.3.1 加載
“加載”是“類加載”（Class Loading）過程的一個階段，希望讀者沒有混淆這兩個看起來很相似的名詞。在加載階段，虛擬機需要完成以下3件事情：1）通過一個類的全限定名來獲取定義此類的二進制字節流。2）將這個字節流所代表的靜態存儲結構轉化爲方法區的運行時數據結構。3）在內存中生成一個代表這個類的java.lang.Class對象，作爲方法區這個類的各種數據的訪問入口。
加載階段與連接階段的部分內容（如一部分字節碼文件格式驗證動作）是交叉進行的，加載階段尚未完成，連接階段可能已經開始，但這些夾在加載階段之中進行的動作，仍然屬於連接階段的內容，這兩個階段的開始時間仍然保持着固定的先後順序。
7.3.2 驗證
驗證是連接階段的第一步，這一階段的目的是爲了確保Class文件的字節流中包含的信息符合當前虛擬機的要求，並且不會危害虛擬機自身的安全。
Java語言本身是相對安全的語言（依然是相對於C/C++來說），使用純粹的Java代碼無法做到諸如訪問數組邊界以外的數據、將一個對象轉型爲它並未實現的類型、跳轉到不存在的代碼行之類的事情，如果這樣做了，編譯器將拒絕編譯。但前面已經說過，Class文件並不一定要求用Java源碼編譯而來，可以使用任何途徑產生，甚至包括用十六進制編輯器直接編寫來產生Class文件。在字節碼語言層面上，上述Java代碼無法做到的事情都是可以實現的，至少語義上是可以表達出來的。虛擬機如果不檢查輸入的字節流，對其完全信任的話，很可能會因爲載入了有害的字節流而導致系統崩潰，所以驗證是虛擬機對自身保護的一項重要工作。
受篇幅所限，本書無法逐條規則去講解，但從整體上看，驗證階段大致上會完成下面4個階段的檢驗動作：文件格式驗證、元數據驗證、字節碼驗證、符號引用驗證。
1.文件格式驗證
第一階段要驗證字節流是否符合Class文件格式的規範，並且能被當前版本的虛擬機處理。這一階段可能包括下面這些驗證點：
[插圖]是否以魔數0xCAFEBABE開頭。
[插圖]主、次版本號是否在當前虛擬機處理範圍之內。[
插圖]常量池的常量中是否有不被支持的常量類型（檢查常量tag標誌）。
[插圖]指向常量的各種索引值中是否有指向不存在的常量或不符合類型的常量。
[插圖]CONSTANT_Utf8_info型的常量中是否有不符合UTF8編碼的數據。
[插圖]Class文件中各個部分及文件本身是否有被刪除的或附加的其他信息。
......
實際上，第一階段的驗證點還遠不止這些，上面這些只是從HotSpot虛擬機源碼[插圖]中摘抄的一小部分內容，該驗證階段的主要目的是保證輸入的字節流能正確地解析並存儲於方法區之內，格式上符合描述一個Java類型信息的要求。這階段的驗證是基於二進制字節流進行的，只有通過了這個階段的驗證後，字節流纔會進入內存的方法區中進行存儲，所以後面的3個驗證階段全部是基於方法區的存儲結構進行的，不會再直接操作字節流。
2.元數據驗證
第二階段是對字節碼描述的信息進行語義分析，以保證其描述的信息符合Java語言規範的要求，這個階段可能包括的驗證點如下：
[插圖]這個類是否有父類（除了java.lang.Object之外，所有的類都應當有父類）。
[插圖]這個類的父類是否繼承了不允許被繼承的類（被final修飾的類）。
[插圖]如果這個類不是抽象類，是否實現了其父類或接口之中要求實現的所有方法。
[插圖]類中的字段、方法是否與父類產生矛盾（例如覆蓋了父類的final字段，或者出現不符合規則的方法重載，例如方法參數都一致，但返回值類型卻不同等）
第二階段的主要目的是對類的元數據信息進行語義校驗，保證不存在不符合Java語言規範的元數據信息
3.字節碼驗證
第三階段是整個驗證過程中最複雜的一個階段，主要目的是通過數據流和控制流分析，確定程序語義是合法的、符合邏輯的。在第二階段對元數據信息中的數據類型做完校驗後，這個階段將對類的方法體進行校驗分析，保證被校驗類的方法在運行時不會做出危害虛擬機安全的事件，例如：
[插圖]保證任意時刻操作數棧的數據類型與指令代碼序列都能配合工作，例如不會出現類似[插圖]這樣的情況：在操作棧放置了一個int類型的數據，使用時卻按long類型來加載入本地變量表中。
[插圖]保證跳轉指令不會跳轉到方法體以外的字節碼指令上。
[插圖]保證方法體中的類型轉換是有效的，例如可以把一個子類對象賦值給父類數據類型，這是安全的，但是把父類對象賦值給子類數據類型，甚至把對象賦值給與它毫無繼承關係、完全不相干的一個數據類型，則是危險和不合法的。……
由於數據流驗證的高複雜性，虛擬機設計團隊爲了避免過多的時間消耗在字節碼驗證階段，在JDK 1.6之後的Javac編譯器和Java虛擬機中進行了一項優化，給方法體的Code屬性的屬性表中增加了一項名爲“StackMapTable”的屬性，這項屬性描述了方法體中所有的基本塊（BasicBlock，按照控制流拆分的代碼塊）開始時本地變量表和操作棧應有的狀態，在字節碼驗證期間，就不需要根據程序推導這些狀態的合法性，只需要檢查StackMapTable屬性中的記錄是否合法即可。這樣將字節碼驗證的類型推導轉變爲類型檢查從而節省一些時間。
4.符號引用驗證
最後一個階段的校驗發生在虛擬機將符號引用轉化爲直接引用的時候，這個轉化動作將在連接的第三階段——解析階段中發生。符號引用驗證可以看做是對類自身以外（常量池中的各種符號引用）的信息進行匹配性校驗，通常需要校驗下列內容：
[插圖]符號引用中通過字符串描述的全限定名是否能找到對應的類。
[插圖]在指定類中是否存在符合方法的字段描述符以及簡單名稱所描述的方法和字段。
[插圖]符號引用中的類、字段、方法的訪問性（private、protected、public、default）是否可被當前類訪問。
……
符號引用驗證的目的是確保解析動作能正常執行，如果無法通過符號引用驗證，那麼將會拋出一個java.lang.IncompatibleClassChangeError異常的子類，如java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。
對於虛擬機的類加載機制來說，驗證階段是一個非常重要的、但不是一定必要（因爲對程序運行期沒有影響）的階段。如果所運行的全部代碼（包括自己編寫的及第三方包中的代碼）都已經被反覆使用和驗證過，那麼在實施階段就可以考慮使用-Xverify:none參數來關閉大部分的類驗證措施，以縮短虛擬機類加載的時間。
7.3.3 準備
準備階段是正式爲類變量分配內存並設置類變量初始值的階段，這些變量所使用的內存都將在方法區中進行分配
首先，這時候進行內存分配的僅包括類變量（被static修飾的變量），而不包括實例變量，實例變量將會在對象實例化時隨着對象一起分配在Java堆中。這裏所說的初始值“通常情況”下是數據類型的零值，也就是默認值,如int 類型的默認值是0
相對的會有一些“特殊情況”：如果類字段的字段屬性表中存在ConstantValue屬性，那在準備階段變量value就會被初始化爲ConstantValue屬性所指定的值，假設上面類變量value的定義變爲：
7.3.4 解析
解析階段是虛擬機將常量池內的符號引用替換爲直接引用的過程，
[插圖]符號引用（Symbolic References）：符號引用以一組符號來描述所引用的目標，符號可以是任何形式的字面量，只要使用時能無歧義地定位到目標即可。符號引用與虛擬機實現的內存佈局無關，引用的目標並不一定已經加載到內存中。各種虛擬機實現的內存佈局可以各不相同，但是它們能接受的符號引用必須都是一致的，因爲符號引用的字面量形式明確定義在Java虛擬機規範的Class文件格式中。
[插圖]直接引用（Direct References）：直接引用可以是直接指向目標的指針、相對偏移量或是一個能間接定位到目標的句柄。直接引用是和虛擬機實現的內存佈局相關的，同一個符號引用在不同虛擬機實例上翻譯出來的直接引用一般不會相同。如果有了直接引用，那引用的目標必定已經在內存中存在
解析動作主要針對類或接口、字段、類方法、接口方法、方法類型、方法句柄和調用點限定符7類符號引用進行.
假設當前代碼所處的類爲D，如果要把一個從未解析過的符號引用N解析爲一個類或接口C的直接引用，那虛擬機完成整個解析的過程需要以下3個步驟：
1）如果C不是一個數組類型，那虛擬機將會把代表N的全限定名傳遞給D的類加載器去加載這個類C。在加載過程中，由於元數據驗證、字節碼驗證的需要，又可能觸發其他相關類的加載動作，例如加載這個類的父類或實現的接口。一旦這個加載過程出現了任何異常，解析過程就宣告失敗。
2）如果C是一個數組類型，並且數組的元素類型爲對象，也就是N的描述符會是類似“[Ljava/lang/Integer”的形式，那將會按照第1點的規則加載數組元素類型。如果N的描述符如前面所假設的形式，需要加載的元素類型就是“java.lang.Integer”，接着由虛擬機生成一個代表此數組維度和元素的數組對象。
3）如果上面的步驟沒有出現任何異常，那麼C在虛擬機中實際上已經成爲一個有效的類或接口了，但在解析完成之前還要進行符號引用驗證，確認D是否具備對C的訪問權限。如果發現不具備訪問權限，將拋出java.lang.IllegalAccessError異常。
2.字段解析
3.類方法解析
4.接口方法解析
7.3.5 初始化
7.4 類加載器
7.4.1 類與類加載器
類加載器雖然只用於實現類的加載動作，但它在Java程序中起到的作用卻遠遠不限於類加載階段。對於任意一個類，都需要由加載它的類加載器和這個類本身一同確立其在Java虛擬機中的唯一性
類加載器雖然只用於實現類的加載動作，但它在Java程序中起到的作用卻遠遠不限於類加載階段。對於任意一個類，都需要由加載它的類加載器和這個類本身一同確立其在Java虛擬機中的唯一性，每一個類加載器，都擁有一個獨立的類名稱空間。這句話可以表達得更通俗一些：比較兩個類是否“相等”，只有在這兩個類是由同一個類加載器加載的前提下才有意義，否則，即使這兩個類來源於同一個Class文件，被同一個虛擬機加載，只要加載它們的類加載器不同，那這兩個類就必定不相等。
這裏所指的“相等”，包括代表類的Class對象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回結果，也包括使用instanceof關鍵字做對象所屬關係判定等情況。如果沒有注意到類加載器的影響，在某些情況下可能會產生具有迷惑性的結果，代碼清單7-8中演示了不同的類加載器對instanceof關鍵字運算的結果的影響。
7.4.2 雙親委派模型
從Java虛擬機的角度來講，只存在兩種不同的類加載器：一種是啓動類加載器（BootstrapClassLoader），這個類加載器使用C++語言實現[插圖]，是虛擬機自身的一部分；另一種就是所有其他的類加載器，這些類加載器都由Java語言實現，獨立於虛擬機外部，並且全都繼承自抽象類java.lang.ClassLoader。
從Java開發人員的角度來看，類加載器還可以劃分得更細緻一些，絕大部分Java程序都會使用到以下3種系統提供的類加載器。
- 啓動類加載器（Bootstrap ClassLoader）：前面已經介紹過，這個類將器負責將存放在<JAVA_HOME>\lib目錄中的，或者被-Xbootclasspath參數所指定的路徑中的，並且是虛擬機識別的（僅按照文件名識別，如rt.jar，名字不符合的類庫即使放在lib目錄中也不會被加載）類庫加載到虛擬機內存中。啓動類加載器無法被Java程序直接引用，用戶在編寫自定義類加載器時，如果需要把加載請求委派給引導類加載器，那直接使用null代替即可，
- [插圖]擴展類加載器（Extension ClassLoader）：這個加載器由sun.misc.Launcher$ExtClassLoader實現，它負責加載<JAVA_HOME>\lib\ext目錄中的，或者被java.ext.dirs系統變量所指定的路徑中的所有類庫，開發者可以直接使用擴展類加載器。
- [插圖]應用程序類加載器（Application ClassLoader）：這個類加載器由sun.misc.Launcher$App-ClassLoader實現。由於這個類加載器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也稱它爲系統類加載器。它負責加載用戶類路徑（ClassPath）上所指定的類庫，開發者可以直接使用這個類加載器，如果應用程序中沒有自定義過自己的類加載器，一般情況下這個就是程序中默認的類加載器。
我們的應用程序都是由這3種類加載器互相配合進行加載的，如果有必要，還可以加入自己定義的類加載器。這些類加載器之間的關係一般如圖7-2所示。
圖7-2中展示的類加載器之間的這種層次關係，稱爲類加載器的雙親委派模型
雙親委派模型要求除了頂層的啓動類加載器外，其餘的類加載器都應當有自己的父類加載器。這裏類加載器之間的父子關係一般不會以繼承（Inheritance）的關係來實現，而是都使用組合（Composition）關係來複用父加載器的代碼。
雙親委派模型的工作過程是：如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把這個請求委派給父類加載器去完成，每一個層次的類加載器都是如此，因此所有的加載請求最終都應該傳送到頂層的啓動類加載器中，只有當父加載器反饋自己無法完成這個加載請求（它的搜索範圍中沒有找到所需的類）時，子加載器纔會嘗試自己去加載。
使用雙親委派模型來組織類加載器之間的關係，有一個顯而易見的好處就是Java類隨着它的類加載器一起具備了一種帶有優先級的層次關係。例如類java.lang.Object，它存放在rt.jar之中，無論哪一個類加載器要加載這個類，最終都是委派給處於模型最頂端的啓動類加載器進行加載，因此Object類在程序的各種類加載器環境中都是同一個類。相反，如果沒有使用雙親委派模型，由各個類加載器自行去加載的話，如果用戶自己編寫了一個稱爲java. lang.Object的類，並放在程序的ClassPath中，那系統中將會出現多個不同的Object類，Java類型體系中最基礎的行爲也就無法保證，應用程序也將會變得一片混亂。如果讀者有興趣的話，可以嘗試去編寫一個與rt.jar類庫中已有類重名的Java類，將會發現可以正常編譯，但永遠無法被加載運行[插圖]
雙親委派模型對於保證Java程序的穩定運作很重要，但它的實現卻非常簡單，實現雙親委派的代碼都集中在java.lang.ClassLoader的loadClass()方法之中，如代碼清單7-10所示，邏輯清晰易懂：先檢查是否已經被加載過，若沒有加載則調用父加載器的loadClass()方法，若父加載器爲空則默認使用啓動類加載器作爲父加載器。如果父類加載失敗，拋出ClassNotFoundException異常後，再調用自己的findClass()方法進行加載。
7.4.3 破壞雙親委派模型
上文提到過雙親委派模型並不是一個強制性的約束模型，而是Java設計者推薦給開發者的類加載器實現方式。在Java的世界中大部分的類加載器都遵循這個模型，但也有例外，到目前爲止，雙親委派模型主要出現過3較大規模的“被破壞”情況
由於雙親委派模型在JDK 1.2之後才被引入，而類加載器和抽象類java.lang. ClassLoader則在JDK 1.0時代就已經存在，面對已經存在的用戶自定義類加載器的實現代碼，Java設計者引入雙親委派模型時不得不做出一些妥協。爲了向前兼容，JDK 1.2之後的java.lang.ClassLoader添加了一個新的protected方法findClass()，在此之前，用戶去繼承java. lang.ClassLoader的唯一目的就是爲了重寫loadClass()方法，因爲虛擬機在進行類加載的時候會調用加載器的私有方法loadClassInternal()，而這個方法的唯一邏輯就是去調用自己的loadClass()。
雙親委派模型的第二次“被破壞”是由這個模型自身的缺陷所導致的，雙親委派很好地解決了各個類加載器的基礎類的統一問題（越基礎的類由越上層的加載器進行加載），基礎類之所以稱爲“基礎”，是因爲它們總是作爲被用戶代碼調用的API，但世事往往沒有絕對的完美，如果基礎類又要調用回用戶的代碼，那該怎麼辦？
爲了解決這個問題，Java設計團隊只好引入了一個不太優雅的設計：線程上下文類加載器（Thread Context ClassLoader）。這個類加載器可以通過java.lang.Thread類的setContextClassLoaser()方法進行設置，如果創建線程時還未設置，它將會從父線程中繼承一個，如果在應用程序的全局範圍內都沒有設置過的話，那這個類加載器默認就是應用程序類加載器。
有了線程上下文類加載器，就可以做一些“舞弊”的事情了，JNDI服務使用這個線程上下文類加載器去加載所需要的SPI代碼，也就是父類加載器請求子類加載器去完成類加載的動作，這種行爲實際上就是打通了雙親委派模型的層次結構來逆向使用類加載器，實際上已經違背了雙親委派模型的一般性原則，但這也是無可奈何的事情。Java中所有涉及SPI的加載動作基本上都採用這種方式，例如JNDI、JDBC、JCE、JAXB和JBI等。
雙親委派模型的第三次“被破壞”是由於用戶對程序動態性的追求而導致的，這裏所說的“動態性”指的是當前一些非常“熱門”的名詞：代碼熱替換（HotSwap）、模塊熱部署（HotDeployment）等，說白了就是希望應用程序能像我們的計算機外設那樣，接上鼠標、U盤，不用重啓機器就能立即使用，鼠標有問題或要升級就換個鼠標，不用停機也不用重啓。對於個人計算機來說，重啓一次其實沒有什麼大不了的，但對於一些生產系統來說，關機重啓一次可能就要被列爲生產事故，這種情況下熱部署就對軟件開發者，尤其是企業級軟件開發者具有很大的吸引力。
Sun公司所提出的JSR-294[插圖]、JSR-277[插圖]規範在與JCP組織的模塊化規範之爭中落敗給JSR-291（即OSGi R4.2），雖然Sun不甘失去Java模塊化的主導權，獨立在發展Jigsaw項目，但目前OSGi已經成爲了業界“事實上”的Java模塊化標準[插圖]，而OSGi實現模塊化熱部署的關鍵則是它自定義的類加載器機制的實現。每一個程序模塊（OSGi中稱爲Bundle）都有一個自己的類加載器，當需要更換一個Bundle時，就把Bundle連同類加載器一起換掉以實現代碼的熱替換。