大家好，我是 BookSea。

作為一名Java程序員，我們每天都在程序里不停地去new對(duì)象，但是你知道這些被new出來(lái)的對(duì)象，最后是怎么被回收的嗎？

在堆里面存放著Java世界中幾乎所有的對(duì)象實(shí)例，垃圾收集器在對(duì)堆進(jìn)行回收前，第一件事情就是要確定這些對(duì)象之中哪些還「存活」著，哪些已經(jīng)「死去」（“死去”即不可能再被任何途徑使用的對(duì)象）。

JVM必然是有自己的一套方法來(lái)判斷哪些對(duì)象該回收，哪些不該回收。

本篇文章就來(lái)聊聊這個(gè)話題。

一、引用計(jì)數(shù)算法

這種算法的工作原理是這樣的：在對(duì)象中添加一個(gè)引用計(jì)數(shù)器，每當(dāng)有一個(gè)地方引用它時(shí)，計(jì)數(shù)器值就加一；當(dāng)引用失效時(shí)，計(jì)數(shù)器值就減一；任何時(shí)刻計(jì)數(shù)器為零的對(duì)象就是不可能再被使用的。

客觀的說(shuō)，引用計(jì)數(shù)算法雖然占用了一些額外的內(nèi)存空間來(lái)計(jì)數(shù)，但原理簡(jiǎn)單，效率也很高。

但是目前主流的Java虛擬機(jī)里面都沒有選用引用計(jì)數(shù)法來(lái)進(jìn)行內(nèi)存管理，why？

主要原因是，引用計(jì)數(shù)算法很難解決對(duì)象之間相互「循環(huán)引用」的問題。下面放段代碼，舉個(gè)例子：

public class MyObject {
    public Object ref = null;
    public static void main(String[] args) {
        MyObject myObject1 = new MyObject();
        MyObject myObject2 = new MyObject();
        myObject1.ref = myObject2;
        myObject2.ref = myObject1;
        myObject1 = null;
        myObject2 = null;
    }
}

這段代碼里定義了一個(gè)類MyObject，只有一個(gè)成員變量ref。

當(dāng)設(shè)置myObject1 = null和myObject2 = null后，僅僅是清除了myObject1和myObject2變量所持有的引用。并沒有影響到myObject1對(duì)象內(nèi)部的ref字段和myObject2對(duì)象內(nèi)部的ref字段，它們?nèi)匀辉谙嗷ヒ谩?/p>

我們可以看出myObject1和myObject2這兩個(gè)對(duì)象除互相引用外再無(wú)任何引用，實(shí)際上這兩個(gè)對(duì)象已經(jīng)不可能再被訪問，但是它們因?yàn)榛ハ嘁弥鴮?duì)方，導(dǎo)致它們的引用計(jì)數(shù)都不為零，引用計(jì)數(shù)算法也就無(wú)法回收它們，這就是循環(huán)引用問題。

有點(diǎn)類似死鎖的概念，A和B互相持有，誰(shuí)也不釋放，直接卡住。

通過這個(gè)例子我們可以看出引用計(jì)數(shù)法是存在弊端的。

所以HotSpot虛擬機(jī)并不是通過引用計(jì)數(shù)算法來(lái)判斷對(duì)象是否存活的，使用的是「可達(dá)性分析算法」。

二、可達(dá)性分析算法

JVM通過可達(dá)性分析（Reachability Analysis）算法來(lái)判定對(duì)象是否存活的。

這個(gè)算法的基本思路就是通過一系列稱為GC Roots的根對(duì)象作為起始節(jié)點(diǎn)集，從這些節(jié)點(diǎn)開始，根據(jù)引用關(guān)系向下搜索。

搜索過程所走過的路徑稱為引用鏈（Reference Chain），如果某個(gè)對(duì)象到GC Roots間沒有任何引用鏈相連，或者用圖論的話來(lái)說(shuō)就是從GC Roots到這個(gè)對(duì)象不可達(dá)時(shí)，則證明此對(duì)象是不可能再被使用的。

如圖，對(duì)象object 5、object 6、object 7到GC Roots是不可達(dá)的，因此它們將會(huì)被判定為可回收的對(duì)象。

上文提到的GC Roots，我們可以認(rèn)為是起點(diǎn)，而在JVM里面，固定可以作為GC Roots的對(duì)象包括以下幾種：

• 在虛擬機(jī)棧（棧中 的本地變量表）中引用的對(duì)象，例如各個(gè)線程被調(diào)用的方法堆棧中使用到的參數(shù)、局部變量、臨時(shí)變量等。
• 在方法區(qū)中常量引用的對(duì)象，例如字符串常量池（String Table）里的引用。
• 在本地方法棧中JNI（本地方法）引用的對(duì)象。
• Java虛擬機(jī)內(nèi)部的引用，如基本數(shù)據(jù)類型對(duì)應(yīng)的Class對(duì)象，一些常駐的異常對(duì)象（NullPointException、OutOfMemoryError）等，以及系統(tǒng)類加載器。
• 所有被同步鎖（synchronized）持有的對(duì)象。
• 反映Java虛擬機(jī)內(nèi)部情況的JMXBean、JVMTI中注冊(cè)的回調(diào)、本地代碼緩存等。

通過枚舉一個(gè)一個(gè)根節(jié)點(diǎn)(GC Roots)，然后順藤摸瓜一路摸下來(lái)，然后沒摸到的那些對(duì)象，也就是不存在引用的對(duì)象就把它咔嚓回收了。這個(gè)過程稱之為「根節(jié)點(diǎn)枚舉」。

目前所有的垃圾收集器在根節(jié)點(diǎn)枚舉這一步驟時(shí)都是必須暫停用戶線程的，也就是必須會(huì)有STW（Stop the Wrold）。

這里面細(xì)講東西很多，先埋個(gè)坑，后續(xù)會(huì)有文章專門來(lái)講根節(jié)點(diǎn)枚舉。

上面我們講了可達(dá)性分析算法是根據(jù)引用來(lái)回收的，而對(duì)不同的引用類型有不同的處理方式，JVM也是會(huì)去「差別對(duì)待的」。

三、引用類型

Java將引用分為強(qiáng)引用（Strongly Re-ference）、軟引用（Soft Reference）、弱引用（Weak Reference）和虛引用（Phantom Reference）4種，這4種引用強(qiáng)度依次逐漸減弱：

• 強(qiáng)引用是最傳統(tǒng)的“引用”的定義，在程序代碼之中普遍存在，即類似Object obj=new Object()這種引用關(guān)系。如果一個(gè)對(duì)象具有強(qiáng)引用，那就類似于"必不可少的生活用品"。只要強(qiáng)引用還存在，垃圾收集器永遠(yuǎn)不會(huì)回收掉被引用的對(duì)象。
• 軟引用是用來(lái)描述一些還有用，但非必須的對(duì)象。只被軟引用關(guān)聯(lián)著的對(duì)象，在系統(tǒng)將要發(fā)生內(nèi)存溢出異常前，會(huì)把這些對(duì)象列進(jìn)回收范圍之中進(jìn)行第二次回收，如果這次回收還沒有足夠的內(nèi)存，才會(huì)拋出內(nèi)存溢出異常。在JDK 1.2版之后提供了SoftReference類來(lái)實(shí)現(xiàn)軟引用。
• 弱引用也是用來(lái)描述那些非必須對(duì)象，但是它的強(qiáng)度比軟引用更弱一些，被弱引用關(guān)聯(lián)的對(duì)象只能生存到下一次垃圾收集發(fā)生為止。當(dāng)垃圾收集器開始工作，無(wú)論當(dāng)前內(nèi)存是否足夠，都會(huì)回收掉只被弱引用關(guān)聯(lián)的對(duì)象。在JDK 1.2版之后提供了WeakReference類來(lái)實(shí)現(xiàn)弱引用。
• 虛引用是最弱的一種引用關(guān)系。如果一個(gè)對(duì)象僅持有虛引用，那么它就和沒有任何引用一樣，隨時(shí)都可能被垃圾回收器回收，無(wú)法通過虛引用來(lái)取得一個(gè)對(duì)象實(shí)例。虛引用主要用來(lái)跟蹤對(duì)象被垃圾回收器回收的活動(dòng)，比如確保某個(gè)資源被finalize后，做一些后續(xù)的清理工作。在JDK 1.2版之后提供了PhantomReference類來(lái)實(shí)現(xiàn)虛引用。

上面巴拉巴拉說(shuō)了一堆話，我知道你們肯定不愛看，也記不住。所以鐵子，我總結(jié)成一句話，你聽這句話就夠了。

總結(jié)一句話就是：強(qiáng)引用內(nèi)存不足也不會(huì)回收，軟引用內(nèi)存不足才回收，弱引用和虛引用看見就回收。

看到這里有個(gè)疑問，在可達(dá)性分析算法中判定為不可達(dá)的對(duì)象，就一定「非死不可」嗎？

四、Dead Or Alive

當(dāng)一個(gè)對(duì)象被判斷為不可達(dá)的時(shí)候，這時(shí)候該對(duì)象處在「緩刑」階段。

意思就是說(shuō)刀已經(jīng)架你脖子上了，但是還沒落下來(lái)，還是有商量的余地的。

要真正宣告一個(gè)對(duì)象死亡，至少要經(jīng)歷兩次標(biāo)記過程：

如果對(duì)象在進(jìn)行可達(dá)性分析后發(fā)現(xiàn)沒有與GC Roots相連接的引用鏈，那它將會(huì)被第一次標(biāo)記，隨后進(jìn)行一次篩選，篩選的條件是此對(duì)象是否有必要執(zhí)行finalize()方法。

假如對(duì)象沒有覆蓋finalize()方法，或者finalize()方法已經(jīng)被虛擬機(jī)調(diào)用過，那么虛擬機(jī)將這兩種情況都視為“沒有必要執(zhí)行”。

如果這個(gè)對(duì)象被判定為確有必要執(zhí)行finalize()方法，那么該對(duì)象將會(huì)被放置在一個(gè)名為F-Queue的隊(duì)列之中，并在稍后由一條由虛擬機(jī)自動(dòng)建立的、低調(diào)度優(yōu)先級(jí)的Finalizer線程去執(zhí)行它們的finalize()方法。

這里所說(shuō)的“執(zhí)行”是指虛擬機(jī)會(huì)觸發(fā)這個(gè)方法開始運(yùn)行，但并不承諾一定會(huì)等待它運(yùn)行結(jié)束。

這樣做的原因是，如果某個(gè)對(duì)象finalize()方法執(zhí)行緩慢，或者更極端地發(fā)生了死循環(huán)，將很可能導(dǎo)致F-Queue隊(duì)列中的其他對(duì)象永久處于等待，卡死在這里。甚至導(dǎo)致整個(gè)內(nèi)存回收子系統(tǒng)的崩潰。

finalize()方法是對(duì)象逃脫死亡命運(yùn)的最后一次機(jī)會(huì)，救命的最后一根稻草，稍后收集器將對(duì)F-Queue中的對(duì)象進(jìn)行第二次小規(guī)模的標(biāo)記。

如果對(duì)象要在finalize()中成功拯救自己——只要重新與引用鏈上的任何一個(gè)對(duì)象建立關(guān)聯(lián)即可，譬如把自己（this關(guān)鍵字）賦值給某個(gè)類變量或者對(duì)象的成員變量，那在第二次標(biāo)記時(shí)它將被移出「即將回收」的集合。

如果對(duì)象這時(shí)候還沒有逃脫，那基本上它就真的要被回收了，就真要說(shuō)byebye了。

需要注意的是：任何一個(gè)對(duì)象的finalize()方法都只會(huì)被系統(tǒng)自動(dòng)調(diào)用一次，如果對(duì)象面臨下一次回收，它的finalize()方法不會(huì)被再次執(zhí)行，不能指望我每次都救你，我只能救你一次，剩下的就靠你自己了。

看起來(lái)對(duì)象能夠使用finalize()方法實(shí)現(xiàn)自我救贖，然而這個(gè)方法并沒有什么用，放一段《深入理解Java虛擬機(jī)》里的原話：

總結(jié)一下，就是finalize()這個(gè)方法并沒什么卵用，大家還是把他忘了好。

對(duì)象的回收行為主要發(fā)生在新生代和老年代，那么有兄弟可能會(huì)問了，永久代有垃圾回收行為嗎?

五、永久代真的"永久"嗎？

注意一下，這里說(shuō)的永久代，主要還是針對(duì)于Java 8以前，在Java 8以及之后的版本中，永久代被元數(shù)據(jù)區(qū)（Metaspace）取代。

永久代和方法區(qū)和元空間的關(guān)系可能有點(diǎn)混亂，稍微提一嘴：方法區(qū)是由Java虛擬機(jī)規(guī)范定義的一個(gè)邏輯區(qū)域，是個(gè)邏輯上的概念，而永久代和元空間則是HotSpot對(duì)方法區(qū)的兩種不同實(shí)現(xiàn)。

一圖勝千言，直接上圖。

有些人認(rèn)為方法區(qū)（如HotSpot虛擬機(jī)中的元空間或者永久代）是沒有垃圾收集行為的，但其實(shí)方法區(qū)是可以被回收的，只不過回收的判定條件過于苛刻，垃圾收集的成果很差。

并不是名字叫永久代就真的「永久」了，出來(lái)混，欠的債總要還的。

我們先搞清楚方法區(qū)要回收的是什么，方法區(qū)的垃圾收集主要回收兩部分內(nèi)容：「廢棄的常量」和「不再使用的類型」。

判定一個(gè)常量是否“廢棄”還是相對(duì)簡(jiǎn)單，看這個(gè)常量有沒有在用就行了，而要判定一個(gè)類型是否屬于「不再被使用的類」的條件就比較苛刻了。需要同時(shí)滿足下面三個(gè)條件（注意是同時(shí)?。?/p>

• 該類所有的實(shí)例都已經(jīng)被回收，也就是Java堆中不存在該類及其任何派生子類的實(shí)例。
• 加載該類的類加載器已經(jīng)被回收，這個(gè)條件除非是經(jīng)過精心設(shè)計(jì)的可替換類加載器的場(chǎng)景，如OSGi、JSP的重加載等，否則通常是很難達(dá)成的。
• 該類對(duì)應(yīng)的java.lang.Class對(duì)象沒有在任何地方被引用，無(wú)法在任何地方通過反射訪問該類的方法。

Java虛擬機(jī)被允許對(duì)滿足上述三個(gè)條件的無(wú)用類進(jìn)行回收，這里說(shuō)的僅僅是“被允許”，而并不是和對(duì)象一樣，沒有引用了就必然會(huì)回收。

關(guān)于是否要對(duì)類型進(jìn)行回收，HotSpot虛擬機(jī)提供了-Xnoclassgc參數(shù)進(jìn)行控制。

對(duì)于Oracle的HotSpot JVM，這個(gè)參數(shù)默認(rèn)是不開啟的，意味著默認(rèn)情況下，類元數(shù)據(jù)可以被垃圾收集器回收。如果你明確使用了 -Xnoclassgc 參數(shù)來(lái)啟動(dòng)JVM，那么就會(huì)禁止類的垃圾回收。

也就是說(shuō)如果沒有開啟這項(xiàng)參數(shù)支持類型的卸載，哪怕滿足了所有條件，也不會(huì)進(jìn)行類型的卸載。

上面我們講了對(duì)象回收的條件，知道了回收的條件之后，我們?cè)僦v講怎么被回收，也就是垃圾回收算法。

這塊可是面試重點(diǎn)，面試問到JVM這塊少不了要被教育一番，大家好好聽，下次可以跟面試官對(duì)波線。

六、垃圾收集算法

垃圾收集（Garbage Collection，GC）算法是Java虛擬機(jī)（JVM）用來(lái)自動(dòng)管理內(nèi)存的一種方式。主要的目標(biāo)是找出那些已經(jīng)不再使用的對(duì)象，并釋放它們所占用的內(nèi)存空間。

通俗來(lái)說(shuō)就是發(fā)現(xiàn)垃圾之后怎么收垃圾，是打包帶走，還是來(lái)個(gè)垃圾分類。

1.標(biāo)記-清除算法

標(biāo)記-清除算法是最早出現(xiàn)也是最基礎(chǔ)的垃圾收集算法。

它分為「標(biāo)記」和「清除」兩個(gè)階段：首先標(biāo)記出所有需要回收的對(duì)象，在標(biāo)記完成后，統(tǒng)一回收掉所有被標(biāo)記的對(duì)象，也可以反過來(lái)，標(biāo)記存活的對(duì)象，統(tǒng)一回收所有未被標(biāo)記的對(duì)象。

下圖為使用“標(biāo)記-清除”算法回收前后的狀態(tài)：

優(yōu)點(diǎn)：不需要進(jìn)行對(duì)象的移動(dòng)，在存活對(duì)象比較多的情況下非常高效。

缺點(diǎn)：標(biāo)記-清除算法主要缺點(diǎn)有兩個(gè)：

• 第一個(gè)是執(zhí)行效率不穩(wěn)定，如果Java堆中包含大量對(duì)象，而且其中大部分是需要被回收的，這時(shí)必須進(jìn)行大量標(biāo)記和清除的動(dòng)作。
• 第二個(gè)是內(nèi)存空間的碎片化問題，標(biāo)記、清除之后會(huì)產(chǎn)生大量不連續(xù)的「內(nèi)存碎片」，而內(nèi)存碎片是無(wú)法被分配對(duì)象的，內(nèi)存碎片太多可能會(huì)導(dǎo)致當(dāng)以后在程序運(yùn)行過程中需要分配較大對(duì)象時(shí)無(wú)法找到足夠的連續(xù)內(nèi)存而不得不提前觸發(fā)另一次垃圾收集動(dòng)作。

第一個(gè)問題其實(shí)還好，但是第二個(gè)內(nèi)存碎片是個(gè)大問題，無(wú)法容忍。試想一下就跟你打游戲，玩著越來(lái)越卡，玩一秒卡二秒，這還怎么玩？

所以后續(xù)的收集算法大多都是以標(biāo)記-清除算法為基礎(chǔ)，改進(jìn)了內(nèi)存碎片的問題，對(duì)其缺點(diǎn)進(jìn)行改進(jìn)而得到的。

2.標(biāo)記-復(fù)制算法

為了解決標(biāo)記-清除算法面對(duì)大量可回收對(duì)象時(shí)執(zhí)行效率低的問題，1969年Fenichel提出了一種稱為「半?yún)^(qū)復(fù)制（Semispace Copying）」的垃圾收集算法。

它將可用內(nèi)存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當(dāng)這一塊的內(nèi)存用完了，就將還存活著的對(duì)象復(fù)制到另外一塊上面，然后再把已使用過的內(nèi)存空間一次清理掉。

如果內(nèi)存中多數(shù)對(duì)象都是存活的，這種算法將會(huì)產(chǎn)生大量的內(nèi)存間復(fù)制的開銷，但對(duì)于多數(shù)對(duì)象都是可回收的情況，算法需要復(fù)制的就是占少數(shù)的存活對(duì)象，而且每次都是針對(duì)整個(gè)半?yún)^(qū)進(jìn)行內(nèi)存回收，分配內(nèi)存時(shí)也就不用考慮有空間碎片的復(fù)雜情況。

所以，標(biāo)記-復(fù)制算法通常用在新生代的Eden區(qū)和Survivor區(qū)，這兩個(gè)區(qū)的對(duì)象，朝生夕死，多數(shù)對(duì)象都是可回收的。

總結(jié)一下，標(biāo)記-復(fù)制算法有如下優(yōu)點(diǎn)和缺點(diǎn)：

• 優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單，內(nèi)存回收時(shí)不用考慮內(nèi)存碎片的出現(xiàn)。
• 缺點(diǎn)：代價(jià)是將可用內(nèi)存縮小為了原來(lái)的一半，并且在對(duì)象存活率較高時(shí)就要進(jìn)行較多的復(fù)制操作，效率將會(huì)降低。

下圖為使用復(fù)制算法回收前后的狀態(tài)：

標(biāo)記-復(fù)制看著還行，但是比較大的缺點(diǎn)是浪費(fèi)了50%的空間，要知道內(nèi)存是很貴的啊。

3.標(biāo)記-整理算法

標(biāo)記-復(fù)制算法在對(duì)象存活率較高時(shí)就要進(jìn)行較多的復(fù)制操作，效率將會(huì)降低。

更關(guān)鍵的是，如果不想浪費(fèi)50%的空間，就需要有額外的空間進(jìn)行分配擔(dān)保，以應(yīng)對(duì)被使用的內(nèi)存中所有對(duì)象都100%存活的極端情況。

所以在老年代一般不能直接選用這種算法。針對(duì)老年代對(duì)象的存亡特征，1974年Edward Lueders提出了另外一種有針對(duì)性的標(biāo)記-整理（Mark-Compact）算法。

其中的標(biāo)記過程仍然與“標(biāo)記-清除”算法一樣，但后續(xù)步驟不是直接對(duì)可回收對(duì)象進(jìn)行清理，而是讓所有存活的對(duì)象都向內(nèi)存空間一端移動(dòng)，然后直接清理掉邊界以外的內(nèi)存。

• 優(yōu)點(diǎn)：經(jīng)過整理之后，新對(duì)象的分配只需要通過指針碰撞便能完成，也解決了內(nèi)存碎片的問題。
• 缺點(diǎn)：GC 暫停的時(shí)間會(huì)增長(zhǎng)，對(duì)象移動(dòng)的時(shí)間成本是十分可觀的。

下圖為使用“標(biāo)記-整理”算法回收前后的狀態(tài)：

4.標(biāo)記-清除 VS 標(biāo)記-整理

標(biāo)記-清除算法與標(biāo)記-整理算法的本質(zhì)差異在于前者是一種「非移動(dòng)式」的回收算法，而后者是「移動(dòng)式」的。

別小看這一差異，是否移動(dòng)回收后的存活對(duì)象是一項(xiàng)優(yōu)缺點(diǎn)并存的風(fēng)險(xiǎn)決策。

如果移動(dòng)存活對(duì)象，尤其是在老年代這種每次回收都有大量對(duì)象存活區(qū)域，移動(dòng)存活對(duì)象會(huì)是一種極為負(fù)重的操作，而且這種對(duì)象移動(dòng)操作必須全程暫停用戶應(yīng)用程序才能進(jìn)行。

但如果跟標(biāo)記-清除算法那樣完全不考慮移動(dòng)和整理存活對(duì)象的話，彌散于堆中的存活對(duì)象導(dǎo)致的內(nèi)存碎片問題就只能依賴更為復(fù)雜的內(nèi)存分配器和內(nèi)存訪問器來(lái)解決。

譬如通過「分區(qū)空閑分配鏈表」來(lái)解決內(nèi)存分配問題。

內(nèi)存的訪問是用戶程序最頻繁的操作，甚至都沒有之一，假如在這個(gè)環(huán)節(jié)上增加了額外的負(fù)擔(dān)，勢(shì)必會(huì)直接影響應(yīng)用程序的吞吐量。

基于以上兩點(diǎn)，是否移動(dòng)對(duì)象都存在弊端，移動(dòng)則內(nèi)存回收時(shí)會(huì)更復(fù)雜，不移動(dòng)則內(nèi)存分配時(shí)會(huì)更復(fù)雜。從垃圾收集的停頓時(shí)間來(lái)看，不移動(dòng)對(duì)象停頓時(shí)間會(huì)更短，但是從整個(gè)程序的吞吐量來(lái)看，移動(dòng)對(duì)象會(huì)更劃算。

HotSpot虛擬機(jī)里面關(guān)注吞吐量的Parallel Scavenge收集器是基于標(biāo)記-整理算法的，而關(guān)注延遲的CMS收集器則是基于標(biāo)記-清除算法的，這也從側(cè)面印證這點(diǎn)。

另外，還有一種「和稀泥式」解決方案可以不在內(nèi)存分配和訪問上增加太大額外負(fù)擔(dān)，做法是讓虛擬機(jī)平時(shí)多數(shù)時(shí)間都采用標(biāo)記-清除算法，暫時(shí)容忍內(nèi)存碎片的存在，直到內(nèi)存空間的碎片化程度已經(jīng)大到影響對(duì)象分配時(shí)，再采用標(biāo)記-整理算法收集一次，以獲得規(guī)整的內(nèi)存空間。

基于標(biāo)記-清除算法的CMS收集器采用的就是這種處理辦法。

當(dāng)CMS出現(xiàn)「并發(fā)失敗”（Concurrent Mode Failure）」時(shí)，這時(shí)會(huì)啟用Serial Old收集器來(lái)重新進(jìn)行老年代的垃圾收集，而Serial Old正是基于標(biāo)記-整理算法。

好了，本篇文章到這就結(jié)束了，這篇文章主要是講JVM是怎么回收對(duì)象的，明白了這個(gè)，JVM算是初窺門徑了。