死鎖是多線程和分布式程序中常見(jiàn)的一種嚴(yán)重問(wèn)題。死鎖是毀滅性的，一旦發(fā)生，系統(tǒng)很難或者幾乎不可能恢復(fù)；死鎖是隨機(jī)的，只有滿足特定條件才會(huì)發(fā)生，而如果條件復(fù)雜，雖然發(fā)生概率很低，但是一旦發(fā)生就非常難重現(xiàn)和調(diào)試。

使用鎖而產(chǎn)生的死鎖是死鎖中的一種常見(jiàn)情況。Linux 內(nèi)核使用 Lockdep 工具來(lái)檢測(cè)和特別是預(yù)測(cè)鎖的死鎖場(chǎng)景。然而，目前 Lockdep 只支持處理互斥鎖，不支持更為復(fù)雜的讀寫(xiě)鎖，尤其是遞歸讀鎖（Recursive-read lock）。因此，Lockdep 既會(huì)出現(xiàn)由讀寫(xiě)鎖引起的假陽(yáng)性預(yù)測(cè)錯(cuò)誤，也會(huì)出現(xiàn)假陰性預(yù)測(cè)錯(cuò)誤。

本工作首先解密 Lockdep工具，然后提出一種通用的鎖的死鎖預(yù)測(cè)算法設(shè)計(jì)和實(shí)現(xiàn)（互斥鎖可以看做只使用讀寫(xiě)鎖中的寫(xiě)鎖），同時(shí)證明該算法是正確和全面的解決方案。

今年初，我們相繼解決了對(duì)滴滴基礎(chǔ)平臺(tái)大規(guī)模服務(wù)器集群影響嚴(yán)重的三個(gè)內(nèi)核故障，在我們解決這些問(wèn)題的時(shí)候，很多時(shí)間和精力都花在去尋找是誰(shuí)在哪里構(gòu)成了死鎖，延誤了故障排除時(shí)間，因此當(dāng)時(shí)就想有沒(méi)有什么通用的方法能夠幫助我們對(duì)付死鎖問(wèn)題。

但是因?yàn)闀r(shí)間緊迫，只能針對(duì)性地探索和處理這幾個(gè)具體問(wèn)題。在最終成功修復(fù)了這幾個(gè)內(nèi)核故障后，終于有一些時(shí)間靜下來(lái)去深入思考死鎖發(fā)生的原因和如何去檢測(cè)和預(yù)測(cè)死鎖。

隨著對(duì)這個(gè)問(wèn)題的深入研究，我相繼做出了一些內(nèi)核死鎖預(yù)測(cè)方面的算法優(yōu)化和算法設(shè)計(jì)工作，其中部分已經(jīng)被 Linux 內(nèi)核接收，其他還在評(píng)審階段。

在這里我和大家分享其中的一個(gè)比較重要的工作：一個(gè)通用的讀寫(xiě)鎖的死鎖預(yù)測(cè)算法。這個(gè)工作提出了一個(gè)通用的鎖的死鎖預(yù)測(cè)算法，支持所有 Linux 內(nèi)核讀寫(xiě)鎖，同時(shí)證明該算法是正確和全面的解決方案。這個(gè)算法所解決的核心問(wèn)題已經(jīng)存在超過(guò)10年以上（目前還在社區(qū)評(píng)審階段）。在介紹這個(gè)工作的之前我首先對(duì)死鎖問(wèn)題和 Linux 內(nèi)核死鎖工具 Lockdep 做簡(jiǎn)要的介紹。

一、死鎖（Deadlock）

死鎖在日常生活中并不鮮見(jiàn)。生活在大城市的人都或多或少經(jīng)歷過(guò)下圖所示的場(chǎng)景。在環(huán)島或者十字路口出現(xiàn)的這種情況就是死鎖。也許其中有車(chē)壞了，但是絕大多數(shù)車(chē)子是可以運(yùn)行的?？墒且?yàn)槊枯v車(chē)都得等著前車(chē)走動(dòng)它才能走動(dòng)，所有車(chē)都走不動(dòng)，或者更一般地講它們不能取得進(jìn)展（Make Forward Progress）。

[[358317]]

圖1：環(huán)島道路的交通堵塞（圖片來(lái)源于網(wǎng)絡(luò)）

這種情況發(fā)生的原因是車(chē)輛的等待構(gòu)成了循環(huán)，在這個(gè)循環(huán)中每輛車(chē)的狀態(tài)都是等待前車(chē)，因此所有車(chē)都等不到到它所要等待的。這種車(chē)輛死鎖狀態(tài)會(huì)持續(xù)惡化并產(chǎn)生嚴(yán)重的后果：首先造成路口交通堵塞，而堵塞如果進(jìn)一步擴(kuò)大會(huì)導(dǎo)致大面積交通癱瘓。車(chē)輛死鎖很難自愈，通過(guò)自身走出死鎖狀態(tài)非常困難或者需要很長(zhǎng)時(shí)間，一般都只能通過(guò)人工（如交通警察）干預(yù)才能解決。

在多線程或者分布式系統(tǒng)程序中，死鎖也會(huì)發(fā)生。其本質(zhì)和上述的路口車(chē)輛堵塞是一樣的，都是因?yàn)閰⑴c者構(gòu)成了循環(huán)等待，使得所有參與者都等不到想要的結(jié)果，從而永遠(yuǎn)等在那里不能取得進(jìn)展。Linux 內(nèi)核當(dāng)然也會(huì)發(fā)生死鎖，如果核心部分（Core），如調(diào)度器和內(nèi)存管理，或者子系統(tǒng)，如文件系統(tǒng)，發(fā)生死鎖，都會(huì)導(dǎo)致整個(gè)系統(tǒng)不可用。

死鎖是隨機(jī)發(fā)生的。就像上圖中環(huán)島的情況一樣，環(huán)島就在那里而死鎖并不是總在發(fā)生。但是環(huán)島本身就是死鎖隱患，尤其在交通壓力比較大的路口，環(huán)島會(huì)比較容易產(chǎn)生死鎖。而如果這種路口設(shè)計(jì)成交通信號(hào)燈就會(huì)好很多，如果設(shè)計(jì)成立交橋則又會(huì)好很多。在程序中，我們把可能產(chǎn)生死鎖的場(chǎng)景稱(chēng)作潛在死鎖（Potential Deadlock Scenario），而把即將發(fā)生或正在發(fā)生的死鎖稱(chēng)為死鎖實(shí)例（Concrete Deadlock）。

如何對(duì)付死鎖一直是學(xué)術(shù)界和應(yīng)用領(lǐng)域積極研究和解決的問(wèn)題。我們可以將對(duì)死鎖的解決方案粗略地分為：死鎖發(fā)現(xiàn)（Detection）、死鎖避免（Prevention）和死鎖預(yù)測(cè)（Prediction）。死鎖發(fā)現(xiàn)是指在在程序運(yùn)行中發(fā)現(xiàn)死鎖實(shí)例；死鎖避免則是在發(fā)現(xiàn)死鎖實(shí)例即將生成時(shí)進(jìn)一步防止這個(gè)實(shí)例；而死鎖預(yù)測(cè)則是通過(guò)靜態(tài)或者動(dòng)態(tài)方法找出程序中的潛在死鎖，從而從根本上預(yù)先消除死鎖隱患。

二、鎖的死鎖和 Lockdep

在死鎖中，因?yàn)橛面i（Lock）不當(dāng)而導(dǎo)致的死鎖是一個(gè)重要死鎖來(lái)源。鎖是同步的一種主要手段，用鎖是不可避免的。對(duì)于復(fù)雜的同步關(guān)系，鎖的使用會(huì)比較復(fù)雜。如果使用不當(dāng)很容易造成鎖的死鎖。從等待的角度來(lái)說(shuō)，鎖的死鎖是由于參與線程等待鎖的釋放，而這種等待構(gòu)成了等待循環(huán)，如 ABBA 死鎖：

圖2：兩線程ABBA死鎖

其中，線程中的黑色箭頭代表線程當(dāng)前執(zhí)行語(yǔ)句，紅色箭頭表示線程語(yǔ)句之間的等待關(guān)系。可以看到，紅色箭頭構(gòu)成了一個(gè)圓圈（或者循環(huán)）。再一次回顧潛在死鎖和死鎖實(shí)例，如果這兩個(gè)線程執(zhí)行的時(shí)間稍有改變，那么很有可能不會(huì)發(fā)生死鎖實(shí)例，比如如果讓 Thread1 執(zhí)行完這一段代碼 Thread2 才開(kāi)始執(zhí)行。但是這樣的用鎖行為（Locking Behavior）毫無(wú)疑問(wèn)是一個(gè)潛在死鎖。

進(jìn)一步可以看出，如果我們能夠追蹤并分析程序的用鎖行為就有可能預(yù)測(cè)死鎖或者找出潛在死鎖，而不是等死鎖發(fā)生時(shí)才能檢測(cè)出死鎖實(shí)例。Linux 內(nèi)核的 Lockdep 工具就是去刻畫(huà)內(nèi)核的用鎖行為進(jìn)而預(yù)測(cè)潛在死鎖并報(bào)告出來(lái)。

Lockdep 能夠刻畫(huà)出一類(lèi)鎖（Lock Class）的行為，主要是通過(guò)記錄一類(lèi)鎖中所有鎖實(shí)例的加鎖順序（Locking Order），即如果一個(gè)線程拿著鎖A，在沒(méi)有釋放前又去拿鎖B，那么鎖A和鎖B就有一個(gè) A->B 的加鎖順序，在 Lockdep 中這個(gè)加鎖順序被稱(chēng)為：鎖依賴(lài) （Lock Dependency）。同樣的，對(duì)于 ABBA 類(lèi)型的死鎖，我們并不需要 Thread1 和 Thread2 恰好產(chǎn)生一個(gè)死鎖實(shí)例，只要有線程產(chǎn)生了 A->B 加鎖順序行為，又有線程產(chǎn)生了一個(gè) B->A 的加鎖順序行為，那么這就構(gòu)成了一個(gè)潛在死鎖，如下圖所示：

圖3：線程ABBA加鎖順序

由此推廣開(kāi)來(lái)，我們可以把所有的加鎖順序（即鎖依賴(lài)）記錄和保存下來(lái)，構(gòu)成一個(gè)加鎖順序圖（Graph）。其中，如果有鎖依賴(lài) A->B ，又有鎖依賴(lài) B->C ，那么由于鎖依賴(lài)的關(guān)系（Relation）是傳遞的（Transitive），因此我們還可以得到鎖依賴(lài) A->C 。A->B 和 B->C 稱(chēng)為直接依賴(lài)（Direct Dependency），而 A->C 稱(chēng)為間接依賴(lài)（Indirect Dependency）。對(duì)于每一個(gè)新的直接鎖依賴(lài)，我們?nèi)z查這個(gè)依賴(lài)是否和圖中已經(jīng)存在的鎖依賴(lài)構(gòu)成一個(gè)循環(huán)，如果是的話，那么我們就可以預(yù)測(cè)產(chǎn)生了一個(gè)潛在死鎖。

三、讀寫(xiě)鎖（Read-write Lock）

剛才我們所指的鎖都是互斥鎖（Exclusive Lock）。讀寫(xiě)鎖是一種更復(fù)雜的鎖，或者說(shuō)一種通用的鎖（General Lock），我們可以認(rèn)為互斥鎖是只用寫(xiě)鎖的讀寫(xiě)鎖。只要沒(méi)有寫(xiě)鎖或者寫(xiě)鎖的爭(zhēng)搶?zhuān)x鎖允許讀者（Reader）同時(shí)持有。

Linux 內(nèi)核中有多種讀寫(xiě)鎖，主要包括：rwsem 、 rwlock 和 qrwlock 等。問(wèn)題是，讀寫(xiě)鎖會(huì)讓死鎖預(yù)測(cè)變得異常復(fù)雜， Lockdep 就不能支持這幾種讀寫(xiě)鎖，因此 Lockdep 在使用過(guò)程中會(huì)產(chǎn)生一些相關(guān)的錯(cuò)誤假陽(yáng)性（False Positive）死鎖預(yù)測(cè)和錯(cuò)誤假陰性（False Negative）死鎖預(yù)測(cè)。這個(gè)問(wèn)題已經(jīng)存在超過(guò)10年以上，我們提出一個(gè)通用的鎖的死鎖預(yù)測(cè)算法，并證明這個(gè)算法解決了讀寫(xiě)鎖的死鎖預(yù)測(cè)問(wèn)題。

四、通用鎖的死鎖預(yù)測(cè)算法（General Deadlock Prediction For Locks）

在描述這個(gè)算法的過(guò)程中，我們通過(guò)提出幾個(gè)引理（Lemma）來(lái)解釋或者證明我們所提出的死鎖預(yù)測(cè)的有效性。

▍引理1：在引入了讀寫(xiě)鎖后，鎖的加鎖順序循環(huán)是潛在死鎖的必要條件，但不是充分條件。并且，一個(gè)潛在死鎖能且只能最早在最后一個(gè)加鎖順序（或鎖依賴(lài)）即將生成死鎖循環(huán)的時(shí)候被預(yù)測(cè)出來(lái)。

基于引理1，解決死鎖預(yù)測(cè)問(wèn)題就是在最后一個(gè)拿鎖順序（即鎖依賴(lài)）形成等待圓環(huán)（循環(huán)）時(shí)，通過(guò)某種方法計(jì)算出這個(gè)等待圓環(huán)是否構(gòu)成潛在死鎖，而我們的任務(wù)就是找到這個(gè)方法（算法）。

▍引理2：兩個(gè)虛擬線程 T1 和 T2 可以用來(lái)表示所有的死鎖場(chǎng)景。

對(duì)于任何一個(gè)死鎖實(shí)例來(lái)說(shuō)，假定有 n 個(gè)線程參與到這個(gè)死鎖實(shí)例中，這 n 個(gè)線程表示為： 

1       T1,T2,…,Tn 

考慮 n 的情況：

•  如果 n=1：這種死鎖即線程自己等待自己，在 Lockdep 中被稱(chēng)為遞歸死鎖（Recursion Deadlock）。由于檢查這種死鎖較為簡(jiǎn)單，因此在下面的算法中忽略這種特殊情況。
•  如果 n>1：這種死鎖在 Lockdep 中被稱(chēng)為翻轉(zhuǎn)死鎖（Inversion Deadlock）。對(duì)于這種情況，我們將這 n 個(gè)線程分成兩組，即 T1,T2,…,Tn-1 和 Tn ，然后把前一組中的所有鎖依賴(lài)合并在一起并假想所有這些依賴(lài)存在于一個(gè)虛擬的線程中，于是得到兩個(gè)虛擬線程 T1 和 T2 。

這就是引理2中所述的兩個(gè)虛擬線程。基于引理2，我們提出一個(gè)死鎖檢查雙線程模型（Two-Thread Model）來(lái)表示內(nèi)核的加鎖行為：

•  T1 ：當(dāng)前檢查鎖依賴(lài)之前的所有鎖依賴(lài)，這些依賴(lài)形成了一個(gè)鎖依賴(lài)圖。
•  T2 ：當(dāng)前的待檢查的直接鎖依賴(lài)。

基于引理2和死鎖檢查雙線程模型，我們可以得到如下引理：

▍引理3：任何死鎖都可以轉(zhuǎn)化成 ABBA 類(lèi)型。

基于上述3個(gè)引理，我們可以進(jìn)一步將死鎖預(yù)測(cè)問(wèn)題描述為，當(dāng)我們得到一個(gè)新的直接鎖依賴(lài) B->A 時(shí)，我們將這個(gè)新依賴(lài)設(shè)想為 T2 ，而之前的所有鎖依賴(lài)都存在于一個(gè)設(shè)想的 T1 產(chǎn)生的一個(gè)鎖依賴(lài)圖中，于是死鎖預(yù)測(cè)就是檢查 T1 中是否存在 A->B 的鎖依賴(lài)，如果存在即存在死鎖，否則就沒(méi)有死鎖并將 T2 合并到 T1 中。如下圖所示：

圖4：T1的鎖依賴(lài)圖和T2的直接鎖依賴(lài)

在引入了讀寫(xiě)鎖之后，鎖依賴(lài)還取決于其中鎖的類(lèi)型，即讀或者寫(xiě)類(lèi)型。我們根據(jù) Linux 內(nèi)核中互斥鎖和讀寫(xiě)鎖的設(shè)計(jì)特性，引入一個(gè)鎖互斥表來(lái)表示鎖之間的互斥關(guān)系：

表1：讀寫(xiě)鎖互斥關(guān)系表

其中，遞歸讀鎖（Recursive-read Lock）是一種特殊的讀鎖，它能夠被同一個(gè)線程遞歸地拿。下面我們首先提出一個(gè)簡(jiǎn)單算法（Simple Algorithm）?；陔p線程模型，給定 T1 和 T2 ,和 ABBA 鎖：

圖5：基于雙線程模型的簡(jiǎn)單算法  

簡(jiǎn)單算法的步驟如下：

• 如果 X1.A 和 X1.B 是互斥的且 X2.A 和 X2.B 是互斥的，那么 T1 和 T2 構(gòu)成潛在死鎖。
•  否則， T1 和 T2 不構(gòu)成潛在死鎖。

從簡(jiǎn)單算法中可以看出，鎖類(lèi)型決定了鎖之間的互斥關(guān)系，而互斥關(guān)系是檢查死鎖的關(guān)鍵信息。對(duì)于讀寫(xiě)鎖來(lái)說(shuō)，鎖類(lèi)型可能在程序執(zhí)行過(guò)程中變化，那么如何記錄所有的鎖類(lèi)型呢？我們基于鎖類(lèi)型的互斥性，即鎖類(lèi)型的互斥性由低到高：遞歸讀鎖 < 讀鎖 < 寫(xiě)鎖（互斥鎖），提出了鎖類(lèi)型的升級(jí)（Lock Type Promotion）。在程序執(zhí)行過(guò)程中，如果碰到了高互斥性的鎖類(lèi)型，那么我們將鎖依賴(lài)中的鎖類(lèi)型升級(jí)到高互斥性的鎖依賴(lài)。鎖類(lèi)型升級(jí)如圖所示：

圖6：鎖類(lèi)型的升級(jí)

其中 RRn 表示遞歸讀鎖n（Recursive-read Lock n） ，Rn表示讀鎖n（Read Lock n），Wn代表寫(xiě)鎖或者互斥鎖n（Write Lock n）。下面 Xn 則表示任意鎖n （即遞歸讀、讀或者寫(xiě)鎖）。

但是，如上簡(jiǎn)單算法并不能處理所有的死鎖預(yù)測(cè)情況，比如下面這個(gè)案例就會(huì)躲過(guò)簡(jiǎn)單算法，但事實(shí)上它是一個(gè)潛在死鎖：

圖7：簡(jiǎn)單算法失敗案例

在這個(gè)案例中， X1 和 X3 是互斥的從而這個(gè)案例構(gòu)成了潛在死鎖。但是簡(jiǎn)單算法在檢查 RR2->X1 時(shí)（即 T2 為 RR2->X1 ），根據(jù)簡(jiǎn)單算法能夠找到 T1 中有 X1->RR2 ，但是由于 RR 和 RR 不具有互斥性，因而錯(cuò)誤認(rèn)定這個(gè)案例不是死鎖。分析這個(gè)案例為什么得出錯(cuò)誤結(jié)論，是因?yàn)檎嬲乃梨i X1X3X3X1 中的 X3->X1 是間接鎖依賴(lài)，而間接依賴(lài)被簡(jiǎn)單算法漏掉了。

這個(gè)問(wèn)題的更深層次原因是因?yàn)榛コ怄i之間只有互斥性，因此只要有 ABBA 就是潛在死鎖，并不需要檢查 T2 的間接鎖依賴(lài)。而在有讀鎖的情況下，這一條件不復(fù)存在，因此就要去考慮 T2 中的間接鎖依賴(lài)。

▍引理4：對(duì)于直接鎖依賴(lài)引入的間接鎖依賴(lài)，如果間接鎖依賴(lài)構(gòu)成死鎖，那么直接鎖依賴(lài)仍然是關(guān)鍵的。

引理4是引理1的引申，根據(jù)引理1，這個(gè)直接鎖依賴(lài)一定是形成鎖循環(huán)的那個(gè)最后鎖依賴(lài)，而引理4說(shuō)明通過(guò)這個(gè)鎖依賴(lài)一定可以通過(guò)某種方法判斷出鎖循環(huán)是否是潛在死鎖。換句話說(shuō)，通過(guò)修改和加強(qiáng)之前提出的簡(jiǎn)單算法，新的算法一定能夠解決這個(gè)問(wèn)題。但是問(wèn)題是，原先 T2 中直接鎖依賴(lài)可能進(jìn)一步生成了很多間接鎖依賴(lài)，我們?nèi)绾尾拍苷业侥莻€(gè)最終產(chǎn)生潛在死鎖的間接鎖依賴(lài)呢？更進(jìn)一步，我們首先需要重新定義 T2 ，再在這個(gè) T2 中找出所有的間接鎖依賴(lài)，那么 T2 的邊界是什么？如果把 T2 擴(kuò)展到整個(gè)鎖依賴(lài)圖，那么算法復(fù)雜度會(huì)提高非常多，甚至可能超出 Lockdep 的處理能力，讓 Lockdep 變得實(shí)際上不可用。

▍引理5：T2 只需要擴(kuò)展到當(dāng)前線程的拿鎖棧（Lock Stack）。

根據(jù)引理5，我們首先修改之前提出的雙線程模型為：

•  T1：當(dāng)前檢查直接鎖依賴(lài)之前的所有鎖依賴(lài)，這些依賴(lài)形成了一個(gè)圖。
•  T2：當(dāng)前的待檢查的線程的鎖棧。

根據(jù)引理5和新的雙線程模型，我們?cè)诤?jiǎn)單算法的基礎(chǔ)上提出如下最終算法（Final Algorithm）：

•  繼續(xù)搜索鎖依賴(lài)圖即 T1 尋找一個(gè)新的鎖依賴(lài)循環(huán)。
•  在這個(gè)新的循環(huán)中，如果有 T2 中的其他鎖存在，那么這個(gè)鎖和 T2 中的直接鎖依賴(lài)構(gòu)成一個(gè)間接鎖依賴(lài)，檢查這個(gè)間接鎖依賴(lài)是否構(gòu)成潛在死鎖。
•  如果找到潛在死鎖，那么算法結(jié)束，如果沒(méi)有到算法轉(zhuǎn)到1直到搜索完整個(gè)鎖依賴(lài)圖為止。

這個(gè)最終算法能解決之前出現(xiàn)漏洞的案例嗎？答案是可以的，具體檢查過(guò)程如圖所示：

圖8：簡(jiǎn)單算法的失敗案例解決過(guò)程

然而，對(duì)于所有其他情況，引理5是正確的嗎？為什么最終算法能夠工作呢？我們通過(guò)如下兩個(gè)引理來(lái)證明最終算法中的間接鎖依賴(lài)是必要且充分的。

▍引理6：檢查 T2 當(dāng)中的間接鎖依賴(lài)是必要的，否則簡(jiǎn)單算法已經(jīng)解決了所有問(wèn)題。

引理6說(shuō)明由于讀寫(xiě)鎖的存在，不能只檢查直接鎖依賴(lài)。

▍引理7：T2 的邊界就是當(dāng)前線程的鎖棧，這是充分的。

根據(jù)引理2和引理3，任何死鎖都可以轉(zhuǎn)化成雙線程 ABBA 死鎖，并且 T1 只能貢獻(xiàn) AB，T2 必須貢獻(xiàn) BA 。在這里，T2 不僅僅是一個(gè)虛擬線程，也是一個(gè)實(shí)際存在的物理線程，因此 T2 需要且只需要檢查當(dāng)前線程。

到這里，一個(gè)通用的讀寫(xiě)鎖死鎖預(yù)測(cè)算法就描述并非正式證明完畢。這個(gè)算法已經(jīng)實(shí)現(xiàn)在 Lockdep 中并提交給 Linux 內(nèi)存社區(qū)去審閱（當(dāng)前最新版本見(jiàn)https://lkml.org/lkml/2019/8/29/167）。鑒于相關(guān)性和篇幅所限，算法當(dāng)中的一些關(guān)鍵細(xì)節(jié)并沒(méi)有全部展現(xiàn)在這里，有興趣的讀者可以去上面的鏈接查找，同時(shí)歡迎提出評(píng)審意見(jiàn)和建議。

回顧從最初處理滴滴基礎(chǔ)平臺(tái)大集群集中爆發(fā)的幾個(gè)嚴(yán)重系統(tǒng)故障，到學(xué)習(xí)研究?jī)?nèi)核死鎖預(yù)測(cè)工具，再到設(shè)計(jì)和實(shí)現(xiàn)新的通用的讀寫(xiě)鎖死鎖預(yù)測(cè)算法。其中充滿了不確定性甚至戲劇性，但整個(gè)過(guò)程以及最后的結(jié)果都讓我收獲滿滿。

我想，這個(gè)經(jīng)歷正像電影《阿甘正傳》里的阿甘跑步一樣：跑到了一個(gè)目的地，就想再多跑一點(diǎn)，到了下一個(gè)目的地，又去設(shè)定一個(gè)新的更遠(yuǎn)的目標(biāo)。我也想，普通的工作和世界級(jí)的工作的區(qū)別并不在于起點(diǎn)，而在于終點(diǎn)，在于是否多跑了幾個(gè)更遠(yuǎn)的目標(biāo)吧。