痞子軍團團長
2006-08-09 06:06:45 UTC
原文是從下面這個網址取得
http://big5.ccidnet.com:89/gate/big5/java.ccidnet.com/
art/297/20060809/790019_1.html
然後修改錯字、刪贅字、替換台灣慣用語與標點符號、重新排版而成。
大部分修改都有附上原文，以防失去替換有誤。
少數贅字 & 標點符號更換則沒有。
這篇文章好像已經沒啥版權問題？我不清楚
不過... 萬一我因此被抓去關，大家記得要來看我... [茶]
====================================================================
[註0]
我們知道，許多程式設計語言都允許在程式運行期動態地分配記憶體空間。
分配記憶體的方式多種多樣，取決於該種語言的語法結構。但不論是哪一種語言
的記憶體分配方式，最後都要交還 [改1] 所分配的記憶體塊的起始地址，即交
還 [改1] 一個指針到記憶體塊的首地址。
當已經分配的記憶體空間不再需要時，換句話說當指向該記憶體塊的句柄
[註1] 超出了使用範圍的時候，該程式或其運行環境就應該回收該記憶體空間，
以節省寶貴的記憶體資源。
在 C，C++ 或其他程式設計語言中，無論是對象 [註2] 還是動態配置的資
源或記憶體，都必須由程式員自行聲明產生和回收，否則其中的資源將消耗，造
成資源的浪費甚至當機。但手工回收記憶體往往是一項複雜而艱巨的工作。因為
要預先確定佔用的記憶體空間是否應該被回收是非常困難的！如果一段程式不能
回收記憶體空間，而且在程式運行時系統中又沒有了可以分配的記憶體空間時，
這段程式就只能崩潰。通常，我們把分配出去後，卻無法回收的記憶體空間稱為
「記憶體滲漏體（Memory Leaks）」。
以上這種程式設計的潛在危險性在 Java 這樣以嚴謹、安全著稱的語言中是
不允許的。但是 Java 語言既不能限制 [改3] 程序員編寫程式的自由性，又不
能把聲明對象的部分去除（否則就不是物件導向 [改4] 的程式語言了），那麼
最好的解決辦法就是從 Java 程式語言本身的特性入手。於是，Java 技術提供
了一個系統級的 thread [改5]，即垃圾收集器 [改6]（Garbage Collection
Thread），來跟蹤每一塊分配出去的記憶體空間，當 Java 虛擬機（Java
Virtual Machine）處於空閒迴圈時，垃圾收集器會自動檢查每一塊 [改7] 分配
出去的記憶體空間，然後自動回收每一塊 [改7] 可以回收的無用的記憶體塊。
垃圾收集器是一種低優先級的執行緒，在一個 Java 程式的生命週期中，它
只有在 CPU [改8] 空閒的時候才有機會運行。它有效地防止了 memory leaks
[改9] 的出現，並盡可能 [改10] 地節省了寶貴的記憶體資源。但是，通過 JVM
[改11] 來執行垃圾收集器的方案可以是多種多樣的。
下面介紹垃圾收集器的特點和它的執行機制：
垃圾收集器系統有自己的一套方案來判斷哪個記憶體塊是應該被回收的、哪
個是不符合要求暫不回收的。垃圾收集器在一個 Java 程式中是自動執行的
[改12]，不能強制執行。即使程式員能明確地判斷出有一塊記憶體已經無用了、
是應該回收的，程式員也不能強制垃圾收集器回收該記憶體塊。程式員唯一能做
的就是通過調用 [改13] 方法來「建議」執行垃圾收集器；但其是否可以執行，
什麼時候執行卻都是不可知的。這也是垃圾收集器的最主要的缺點。當然相對於
它給程式員帶來的巨大方便性而言，這個缺點是瑕不掩瑜的。
垃圾收集器的主要特點有：
1. 垃圾收集器的工作目標是回收已經無用的對象的記憶體空間，從而避免
memory leaks 產生、節省記憶體資源、避免程式代碼的崩潰。
2. 垃圾收集器判斷一個對象的記憶體空間是否無用的標準是：如果該對象
不再被 [改14] 程式中任何一個「活動的部分」所引用，此時我們就說
，該對象的記憶體空間已經無用。所謂「活動的部分」，是指程式中某
部分參與程式的調用，正在執行過程中，尚未執行完畢。
3. 垃圾收集器雖然是低優先等級的 thread [改15]，但在系統可用記憶體
量過低的時候，它可能會突發地執行來挽救記憶體資源。當然其執行與
否也是不可預知的。
4. 垃圾收集器不可以被強制執行，但程式員可以通過調用 System.gc() 方
法來建議執行垃圾收集器。
5. 不能保證一個無用的對象一定會被垃圾收集器收集，也不能保證垃圾收
集器在一段 Java 語言代碼中一定會執行。因此在程式執行過程中被分
配出去的記憶體空間可能會一直保留到該程式執行完畢，除非該空間被
重新分配或被其他方法回收。由此可見，完全徹底地根絕 memory leaks
的產生也是不可能的。但是請不要忘記，Java 的垃圾收集器畢竟使程式
員從手工回收記憶體空間的繁重工作中解脫了出來。設想一個程式員要
用 C 或 C++ 來編寫一段 10 萬行語句的程式碼 [改16]，那麼他一定會
充分體會到 Java 垃圾收集器的優點！
6. 同樣沒有辦法預知在一組均符合垃圾收集器收集標準的對象中，哪一個
會被首先收集。
7. 迴圈引用對象不會影響其被垃圾收集器收集。
8. 可以通過將對象的引用變數（reference variables，即句柄 handles）
設定為 null [改17]，來暗示垃圾收集器來收集該對象。但此時，如果
該對象連接有事件監聽器（典型的 AWT 組件），那它還是不可以被收集
。所以在設一個引用變數為 null 值之前，應注意該引用變數指向的對
像是否被監聽，若有，要首先除去監聽器，然後才可以賦空值。
9. 每一個對象都有一個 finalize() 方法，這個方法是從 Object 類繼承
來的。
10. finalize() 方法用來回收記憶體以外的系統資源，就像是文件處理器
和網路連接器。該方法的調用順序和用來調用該方法的對象的創建順序
是無關的。換句話說，書寫程式時該方法的順序和方法的實際調用順序
是不相干的。請注意這只是 finalize() 方法的特點。
11. 每個對象只能調用 finalize() 方法一次。如果在 finalize() 方法執
行時產生異常（exception），則該對象仍可以被垃圾收集器收集。
12. 垃圾收集器跟蹤每一個對象，收集那些不可到達的對象（即該對象沒有
被程式的任何「活的部分」所調用），回收其佔有的記憶體空間。但在
進行垃圾收集的時候，垃圾收集器會調用 finalize() 方法，通過讓其
他對象知道它的存在，而使不可到達的對象再次「復蘇」為可到達的對
象。既然每個對象只能調用一次 finalize() 方法，所以每個對象也只
可能「復蘇」一次。
13. finalize() 方法可以明確地被調用，但它卻不能進行垃圾收集。
14. finalize() 方法可以被重載（overload），但只有具備初始的
finalize() 方法特點的方法才可以被垃圾收集器調用。
15. 子類別 [改18] 的 finalize() 方法可以明確地調用父類別 [改18] 的
finalize() 方法，作為該子類對象的最後一次適當的操作。但 Java
編譯器卻不認為這是一次覆蓋操作（overriding），所以也不會對其調
用進行檢查。
16. 當 finalize() 方法尚未被調用時，System.runFinalization() 方法
可以用來調用 finalize() 方法，並實現相同的效果，對無用對象進行
垃圾收集。
17. 當一個方法 [註3] 執行完畢，其中的局部變數就會超出使用範圍，此
時可以被當作垃圾收集。但以後每當該方法再次被調用時，其中的局部
變數便會被重新創建。
18. Java 語言使用了一種「標記交換區的垃圾收集演算法」。該演算法會
遍歷程式中每一個對象的句柄，為被引用的對象做標記，然後回收尚未
做標記的對象。所謂遍歷可以簡單地理解為「檢查每一個」。 [註4]
19. Java 語言允許程式員為任何方法添加 finalize() 方法，該方法會在
垃圾收集器交換回收對象之前被調用。但不要過分依賴該方法對系統資
源進行回收和再利用，因為該方法調用後的執行結果是不可預知的。
通過以上對垃圾收集器特點的了解，你應該可以明確垃圾收集器的作用，和
垃圾收集器判斷一塊記憶體空間是否無用的標準。簡單地說，當你為一個對象賦
值為 null 並且重新定向了該對象的引用者，此時該對象就符合垃圾收集器的收
集標準。
判斷一個對像是否符合垃圾收集器的收集標準，這是SUN公司程式員認證考
試中垃圾收集器部分的重要考點（可以說，這是唯一的考點）。所以，考生在一
段給定的代碼中，應該能夠判斷出哪個對象符合垃圾收集器收集的標準，哪個不
符合。下面結合幾種認證考試中可能出現的題型來具體講解：
Object obj = new Object ();
我們知道，obj 為 Object 的一個句柄。當出現 new 關鍵字時，就給新建
的對象分配記憶體空間，而 obj 的值就是新分配的記憶體空間的首地址，即該
對象的值（請特別注意，對象的值和對象的內容是不同含義的兩個概念：對象的
值就是指其記憶體塊的首地址，即對象的句柄；而對象的內容則是其具體的記憶
體塊）。此時如果有 obj = null；則 obj 指向的記憶體塊此時就無用了，因為
下面再沒有調用該變數了。
請再看以下三種認證考試時可能出現的題型：
程式段1：
1. fobj = new Object ();
2. fobj.Method();
3. fobj = new Object( ) ;
4. fobj.Method( ) ;
問：這段代碼中，第幾行的 fobj 符合垃圾收集器的收集標準？
答：第 3 行。因為第 3 行的 fobj 被賦了新值，產生了一個新的對象，即
換了一塊新的記憶體空間，也相當於為第 1 行中的 fobj 賦了 null 值。這種
類型的題在認證考試中是最簡單的。
程式段2：
1. Object sobj = new Object ();
2. Object sobj = null;
3. Object sobj = new Object ();
4. sobj = new Object ();
問：這段代碼中，第幾行的記憶體空間符合垃圾收集器的收集標準？
答：第 1 行和第 3 行。因為第 2 行為 sobj 賦值為 null，所以在此第
1 行的 sobj 符合垃圾收集器的收集標準。而第 4 行相當於為 sobj 賦值為
null，所以在此第 3 行的 sobj 也符合垃圾收集器的收集標準。
如果有一個對象的句柄 a，且你把 a 作為某個構造器的參數，即 new
Constructor(a) 的時候，即使你給 a 賦值為 null，a 也不符合垃圾收集器的
收集標準。直到由上面構造器構造的新對象被賦空值時，a 才可以被垃圾收集器
收集。
程式段3：
1. Object aobj = new Object ();
2. Object bobj = new Object ();
3. Object cobj = new Object ();
4. aobj = bobj;
5. aobj = cobj;
6. cobj = null;
7. aobj = null;
問：這段代碼中，第幾行的記憶體空間符合垃圾收集器的收集標準？
答：第 7 行。注意這類題型是認證考試中可能遇到的最難題型了。
行 1～3 分別創建了 Object 類的三個對象：aobj，bobj，cobj
行 4：此時對象 aobj 的句柄指向 bobj，所以該行的執行不能使 aobj 符
合垃圾收集器的收集標準。
行 5：此時對象 aobj 的句柄指向 cobj，所以該行的執行不能使 aobj 符
合垃圾收集器的收集標準。
行 6：此時仍沒有任何一個對象符合垃圾收集器的收集標準。
行 7：對象 cobj 符合了垃圾收集器的收集標準，因為 cobj 的句柄指向單
一的地址空間。在第 6 行的時候，cobj 已經被賦值為 null，但由 cobj 同時
還指向了 aobj（第 5 行），所以此時 cobj 並不符合垃圾收集器的收集標準。
而在第 7 行，aobj 所指向的地址空間也被賦予了空值 null，這就說明瞭，由
cobj 所指向的地址空間已經被完全地賦予了空值。所以此時 cobj 最終符合了
垃圾收集器的收集標準。但對於 aobj 和 bobj，仍然無法判斷其是否符合收集
標準。
總之，在Java語言中，判斷一塊記憶體空間是否符合垃圾收集器收集標準的
標準只有兩個：
1. 給對象賦予了空值null，以下再沒有調用過。
2. 給對象賦予了新值，既重新分配了記憶體空間。
最後再次提醒一下，一塊記憶體空間符合了垃圾收集器的收集標準，並不意
味著這塊記憶體空間就一定會被垃圾收集器收集。
==========================================================================
修改部份
1. 返回→交還
2. 死機→當機
3. 限製→限制
4. 面向對象→物件導向
5. 線程→ Thread（其後不再註明）
6. 垃圾收集器線程→垃圾收集器（其後不再註明）
7. 每一快→每一塊
8. 記憶體→CPU
9. 記憶體滲漏體→memory leaks（其後不再註明）
10. 極大可能→盡可能
11. Java虛擬機→JVM（其後不再註明）
12. 的執行是自動的→是自動執行的
13. System. gc→System.gc()（其後不再註明）
14. 不能再被→不再被
15. 作為低優先級的線程運行→低優先等級的 thread
16. 代碼→程式碼（其後不再註明）
17. 初始化為null值→設定為 null
18. 類→類別
註解部份
0. 把第一段的廢話砍掉
1. handles, reference variables
2. 應該是 reference
（上述兩個，如果有更好的中文翻譯，懇請賜教）
3. 應該是 method
4. 詳細演算法內容可參考下列網址
http://www.microsoft.com/taiwan/msdn/columns/DoNet/garbage_collection.htm
--
[1;33;41m 侃侃長論鮮窒礙 [m 網站：http://www.psmonkey.idv.tw
[1;33;41m 眾目睽睽無心顫 [m 個人版：telnet://legend.twbbs.org
[1;33;41m 煢居少聊常人事 [m
[1;33;41m 殺頭容易告白難 [m 歡迎參觀 Java 版（@ptt.cc）精華區 \囧/
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.126.172.167
※ 編輯: PsMonkey 來自: 59.126.172.167 (08/09 22:06)
http://big5.ccidnet.com:89/gate/big5/java.ccidnet.com/
art/297/20060809/790019_1.html
然後修改錯字、刪贅字、替換台灣慣用語與標點符號、重新排版而成。
大部分修改都有附上原文，以防失去替換有誤。
少數贅字 & 標點符號更換則沒有。
這篇文章好像已經沒啥版權問題？我不清楚
不過... 萬一我因此被抓去關，大家記得要來看我... [茶]
====================================================================
[註0]
我們知道，許多程式設計語言都允許在程式運行期動態地分配記憶體空間。
分配記憶體的方式多種多樣，取決於該種語言的語法結構。但不論是哪一種語言
的記憶體分配方式，最後都要交還 [改1] 所分配的記憶體塊的起始地址，即交
還 [改1] 一個指針到記憶體塊的首地址。
當已經分配的記憶體空間不再需要時，換句話說當指向該記憶體塊的句柄
[註1] 超出了使用範圍的時候，該程式或其運行環境就應該回收該記憶體空間，
以節省寶貴的記憶體資源。
在 C，C++ 或其他程式設計語言中，無論是對象 [註2] 還是動態配置的資
源或記憶體，都必須由程式員自行聲明產生和回收，否則其中的資源將消耗，造
成資源的浪費甚至當機。但手工回收記憶體往往是一項複雜而艱巨的工作。因為
要預先確定佔用的記憶體空間是否應該被回收是非常困難的！如果一段程式不能
回收記憶體空間，而且在程式運行時系統中又沒有了可以分配的記憶體空間時，
這段程式就只能崩潰。通常，我們把分配出去後，卻無法回收的記憶體空間稱為
「記憶體滲漏體（Memory Leaks）」。
以上這種程式設計的潛在危險性在 Java 這樣以嚴謹、安全著稱的語言中是
不允許的。但是 Java 語言既不能限制 [改3] 程序員編寫程式的自由性，又不
能把聲明對象的部分去除（否則就不是物件導向 [改4] 的程式語言了），那麼
最好的解決辦法就是從 Java 程式語言本身的特性入手。於是，Java 技術提供
了一個系統級的 thread [改5]，即垃圾收集器 [改6]（Garbage Collection
Thread），來跟蹤每一塊分配出去的記憶體空間，當 Java 虛擬機（Java
Virtual Machine）處於空閒迴圈時，垃圾收集器會自動檢查每一塊 [改7] 分配
出去的記憶體空間，然後自動回收每一塊 [改7] 可以回收的無用的記憶體塊。
垃圾收集器是一種低優先級的執行緒，在一個 Java 程式的生命週期中，它
只有在 CPU [改8] 空閒的時候才有機會運行。它有效地防止了 memory leaks
[改9] 的出現，並盡可能 [改10] 地節省了寶貴的記憶體資源。但是，通過 JVM
[改11] 來執行垃圾收集器的方案可以是多種多樣的。
下面介紹垃圾收集器的特點和它的執行機制：
垃圾收集器系統有自己的一套方案來判斷哪個記憶體塊是應該被回收的、哪
個是不符合要求暫不回收的。垃圾收集器在一個 Java 程式中是自動執行的
[改12]，不能強制執行。即使程式員能明確地判斷出有一塊記憶體已經無用了、
是應該回收的，程式員也不能強制垃圾收集器回收該記憶體塊。程式員唯一能做
的就是通過調用 [改13] 方法來「建議」執行垃圾收集器；但其是否可以執行，
什麼時候執行卻都是不可知的。這也是垃圾收集器的最主要的缺點。當然相對於
它給程式員帶來的巨大方便性而言，這個缺點是瑕不掩瑜的。
垃圾收集器的主要特點有：
1. 垃圾收集器的工作目標是回收已經無用的對象的記憶體空間，從而避免
memory leaks 產生、節省記憶體資源、避免程式代碼的崩潰。
2. 垃圾收集器判斷一個對象的記憶體空間是否無用的標準是：如果該對象
不再被 [改14] 程式中任何一個「活動的部分」所引用，此時我們就說
，該對象的記憶體空間已經無用。所謂「活動的部分」，是指程式中某
部分參與程式的調用，正在執行過程中，尚未執行完畢。
3. 垃圾收集器雖然是低優先等級的 thread [改15]，但在系統可用記憶體
量過低的時候，它可能會突發地執行來挽救記憶體資源。當然其執行與
否也是不可預知的。
4. 垃圾收集器不可以被強制執行，但程式員可以通過調用 System.gc() 方
法來建議執行垃圾收集器。
5. 不能保證一個無用的對象一定會被垃圾收集器收集，也不能保證垃圾收
集器在一段 Java 語言代碼中一定會執行。因此在程式執行過程中被分
配出去的記憶體空間可能會一直保留到該程式執行完畢，除非該空間被
重新分配或被其他方法回收。由此可見，完全徹底地根絕 memory leaks
的產生也是不可能的。但是請不要忘記，Java 的垃圾收集器畢竟使程式
員從手工回收記憶體空間的繁重工作中解脫了出來。設想一個程式員要
用 C 或 C++ 來編寫一段 10 萬行語句的程式碼 [改16]，那麼他一定會
充分體會到 Java 垃圾收集器的優點！
6. 同樣沒有辦法預知在一組均符合垃圾收集器收集標準的對象中，哪一個
會被首先收集。
7. 迴圈引用對象不會影響其被垃圾收集器收集。
8. 可以通過將對象的引用變數（reference variables，即句柄 handles）
設定為 null [改17]，來暗示垃圾收集器來收集該對象。但此時，如果
該對象連接有事件監聽器（典型的 AWT 組件），那它還是不可以被收集
。所以在設一個引用變數為 null 值之前，應注意該引用變數指向的對
像是否被監聽，若有，要首先除去監聽器，然後才可以賦空值。
9. 每一個對象都有一個 finalize() 方法，這個方法是從 Object 類繼承
來的。
10. finalize() 方法用來回收記憶體以外的系統資源，就像是文件處理器
和網路連接器。該方法的調用順序和用來調用該方法的對象的創建順序
是無關的。換句話說，書寫程式時該方法的順序和方法的實際調用順序
是不相干的。請注意這只是 finalize() 方法的特點。
11. 每個對象只能調用 finalize() 方法一次。如果在 finalize() 方法執
行時產生異常（exception），則該對象仍可以被垃圾收集器收集。
12. 垃圾收集器跟蹤每一個對象，收集那些不可到達的對象（即該對象沒有
被程式的任何「活的部分」所調用），回收其佔有的記憶體空間。但在
進行垃圾收集的時候，垃圾收集器會調用 finalize() 方法，通過讓其
他對象知道它的存在，而使不可到達的對象再次「復蘇」為可到達的對
象。既然每個對象只能調用一次 finalize() 方法，所以每個對象也只
可能「復蘇」一次。
13. finalize() 方法可以明確地被調用，但它卻不能進行垃圾收集。
14. finalize() 方法可以被重載（overload），但只有具備初始的
finalize() 方法特點的方法才可以被垃圾收集器調用。
15. 子類別 [改18] 的 finalize() 方法可以明確地調用父類別 [改18] 的
finalize() 方法，作為該子類對象的最後一次適當的操作。但 Java
編譯器卻不認為這是一次覆蓋操作（overriding），所以也不會對其調
用進行檢查。
16. 當 finalize() 方法尚未被調用時，System.runFinalization() 方法
可以用來調用 finalize() 方法，並實現相同的效果，對無用對象進行
垃圾收集。
17. 當一個方法 [註3] 執行完畢，其中的局部變數就會超出使用範圍，此
時可以被當作垃圾收集。但以後每當該方法再次被調用時，其中的局部
變數便會被重新創建。
18. Java 語言使用了一種「標記交換區的垃圾收集演算法」。該演算法會
遍歷程式中每一個對象的句柄，為被引用的對象做標記，然後回收尚未
做標記的對象。所謂遍歷可以簡單地理解為「檢查每一個」。 [註4]
19. Java 語言允許程式員為任何方法添加 finalize() 方法，該方法會在
垃圾收集器交換回收對象之前被調用。但不要過分依賴該方法對系統資
源進行回收和再利用，因為該方法調用後的執行結果是不可預知的。
通過以上對垃圾收集器特點的了解，你應該可以明確垃圾收集器的作用，和
垃圾收集器判斷一塊記憶體空間是否無用的標準。簡單地說，當你為一個對象賦
值為 null 並且重新定向了該對象的引用者，此時該對象就符合垃圾收集器的收
集標準。
判斷一個對像是否符合垃圾收集器的收集標準，這是SUN公司程式員認證考
試中垃圾收集器部分的重要考點（可以說，這是唯一的考點）。所以，考生在一
段給定的代碼中，應該能夠判斷出哪個對象符合垃圾收集器收集的標準，哪個不
符合。下面結合幾種認證考試中可能出現的題型來具體講解：
Object obj = new Object ();
我們知道，obj 為 Object 的一個句柄。當出現 new 關鍵字時，就給新建
的對象分配記憶體空間，而 obj 的值就是新分配的記憶體空間的首地址，即該
對象的值（請特別注意，對象的值和對象的內容是不同含義的兩個概念：對象的
值就是指其記憶體塊的首地址，即對象的句柄；而對象的內容則是其具體的記憶
體塊）。此時如果有 obj = null；則 obj 指向的記憶體塊此時就無用了，因為
下面再沒有調用該變數了。
請再看以下三種認證考試時可能出現的題型：
程式段1：
1. fobj = new Object ();
2. fobj.Method();
3. fobj = new Object( ) ;
4. fobj.Method( ) ;
問：這段代碼中，第幾行的 fobj 符合垃圾收集器的收集標準？
答：第 3 行。因為第 3 行的 fobj 被賦了新值，產生了一個新的對象，即
換了一塊新的記憶體空間，也相當於為第 1 行中的 fobj 賦了 null 值。這種
類型的題在認證考試中是最簡單的。
程式段2：
1. Object sobj = new Object ();
2. Object sobj = null;
3. Object sobj = new Object ();
4. sobj = new Object ();
問：這段代碼中，第幾行的記憶體空間符合垃圾收集器的收集標準？
答：第 1 行和第 3 行。因為第 2 行為 sobj 賦值為 null，所以在此第
1 行的 sobj 符合垃圾收集器的收集標準。而第 4 行相當於為 sobj 賦值為
null，所以在此第 3 行的 sobj 也符合垃圾收集器的收集標準。
如果有一個對象的句柄 a，且你把 a 作為某個構造器的參數，即 new
Constructor(a) 的時候，即使你給 a 賦值為 null，a 也不符合垃圾收集器的
收集標準。直到由上面構造器構造的新對象被賦空值時，a 才可以被垃圾收集器
收集。
程式段3：
1. Object aobj = new Object ();
2. Object bobj = new Object ();
3. Object cobj = new Object ();
4. aobj = bobj;
5. aobj = cobj;
6. cobj = null;
7. aobj = null;
問：這段代碼中，第幾行的記憶體空間符合垃圾收集器的收集標準？
答：第 7 行。注意這類題型是認證考試中可能遇到的最難題型了。
行 1～3 分別創建了 Object 類的三個對象：aobj，bobj，cobj
行 4：此時對象 aobj 的句柄指向 bobj，所以該行的執行不能使 aobj 符
合垃圾收集器的收集標準。
行 5：此時對象 aobj 的句柄指向 cobj，所以該行的執行不能使 aobj 符
合垃圾收集器的收集標準。
行 6：此時仍沒有任何一個對象符合垃圾收集器的收集標準。
行 7：對象 cobj 符合了垃圾收集器的收集標準，因為 cobj 的句柄指向單
一的地址空間。在第 6 行的時候，cobj 已經被賦值為 null，但由 cobj 同時
還指向了 aobj（第 5 行），所以此時 cobj 並不符合垃圾收集器的收集標準。
而在第 7 行，aobj 所指向的地址空間也被賦予了空值 null，這就說明瞭，由
cobj 所指向的地址空間已經被完全地賦予了空值。所以此時 cobj 最終符合了
垃圾收集器的收集標準。但對於 aobj 和 bobj，仍然無法判斷其是否符合收集
標準。
總之，在Java語言中，判斷一塊記憶體空間是否符合垃圾收集器收集標準的
標準只有兩個：
1. 給對象賦予了空值null，以下再沒有調用過。
2. 給對象賦予了新值，既重新分配了記憶體空間。
最後再次提醒一下，一塊記憶體空間符合了垃圾收集器的收集標準，並不意
味著這塊記憶體空間就一定會被垃圾收集器收集。
==========================================================================
修改部份
1. 返回→交還
2. 死機→當機
3. 限製→限制
4. 面向對象→物件導向
5. 線程→ Thread（其後不再註明）
6. 垃圾收集器線程→垃圾收集器（其後不再註明）
7. 每一快→每一塊
8. 記憶體→CPU
9. 記憶體滲漏體→memory leaks（其後不再註明）
10. 極大可能→盡可能
11. Java虛擬機→JVM（其後不再註明）
12. 的執行是自動的→是自動執行的
13. System. gc→System.gc()（其後不再註明）
14. 不能再被→不再被
15. 作為低優先級的線程運行→低優先等級的 thread
16. 代碼→程式碼（其後不再註明）
17. 初始化為null值→設定為 null
18. 類→類別
註解部份
0. 把第一段的廢話砍掉
1. handles, reference variables
2. 應該是 reference
（上述兩個，如果有更好的中文翻譯，懇請賜教）
3. 應該是 method
4. 詳細演算法內容可參考下列網址
http://www.microsoft.com/taiwan/msdn/columns/DoNet/garbage_collection.htm
--
[1;33;41m 侃侃長論鮮窒礙 [m 網站：http://www.psmonkey.idv.tw
[1;33;41m 眾目睽睽無心顫 [m 個人版：telnet://legend.twbbs.org
[1;33;41m 煢居少聊常人事 [m
[1;33;41m 殺頭容易告白難 [m 歡迎參觀 Java 版（@ptt.cc）精華區 \囧/
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 59.126.172.167
※ 編輯: PsMonkey 來自: 59.126.172.167 (08/09 22:06)