標準C＋＋類std::string的

記憶體共享和Copy-On-Write技術

1、概念

Scott Meyers在《More Effective C++》中舉了個例子，不知你是否還記得？在你還在上學的時候，你的父母要你不要看電視，而去複習功課，於是你把自己關在房間裡，做出一副正在複習功課的樣子，其實你在幹著別的諸如給班上的某位女生寫情書之類的事，而一旦你的父母出來在你房間要檢查你是否在複習時，你才真正撿起課本看書。這就是“拖延戰術”，直到你非要做的時候才去做。

當然，這種事情在現實生活中時往往會出事，但其在程式設計世界中搖身一變，就成為了最有用的技術，正如C++中的可以隨處宣告變數的特點一樣，Scott Meyers推薦我們，在真正需要一個儲存空間時才去宣告變數（分配記憶體），這樣會得到程式在執行時最小的記憶體花銷。執行到那才會去做分配記憶體這種比較耗時的工作，這會給我們的程式在執行時有比較好的效能。必竟，20%的程式執行了80%的時間。

當然，拖延戰術還並不只是這樣一種型別，這種技術被我們廣泛地應用著，特別是在作業系統當中，當一個程式執行結束時，作業系統並不會急著把其清除出記憶體，原因是有可能程式還會馬上再執行一次（從磁碟把程式裝入到記憶體是個很慢的過程），而只有當記憶體不夠用了，才會把這些還駐留記憶體的程式清出。

寫時才複製（Copy-On-Write）技術，就是程式設計界“懶惰行為”——拖延戰術的產物。舉個例子，比如我們有個程式要寫檔案，不斷地根據網路傳來的資料寫，如果每一次fwrite或是fprintf都要進行一個磁碟的I/O操作的話，都簡直就是效能上巨大的損失，因此通常的做法是，每次寫檔案操作都寫在特定大小的一塊記憶體中（磁碟快取），只有當我們關閉檔案時，才寫到磁碟上（這就是為什麼如果檔案不關閉，所寫的東西會丟失的原因）。更有甚者是檔案關閉時都不寫磁碟，而一直等到關機或是記憶體不夠時才寫磁碟，Unix就是這樣一個系統，如果非正常退出，那麼資料就會丟失，檔案就會損壞。

呵呵，為了效能我們需要冒這樣大的風險，還好我們的程式是不會忙得忘了還有一塊資料需要寫到磁碟上的，所以這種做法，還是很有必要的。

2、標準C++類std::string的Copy-On-Write

在我們經常使用的STL標準模板庫中的string類，也是一個具有寫時才複製技術的類。C++曾在效能問題上被廣泛地質疑和指責過，為了提高效能，STL中的許多類都採用了Copy-On-Write技術。這種偷懶的行為的確使使用STL的程式有著比較高要效能。

這裡，我想從C++類或是設計模式的角度為各位揭開Copy-On-Write技術在string中實現的面紗，以供各位在用C++進行類庫設計時做一點參考。

在講述這項技術之前，我想簡單地說明一下string類記憶體分配的概念。透過常，string類中必有一個私有成員，其是一個char*，使用者記錄從堆上分配記憶體的地址，其在構造時分配記憶體，在析構時釋放記憶體。因為是從堆上分配記憶體，所以string類在維護這塊記憶體上是格外小心的，string類在返回這塊記憶體地址時，只返回const char*，也就是隻讀的，如果你要寫，你只能透過string提供的方法進行資料的改寫。

2.1、特性

由表及裡，由感性到理性，我們先來看一看string類的Copy-On-Write的表面特徵。讓我們寫下下面的一段程式：

#include

using namespace std;

main()

{

string str1 = "hello world";

string str2 = str1;

printf ("Sharing the memory:n");

printf ("tstr1's address: %xn", str1.c_str() );

printf ("tstr2's address: %xn", str2.c_str() );

str1[1]='q';

str2[1]='w';

printf ("After Copy-On-Write:n");

printf ("tstr1's address: %xn", str1.c_str() );

printf ("tstr2's address: %xn", str2.c_str() );

return 0;

}

這個程式的意圖就是讓第二個string透過第一個string構造，然後列印出其存放資料的記憶體地址，然後分別修改str1和str2的內容，再查一下其存放記憶體的地址。程式的輸出是這樣的（我在VC6.0和g++ 2.95都得到了同樣的結果）：

> g++ -o stringTest stringTest.cpp

> ./stringTest

Sharing the memory:

str1's address: 343be9

str2's address: 343be9

After Copy-On-Write:

str1's address: 3407a9

str2's address: 343be9

從結果中我們可以看到，在開始的兩個語句後，str1和str2存放資料的地址是一樣的，而在修改內容後，str1的地址發生了變化，而str2的地址還是原來的。從這個例子，我們可以看到string類的Copy-On-Write技術。

2.2、深入

在深入這前，透過上述的演示，我們應該知道在string類中，要實現寫時才複製，需要解決兩個問題，一個是記憶體共享，一個是Copy-On-Wirte，這兩個主題會讓我們產生許多疑問，還是讓我們帶著這樣幾個問題來學習吧：

1、 Copy-On-Write的原理是什麼？

2、 string類在什麼情況下才共享記憶體的？

3、 string類在什麼情況下觸發寫時才複製（Copy-On-Write）?

4、 Copy-On-Write時，發生了什麼？

5、 Copy-On-Write的具體實現是怎麼樣的？

喔，你說只要看一看STL中stirng的原始碼你就可以找到答案了。當然，當然，我也是參考了string的父模板類basic_string的原始碼。但是，如果你感到看STL的原始碼就好像看機器碼，並嚴重打擊你對C++自信心，乃至產生了自己是否懂C++的疑問，如果你有這樣的感覺，那麼還是繼續往下看我的這篇文章吧。

OK，讓我們一個問題一個問題地探討吧，慢慢地所有的技術細節都會浮出水面的。

2.3、 Copy-On-Write的原理是什麼？

有一定經驗的程式設計師一定知道，Copy-On-Write一定使用了“引用計數”，是的，必然有一個變數類似於RefCnt。當第一個類構造時，string的建構函式會根據傳入的引數從堆上分配記憶體，當有其它類需要這塊記憶體時，這個計數為自動累加，當有類析構時，這個計數會減一，直到最後一個類析構時，此時的RefCnt為1或是0，此時，程式才會真正的Free這塊從堆上分配的記憶體。

是的，引用計數就是string類中寫時才複製的原理！

不過，問題又來了，這個RefCnt該存在在哪裡呢？如果存放在string類中，那麼每個string的例項都有各自的一套，根本不能共有一個RefCnt，如果是宣告成全域性變數，或是靜態成員，那就是所有的string類共享一個了，這也不行，我們需要的是一個“民主和集中”的一個解決方法。這是如何做到的呢？呵呵，人生就是一個糊塗後去探知，知道後和又糊塗的迴圈過程。別急別急，在後面我會給你一一道來的。

2.3.1、 string類在什麼情況下才共享記憶體的？

這個問題的答案應該是明顯的，根據常理和邏輯，如果一個類要用另一個類的資料，那就可以共享被使用類的記憶體了。這是很合理的，如果你不用我的，那就不用共享，只有你使用我的，才發生共享。

使用別的類的資料時，無非有兩種情況，1）以別的類構造自己，2）以別的類賦值。第一種情況時會觸發複製建構函式，第二種情況會觸發賦值運算子。這兩種情況我們都可以在類中實現其對應的方法。對於第一種情況，只需要在string類的複製建構函式中做點處理，讓其引用計數累加；同樣，對於第二種情況，只需要過載string類的賦值運算子，同樣在其中加上一點處理。

嘮叨幾句：

1）構造和賦值的差別

對於前面那個例程中的這兩句：

string str1 = "hello world";

string str2 = str1;

不要以為有“=”就是賦值操作，其實，這兩條語句等價於：

string str1 ("hello world"); //呼叫的是建構函式

string str2 (str1); //呼叫的是複製建構函式

如果str2是下面的這樣情況：

string str2; //呼叫引數預設為空串的建構函式：string str2(“”);

str2 = str1; //呼叫str2的賦值操作：str2.operator=(str1);

2) 另一種情況

char tmp[]=”hello world”;

string str1 = tmp;

string str2 = tmp;

這種情況下會觸發記憶體的共享嗎？想當然的，應該要共享。可是根據我們前面所說的共享記憶體的情況，兩個string類的宣告和初始語句並不符合我前述的兩種情況，所以其並不發生記憶體共享。而且，C++現有特性也無法讓我們做到對這種情況進行類的記憶體共享。

2.3.2、 string類在什麼情況下觸發寫時才複製（Copy-On-Write）?

哦，什麼時候會發現寫時才複製？很顯然，當然是在共享同一塊記憶體的類發生內容改變時，才會發生Copy-On-Write。比如string類的[]、=、+=、+、運算子賦值，還有一些string類中諸如insert、replace、append等成員函式,包括類的析構時。

修改資料才會觸發Copy-On-Write，不修改當然就不會改啦。這就是託延戰術的真諦，非到要做的時候才去做。

2.3.3、 Copy-On-Write時，發生了什麼？

我們可能根據那個訪問計數來決定是否需要複製，參看下面的程式碼：

If ( RefCnt>0 ) {

char* tmp = (char*) malloc(strlen(_Ptr)+1);

strcpy(tmp, _Ptr);

_Ptr = tmp;

}

上面的程式碼是一個假想的複製方法，如果有別的類在引用（檢查引用計數來獲知）這塊記憶體，那麼就需要把更改類進行“複製”這個動作。

我們可以把這個拷的執行封裝成一個函式，供那些改變內容的成員函式使用。

2.3.4、 Copy-On-Write的具體實現是怎麼樣的？

最後的這個問題，我們主要解決的是那個“民主集中”的難題。請先看下面的程式碼：

string h1 = “hello”;

string h2= h1;

string h3;

h3 = h2;

string w1 = “world”;

string w2(“”);

w2=w1;

很明顯，我們要讓h1、h2、h3共享同一塊記憶體，讓w1、w2共享同一塊記憶體。因為，在h1、h2、h3中，我們要維護一個引用計數，在w1、w2中我們又要維護一個引用計數。

如何使用一個巧妙的方法產生這兩個引用計數呢？我們想到了string類的記憶體是在堆上動態分配的，既然共享記憶體的各個類指向的是同一個記憶體區，我們為什麼不在這塊區上多分配一點空間來存放這個引用計數呢？這樣一來，所有共享一塊記憶體區的類都有同樣的一個引用計數，而這個變數的地址既然是在共享區上的，那麼所有共享這塊記憶體的類都可以訪問到，也就知道這塊記憶體的引用者有多少了。

請看下圖：

於是，有了這樣一個機制，每當我們為string分配記憶體時，我們總是要多分配一個空間用來存放這個引用計數的值，只要發生複製構造可是賦值時，這個記憶體的值就會加一。而在內容修改時，string類為檢視這個引用計數是否為0，如果不為零，表示有人在共享這塊記憶體，那麼自己需要先做一份複製，然後把引用計數減去一，再把資料複製過來。下面的幾個程式片段說明了這兩個動作：

//建構函式（分存記憶體）

string::string(const char* tmp)

{

_Len = strlen(tmp);

_Ptr = new char[_Len+1+1];

strcpy( _Ptr, tmp );

_Ptr[_Len+1]=0; // 設定引用計數

}

//複製構造（共享記憶體）

string::string(const string& str)

{

if (*this != str){

this->_Ptr = str.c_str(); //共享記憶體

this->_Len = str.szie();

this->_Ptr[_Len+1] ++; //引用計數加一

}

//寫時才複製Copy-On-Write

char& string::operator[](unsigned int idx)

{

if (idx > _Len || _Ptr == 0 ) {

static char nullchar = 0;

return nullchar;

}

_Ptr[_Len+1]--; //引用計數減一

char* tmp = new char[_Len+1+1];

strncpy( tmp, _Ptr, _Len+1);

_Ptr = tmp;

_Ptr[_Len+1]=0; // 設定新的共享記憶體的引用計數

return _Ptr[idx];

}

//解構函式的一些處理

~string()

{

_Ptr[_Len+1]--; //引用計數減一

// 引用計數為0時，釋放記憶體

if (_Ptr[_Len+1]==0) {

delete[] _Ptr;
}

}

哈哈，整個技術細節完全浮出水面。

不過，這和STL中basic_string的實現細節還有一點點差別，在你開啟STL的原始碼時，你會發現其取引用計數是透過這樣的訪問：_Ptr[-1]，標準庫中，把這個引用計數的記憶體分配在了前面（我給出來的程式碼是把引用計數分配以了後面，這很不好），分配在前的好處是當string的長度擴充套件時，只需要在後面擴充套件其記憶體，而不需要移動引用計數的記憶體存放位置，這又節省了一點時間。

STL中的string的記憶體結構就像我前面畫的那個圖一樣，_Ptr指著是資料區，而RefCnt則在_Ptr-1 或是 _Ptr[-1]處。

2.4、臭蟲Bug

是誰說的“有太陽的地方就會有黑暗”？或許我們中的許多人都很迷信標準的東西，認為其是久經考驗，不可能出錯的。呵呵，千萬不要有這種迷信，因為任何設計再好，編碼再好的程式碼在某一特定的情況下都會有Bug，STL同樣如此，string類的這個共享記憶體/寫時才複製技術也不例外，而且這個Bug或許還會讓你的整個程式crash掉！