“大菜”:源於自己剛踏入猿途混沌時起,自我感覺不是一般的菜,因而得名“大菜”,於自身共勉。 擴展閱讀: "深入理解值類型和引用類型" 基本概念 string(嚴格來說應該是System.String) 類型是我們日常coding中用的最多的類型之一。那什麼是String呢?^ ~ ^ String是 ...
“大菜”:源於自己剛踏入猿途混沌時起,自我感覺不是一般的菜,因而得名“大菜”,於自身共勉。
擴展閱讀:深入理解值類型和引用類型
基本概念
string(嚴格來說應該是System.String) 類型是我們日常coding中用的最多的類型之一。那什麼是String呢?^ ~ ^
String是一個不可變的連續16位的Unicode代碼值的集合,它直接派生自System.Object類型。
與之對應的還有一個不常用的安全字元串類型System.Security.SecureString,它會在非托管的記憶體上分配,以便避開GC的黑手。主要用於安全性特高的場景。[具體可查看msdn這裡不展開討論了。=>msdn查看詳情
特性
- 由於String類型直接派生於Object,所以它是引用類型,那就意味著String對象的實例總是存在於堆上。
- String具有不變性,也就是說一旦初始化,它的值將永遠不變。
- String類型是封閉的,換言之,你的任何類型不能繼承String。
- 定義字元串實例的關鍵字string只是System.String 類型的一個映射。
註意事項
- 關於字元串中的回車符和換行符一般大家喜歡直接硬編碼‘\r\n’,但是不建議這麼做,一旦程式遷移到其他平臺,將出現錯誤。相反,推薦使用System.Environment類的NewLine屬性來生成回車符和換行符,可以跨平臺使用的。
常量字元串的拼接和非常量字元串在CLR中行為是不一樣的。具體請查看性能部分。
- 字元串之前加@符號會改變編譯器的行為,如果加了@符號,編譯器會把String中的轉義字元視為正常字元來顯示。也就是我定義的什麼內容就是什麼內容,主要在使用文件路徑或者目錄字元串中使用。以下兩個String內容的輸出將完全一致。
static void Main(string[] args)
{
string a = "c:\\temp\\1";
string b = @"c:\temp\1";
Console.WriteLine(a);
Console.WriteLine(b);
Console.Read();
}
性能
- c#的編譯器直接支持String類型,並將定義的常量字元串在編譯期直接存放到模塊的元數據中。然後會在運行時直接載入。這也說明String類型的常量在運行時是有特殊待遇的。
- 由於字元串的不變性,也就意味著多個線程同時操作該字元串不會有任何線程安全的問題。這在某些共用配置的設計中很有用。
- 如果程式經常會對比重覆度比較高的字元串,這會造成性能上的影響,因為對比字元串是要經過幾個步驟的。為此CLR引入了一個字元串重用的技術,學名叫做‘字元串留用’。原理就是:CLR會在初始化的時候創建一個內部的哈希表,key是字元串,value就是留用字元串在托管堆上的引用。
String類型提供了兩個靜態方法來操作這個哈希表:
String.Intern
String.IsInterned
具體請查看msdn(https://msdn.microsoft.com/zh-cn/library/system.string.isinterned(v=vs.110).aspx)
但是c#編譯器預設是不開啟字元串留用功能的,因為如果程式大量把字元串留用,應用程式總體性能可能會變得更慢。(微軟也是挺糾結的,程式員TMD的更糾結)
- 如果我們的程式中有很多個一模一樣值的常量字元串, c#的編譯器會在編譯期間把這些字元串合併為一個並寫入模塊的元數據中,然後修改所有引用該字元串的代碼。這也是一種字元串重用技術,學名‘字元串池’。這意味著什麼呢?這意味著所有值相同的常量字元串其實引用的是同一個記憶體地址的實例,在相同值非常多的情況下能顯著提高性能和節省大量記憶體。
string s1 = "hello 大菜";
string s2 = "hello 大菜";
unsafe
{
ixed (char* p = s1)
{
Console.WriteLine("字元串地址= 0x{0:x}", (int)p);
}
fixed (char* p = s2)
{
Console.WriteLine("字元串地址= 0x{0:x}", (int)p);
}
}
輸出結果:
字元串地址= 0x80002d84
字元串地址= 0x80002d84
可見實例的值只分配了一次,但是有一點需要說明,字元串僅用於編譯期能確定值的字元串,也就是常量字元串。如果我的程式修改為:
args = new string[] { "dfasfdsa"};
string s1 = "hello 大菜"+ args[0];
string s2 = "hello 大菜"+args[0];
unsafe
{
fixed (char* p = s1)
{
Console.WriteLine("字元串地址= 0x{0:x}", (int)p);
}
fixed (char* p = s2)
{
Console.WriteLine("字元串地址= 0x{0:x}", (int)p);
}
}
運行結果:
字元串地址= 0x2e3c
字元串地址= 0x2e7c
- 平時coding避免不了字元串的連接,如果一個頻繁拼接字元串的場景下使用‘+’,對程式整體性能和GC影響還是挺大的,為此c#推出了 StringBuilder類型來優化字元串的拼接。相對於String類型的不變性來說,StringBuilder更像是可變的字元串類型。它的底層數據結構是一個Char的數組。另外還有容量(預設為16),最大容量(預設為int.MaxValue)等屬性。StringBuilder的優勢在於字元總數未超過‘容量’的時候,底層數組不會重新分配,這和String每次都重新分配形成最大的對比。如果字元總數超過‘容量’,StringBuilder會自動倍增容量屬性,用一個新的數組來容納原來的值,原來數組將會被GC回收。可見如果StringBuilder頻繁的動態擴容也會損害性能,但是影響可能會比String小的多。 合理的設置StringBuilder初始容量對程式有很大幫助。測試如下:
int count = 100000;
Stopwatch sw = new Stopwatch();
sw.Start();
string s = "";
for (int i = 0; i < count; i++)
{
s += i.ToString();
}
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds);
運行結果:
14221
查看GC的情況
Gc執行的是如此頻繁。 性能是可想而知的。接著看一下StringBuilder
int count = 100000;
Stopwatch sw = new Stopwatch();
sw.Start();
StringBuilder sb = new StringBuilder();//聽說程式員都這樣命名StringBuilder
for (int i = 0; i < count; i++)
{
sb.Append(i.ToString());
}
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds);
運行結果:
12
GC情況:
幾乎沒有GC(可能還未達到觸發GC的臨界點),如果我合理初始化了StringBuilder 容量,生產環境中結果差距將會更大。 呵呵 ^ ~ ^
其他
關於字元串留用和字元串池
- 一個程式集載入的時候,CLR預設會留用該程式集元數據中描述的所有文本常量字元串。由於可能會出現額外的哈希表查找造成的性能下降的現象,所以現在可以禁用這個特性了。
- coding中我們平常比較兩個字元串是否相等,那這個過程是怎麼樣的呢?
- 首先判斷字元的數量是否相等。
- CLR逐個對比字元最終確定是否相等。
這個場景是適合字元串留用的。因為不再需要經過以上的兩個步驟,直接哈希表拿到value就可以對比確定了。
關於字元串拼接性能
基於以上所有知識,那是不是StringBuilder拼接字元串性能永遠都高於符號‘+’呢?答案是否定的。
static void Main(string[] args)
{
int count = 10000000;
Stopwatch sw = new Stopwatch();
sw.Start();
string str1 = "str1", str2 = "str2", str3 = "str3";
for (int i = 0; i < count; i++)
{
string s = str1 + str2 + str3;
}
sw.Stop();
Console.WriteLine($@"+用時: {sw.ElapsedMilliseconds}" );
sw.Reset();
sw.Start();
for (int i = 0; i < count; i++)
{
StringBuilder sb = new StringBuilder();//聽說程式員都這樣命名StringBuilder
sb.Append(str1).Append(str2).Append(str3);
}
sw.Stop();
Console.WriteLine($@"StringBuilder.Append 用時: {sw.ElapsedMilliseconds}");
Console.Read();
}
運行結果:
+用時: 553
StringBuilder.Append 用時: 975
符號‘+’最終會調用String.Concat方法,當同時連接幾個字元串時,並不是每連接一個都分配一次記憶體,而是把幾個字元都作為 String.Concat方法的參數,只分配一次記憶體。所以在拼接的字元串個數比較少的場景下,String.Concat 性能是略高於StringBuilder.Append。string.Format 方法最終調用的是StringBuilder,這裡不做展開討論了,請自行參考其他文檔。
所以萬事都不是絕對的!!每個事物都有適合自己的場景,我們都需要自己去探索。(程式員太累了)
以上都是非生產環境測試結果,如果錯誤,請及時指正
請尊重一個猿的辛苦,轉載請標明出處 ^ ~ ^ 。部分圖片來源於網路,如有侵權請及時聯繫。讓我們一起進步吧
一個不止於IT圈內容的微信公眾號,歡迎關註,交流更多的IT知識。不定時會有驚喜奧 ^ ~ ^