[[420501]]

大家好，我是梁唐。

相信大家應該都學過C語言或者是C++，C/C++當中令初學者比較頭疼的可能就是指針了。畢竟用起來賊麻煩，要new來new去，用完了還得delete，一不小心就燙燙燙燙燙燙了。

我們今天不講指針的這些技術細節，只聊一個問題，為什么設計者會設計出這么一個東西，難道不知道它很難用嗎?

一

吐槽誰都會，但是吐槽完了還能去琢磨一下的，這就體現出差距了。

對于今天增刪改查明天改查增刪的程序員們來說，的確是沒有使用指針的必要。我只要能從數據庫里讀取、寫入數據就行，為什么非得用指針?

但是如果大家寫過一些數據結構，尤其是一些相對比較復雜的數據結構立馬就能感受到指針的香味。

我隨便在網上找了一段SBT的代碼片段，給大家演示一下：

void maintain(node *&o,bool d){ 
    if(o->ch[d]->ch[d]->s>o->ch[!d]->s){ 
        rotate(o,!d); 
    }else if(o->ch[d]->ch[!d]->s>o->ch[!d]->s){ 
        rotate(o->ch[d],d); 
        rotate(o,!d); 
    }else return; 
    maintain(o->ch[1],1); 
    maintain(o->ch[0],0); 
    maintain(o,1); 
    maintain(o,0); 
} 

這段邏輯是用來維護二叉樹的平衡的，也就是用來進行各種各樣的旋轉操作。代碼邏輯看不懂沒有關系，我們只要看下當中函數調用的部分，都是把一個孩子節點的指針丟進函數里去就結束了。

如果函數傳遞的不是指針的話，這段邏輯還成立嗎?

顯然就不成立了，因為函數傳遞參數是值傳遞，傳入進去的值都會生成一個拷貝。我們在函數內部無論如何修改，也不會影響函數外的結果。

我之前用Python寫過一次，因為Python當中沒有指針。同樣的數據結構就沒這么方便，想要將一個節點替換成另外一個，需要先追溯到它的父節點，然后對它的父節點當中的內容進行修改。

再比如有了指針之后，我們可以實現動態分配內存。不僅如此，我們還可以直接操作內存地址，完成一些匯編語言才能實現的高端操作。

所以指針這個設計雖然會導致各種各樣的問題，學習成本也不低，但肯定不是一無是處的。許多語言閹割掉了指針功能，雖然在一些問題和場景當中編碼舒服了很多，但也遇到了很多其他的問題。

其中最大的問題就是內存管理的問題。

二

C/C++當中內存管理幾乎都是由程序員來執行的，我們要使用一塊內存的時候，就通過new/malloc來創建一個變量或者是數組，用完了之后就通過free或者是delete將它銷毀。

這種做法的好處是程序員擁有最高的執行權限，我們可以自由控制內存的使用與銷毀。像是Java、Python等語言，內存管理都是交給底層程序來控制的，我們在一塊內存使用結束之后，無法確定它會在什么時候釋放。

相比于交給程序去執行，由程序員執行內存管理本身并不是很糟糕的方案。畢竟程序是死的，總有一些特殊case處理不好。而人為處理，靈活性大大增加。

但遺憾的是，大部分情況下人比程序更加不靠譜，人工控制內存的問題明面上很好，但是隱患非常大，經常出現意外情況。

舉幾個例子，比如最常見的new了一塊內存忘記了delete，或者是還沒有delete就修改了指針，這樣就會導致有一塊內存申請好了放在那里，但是沒有任何一個指針指向它，除非程序結束，再也無法釋放。這也就是常說的內存泄漏。

除了程序員馬虎忘記了delete之外，有時候一些意想不到的錯誤也會導致內存泄漏。另外一個很常見的情況如下：

Node node = new Node(); 
dosomething(); 
delete node; 

很有可能我們在執行something的時候，報錯了，然后異常拋出，導致delete的操作被跳過了。

除了內存泄漏之外，還有可能出現反向出問題的情況。比如一個指針，我們還沒用完，下游某個地方還在使用，突然上游delete了，于是引發報錯。更要命的時候，有些古老項目好幾百萬行，都不知道這個指針中間經歷了什么，也沒辦法追溯它被delete的地方，有可能這整個鏈路上的邏輯異常復雜，導致你根本無力修改，只能特判這種情況，如果出現了就重新new一個，于是又增加了一個內存泄漏的隱患。

由程序員掌管內存的管理大權本身并沒有什么問題，但問題是不是每一個工程師每時每刻都是諸葛亮，能夠理解項目當中的每一個細節。尤其是當這個項目無比龐大了之后，動輒幾百萬行代碼的項目，也根本超過了人類能夠理解的極限。

最后的結果就是雜草叢生，問題無數，甚至工程師們無力解決已有的問題，只能往上添加更多的問題。

那把內存管理權限交給程序是否就高枕無憂了呢?

三

把內存完全交給程序管理，這就相當于從一個極端走向了另外一個極端。從完全人工控制走向了人工完全控制不了，其實也很有很多問題。

表面上減輕了程序員們的負擔，甚至對于很多初學者來說完全沒有意識到內存管理這個問題，就天然地以為這是編譯器/解釋器理所應當的天職。沒有什么是理所應當的，當你以為理所應當的時候，往往就是問題產生的開始。

雖然各個語言的內存管理策略不盡相同，但往往大同小異，以其中比較典型的Java距離，做個介紹。

我們可以把Java中的內存看成幾個桶，簡化一下大概是四個桶。嚴格來說還有程序計數器、虛擬機棧、本地方法棧等內容，但是不太重要，就不一一列舉了。

把這四個桶的原理理解了，基本上就能對Java內存管理做到一知半解了。先說方法區，顧名思義就是存儲方法的地方。方法也就是我們開發程序的時候寫的函數，只不過在Java當中統一稱為方法，因為Java當中一切都是類，所有的函數都是某一個類的方法。

方法區的內容是存儲在棧當中的，棧當中空間比較小一般存儲一些程序執行時的上下文信息。比如當前方法調用棧信息，本地、虛擬機中的棧信息等等。

方法區當中的內存比較小，存儲的東西也比較少，因此很少需要清理，只會在終極清理機制——full GC的時候清理。除了方法區之外的部分都是堆內存。

接著是新生代和老生代，新生代是兩個空間大小相同的內存區域。當我們new一個新的實例的時候，開辟的內存其實就是新生代當中的內存。為什么新生代當中會有兩個區域1和2呢?這是因為為了方便進行minor GC。

新生代當中必然有一個桶是空的，我們假設1是當前使用的，2是空閑的。當1內存滿了之后，會觸發minor GC。虛擬機會把1桶當中的內容一個一個按順序倒出來，檢查是否還在使用，如果還在使用就存入2當中，如果沒在使用就丟棄。這樣雖然空閑了一塊區域，但是可以保證新生代當中的內存是連續的，保證了內存的利用率。

當一個實例經過好幾次minor GC還沒有被清理之后，就說明它活得可能會比較久，所以要移入老生代當中。老生代當中存儲的都是這種經過了好幾次GC還沒被清理的老家伙。老家伙們活得很久， 而且往往占據的內存也比較大，所以針對這塊內存設計了新的回收策略，即major GC。

由于老生代只有一塊，所以我們沒辦法像是新生代一樣按照順序來回倒騰，只能一次性處理。這里采取的策略叫做CMS算法，其實就是標記回收算法。算法會根據這些老家伙的使用情況，給它們打上標簽，看看哪些還在使用不能清理，哪些是已經沒用的，可以干掉了。標簽打完之后，會對這塊內存整個清理，重新分配內存空間，保證清理之后的內存也是連續的。

當然由于這當中需要打標簽，還需要移動內存分片，因此消耗的時間會比較久。內存分為新生代和老生代的策略也是盡量避免進行這樣比較耗時的回收策略。

當進行full GC，也就是所有內存區域一同清理的時候會觸發虛擬機stop the world，顧名思義也就是停止一切響應，埋頭清理內存。這個時候會導致服務不可用，這也是Java的一大詬病之一，但這也是GC機制導致的。只能根據實際需要以及GC機制進行優化，降低頻率，幾乎不能根除。

也正是因為內存管理策略比較復雜，所以如果對內存這塊沒有深入的了解的話，很容易導致一些問題。比如頻繁觸發GC，導致系統經常無法響應。或者是干脆內存使用不合理，導致經常會出現內存溢出的情況，直接OOM崩潰。很多服務剛上線的時候運行得好好的，過了一段時間突然崩了，往往十有八九都是內存管理沒過關。

所以很多被內存回收折騰得頭疼的工程師又會懷念當年C++指針控制內存的方便，想用就用，想釋放就釋放，根本不用看虛擬機的臉色。但反過來C++那邊也在覺得自動回收機制寫代碼方便，是歷史潮流，所以新版的C++當中也開發了類似可智能回收指針這樣的特性。

兩邊都在掙扎，其實類似的情況在代碼設計當中非常非常常見，程序里永遠沒有完美，只有現實和妥協。

好了，關于指針就聊到這里，希望大家喜歡。