這篇文章主要為大家展示了“C#中使用CLR需要注意什么”，內(nèi)容簡(jiǎn)而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“C#中使用CLR需要注意什么”這篇文章吧。

創(chuàng)新互聯(lián)是一家專業(yè)提供衛(wèi)輝企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站制作、成都網(wǎng)站建設(shè)、HTML5、小程序制作等業(yè)務(wù)。10年已為衛(wèi)輝眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)的建站公司優(yōu)惠進(jìn)行中。

1、C# CLR之foreach的性能問題

foreach(string s in rows) { foo(s); }的實(shí)現(xiàn)是：

IEnumerator e = rows.GetEnumerator();  try {    string s;    while (e.MoveNext()) {      s = (String) e.Current;      foo(s);    }  }  finally {    IDisposable d = e as IDisposable;    if (d != null) d.Dispose();  }

每一步都調(diào)用了e.MoveNext()和e.Current兩個(gè)方法；而大多數(shù)時(shí)候，完全有可能優(yōu)化為一次調(diào)用。顯然這對(duì)性能是有影響的。雖然foreach對(duì)于數(shù)組作了單獨(dú)的優(yōu)化（編譯成for循環(huán)），但這還是值得注意的。

那么，怎么做比較快？

對(duì)于List等Collection，可以用ForEach(Actionaction)，F(xiàn)indAll(Predicatematch)，ConvertAll(Converterconverter)等方法。它們比較快，但不是所有實(shí)現(xiàn)IEnumerable的類都提供。

LINQ追求compatiblity，而不是performance。因此LINQ的實(shí)現(xiàn)完全采用了foreach。值得注意。

2、C# CLR之yield的實(shí)現(xiàn)原理

實(shí)現(xiàn)一個(gè)支持IEnumerable的對(duì)象時(shí)，一般會(huì)用到y(tǒng)ield關(guān)鍵字，這樣foreach遍歷這個(gè)對(duì)象時(shí)，可以做到lazy evaluation。例如：

class MyCollection: IEnumerable<char> {    private string s; ...    public IEnumerable<char> GetEnumerator() {      for (int i=0; i<s.Length; i++)    {        yield return s[i];      }   }  }

執(zhí)行到y(tǒng)ield時(shí)函數(shù)返回，下次調(diào)用時(shí)，接著上次運(yùn)行的位置繼續(xù)運(yùn)行。這個(gè)continuation的效果是怎么做的呢？

包含yield的函數(shù)都會(huì)被編譯器做成一個(gè)狀態(tài)機(jī)。每調(diào)一次，就接著上次的狀態(tài)繼續(xù)運(yùn)行。簡(jiǎn)單有效啊。我一直以為要有什么特殊的辦法呢。

3、C# CLR之exception handling的實(shí)現(xiàn)決定了throw的performance較差。

可以用Int32.TryParse代替try{Int32.Parse…}catch{…}，稍快一點(diǎn)。類似地建議使用Dictionary.TryGetValue。

4、C# CLR之.Net CLR執(zhí)行引擎對(duì)應(yīng)于MSCorWks.dll和MSCorEE.dll這兩個(gè)文件。

5、C# CLR之.Net 3.0, 3.5沒有對(duì)CLR作任何修改。

所有增加的東西（比如LINQ）都是syntactic sugar，只改了C#編譯器而已。

6、C# CLR之AppDomain

如果把.Net虛擬機(jī)看成一個(gè)虛擬操作系統(tǒng)，AppDomain的概念則類似于操作系統(tǒng)中的進(jìn)程。

可以用代碼創(chuàng)建一個(gè)AppDomain，然后動(dòng)態(tài)加載/卸載assembly，還可以設(shè)置權(quán)限，相當(dāng)于提供了一個(gè)沙箱。

跨AppDomain的調(diào)用類似于RPC。

調(diào)用某個(gè)AppDomain內(nèi)部的obj.foo(x)時(shí)，.net會(huì)自動(dòng)幫你做出一個(gè)proxy object，你所調(diào)用的obj其實(shí)是一個(gè)proxy object。傳給foo的參數(shù)x會(huì)先被被marshal，以保證AppDomain被安全隔離。

誰用AppDomain？SQL Server用這個(gè)技術(shù)實(shí)現(xiàn)managed存儲(chǔ)過程。IIS會(huì)把不同的Web Application放在不同的AppDomain里，以實(shí)現(xiàn)動(dòng)態(tài)裝卸。

7、C# CLR之動(dòng)態(tài)載入Assembly的陷阱

Sytem.Reflection.Assembly.LoadFrom(pathName)并不會(huì)載入pathName所指定的dll，而是看看pathName那個(gè)dll的名字、版本，然后到系統(tǒng)默認(rèn)位置去找。（陷阱?。?/p>

8、C# CLR之C#里用reflection創(chuàng)建一個(gè)新對(duì)象

用Activator.CreateInstance。（奇怪的名字啊。）

9、C# CLR之C#泛型之“where”

可以用“where”來限定T的接口。例如

static T min(T arg1, T arg2) where T: IComparable{…}

不寫where的話，就不能調(diào)arg1.CompareTo(arg2)。

為啥不把T換成IComparable？一是為保證arg1, arg2一定是同一個(gè)類型，二是泛型的效率更高。（JIT會(huì)為不同類型的T各生成一份native code，從而避免了boxing）

更多where的細(xì)節(jié)：

* 要想調(diào)T t1 = new T()，必須聲明where T: new()或者where T: struct

* 要寫T t2 = null，必須聲明where T: class

* T z = default(T)是一個(gè)特殊的用法，會(huì)把T的每個(gè)bit都置為0。

* 假設(shè)定義了Foo(T x, T y)，則if (x==null) … 是可以通過的，雖然C#中value type的值不允許為null（例如int a=null是錯(cuò)的）。這是因?yàn)?，此時(shí)的語義是一致的，反正if里面的操作不被執(zhí)行就是了，所以編譯器對(duì)這種特殊情況網(wǎng)開一面。

* if (x==y)不行，除非寫了where T: baseclass。（這里我也沒理解為啥。。。>_<好像說是不知道應(yīng)該用reference比較還是value比較？）

10、C# CLR之匿名函數(shù)的背后。。。

在C# 2.0以后可以用匿名的delegate，如ThreadPool.QueueWorkItem(delegate (Object obj) { Console.WriteLine(obj); })

但編譯器的實(shí)現(xiàn)會(huì)帶來一點(diǎn)點(diǎn)overhead，會(huì)生成一個(gè)小小的靜態(tài)WaitCallback對(duì)象，可以用Reflector看生成的代碼。（不要打開Reflector的optimization，否則就看不到了）

如果是自己寫的話，可以選擇每次動(dòng)態(tài)建立一個(gè)WaitCallback對(duì)象然后銷毀。當(dāng)然這樣做性能可能差一些，但這里的idea是：編譯器會(huì)自動(dòng)做一些事，但不一定是你所希望的。在使用這些高級(jí)feature前，最好先搞清楚背后發(fā)生了什么。

另一個(gè)細(xì)節(jié)：如果匿名函數(shù)中使用了外層函數(shù)的局部變量（即所謂的function closure），會(huì)導(dǎo)致創(chuàng)建額外的shared-state object，把用到的局部變量做成一個(gè)新對(duì)象傳給匿名函數(shù)。

上述描述同樣適用于lambda函數(shù)。因?yàn)镃#的lambda函數(shù)就是匿名函數(shù)，改了改語法而已。

11、C# CLR之Nullable type

雖然C#要求value type的值不能是null，但寫數(shù)據(jù)庫程序時(shí)經(jīng)常遇到某個(gè)值是null的情況。為此，C#2.0引入了Nullable type。例如，int? x = null。

int? x其實(shí)就是一個(gè)縮寫，等價(jià)于Nullablex。Nullable是預(yù)定義的一個(gè)類，簡(jiǎn)單地對(duì)x作了封裝。（因?yàn)樵黾恿艘粋€(gè)類，顯然對(duì)性能稍微有點(diǎn)影響）

這個(gè)小改動(dòng)的實(shí)現(xiàn)其實(shí)很麻煩，需要修改CLR。為什么？因?yàn)樵鹊膞是一個(gè)value type，現(xiàn)在則變成了一個(gè)object，看這個(gè)：

void M(Object o)   {    if (o=null) {Bar();}  }  void F()  {    int? x = null;    M(x);  }

如果CLR不專門做修正的話，上面的Bar()不會(huì)被執(zhí)行。（思考題：想一想為什么~）

另外，C#還引入了一個(gè)默認(rèn)值運(yùn)算符“??”，稱為null-coalescing operator。

一句話，x ?? value是 (x==null) ? value: x的簡(jiǎn)寫。

12、C# CLR之屬性(property)的簡(jiǎn)單聲明

public int x {get; private set;}

是個(gè)很好用的句式。

注意，

public int x {get;}

是錯(cuò)誤的，不能通過編譯。

13、C# CLR之Extension method

//Extension method  static class MyExtMethods   {    static public GetFirstLetter(this string s) {return s[0];}  }

然后就可以用string s = “hello”; char ch = s.GetFirstLetter()了。

原理很簡(jiǎn)單，編譯器把上面那句話翻譯成MyExtMethods.GetFirstLetter(s)。LINQ就用到了這個(gè)技術(shù)。

14、C# CLR之匿名類型的背后。。。

var o = new {name = “Xiangpeng”, id = 123 };

在這背后是編譯器生成的一個(gè)匿名類，包含了兩個(gè)只讀屬性，形如public int id { get {return _id;} }為什么不做成可讀寫的呢？

很微妙。匿名類自動(dòng)生成了GetHashCode()，返回的是對(duì)所有屬性的hash code做XOR的結(jié)果。如果允許修改屬性值，那么Hash code的值就會(huì)變化；而這個(gè)可能會(huì)出問題~保險(xiǎn)起見，只讀吧。

15、C# CLR之每個(gè)thread占1M物理內(nèi)存

在Win32編程中thread的1M stack空間是Reserve的，直到真正用時(shí)才占用物理內(nèi)存；而在.net中，這1M空間直接被commit。

還好，可以在新建thread時(shí)指定stack size。不過這也比較危險(xiǎn)，設(shè)小了怕不夠。實(shí)際上，最好盡量避免創(chuàng)建thread——太多的thread要么導(dǎo)致CPU競(jìng)爭(zhēng)和context switch，要么都block著浪費(fèi)內(nèi)存。建議是：能用ThreadPool就用ThreadPool。

以上是“C#中使用CLR需要注意什么”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

網(wǎng)頁題目：C#中使用CLR需要注意什么
文章路徑：http://chinadenli.net/article38/pghopp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、移動(dòng)網(wǎng)站建設(shè)、ChatGPT、外貿(mào)網(wǎng)站建設(shè)、用戶體驗(yàn)、網(wǎng)站營銷

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)