.NET Framework 4.5 有哪些特性？相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。
創(chuàng)新互聯(lián)主要從事成都網(wǎng)站建設(shè)、成都做網(wǎng)站、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)巨鹿,十余年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來(lái)電咨詢建站服務(wù):18982081108
自.NET 4.5發(fā)布已經(jīng)過(guò)了差不多1年了。但是隨著最近微軟大多數(shù)的發(fā)布，與.NET開(kāi)發(fā)者交流的問(wèn)題顯示，開(kāi)發(fā)者僅知道一到兩個(gè)特性，其他的特性僅僅停留在MSDN并以簡(jiǎn)單的文檔形式存在著。
比如說(shuō)，當(dāng)你問(wèn)一個(gè).NET開(kāi)發(fā)者.NET框架內(nèi)核中有什么新東西的時(shí)候，他們中的大多數(shù)僅僅會(huì)說(shuō)異步與等待（至少和我交談的人們僅僅談到了這些特性）。
另外也很難貫通所有的新特性。因?yàn)檫@些特性可能對(duì)于你目前正在開(kāi)發(fā)的工作并不如聽(tīng)上去那么有趣。
所以在這篇文章中我想提及我喜歡的5個(gè)在.NET4.5內(nèi)核中的特性。當(dāng)然，這可能只是我喜歡的而并不是你的。但是我所做的是當(dāng)我選擇這些特性時(shí)我也想著較大的.NET社區(qū)，我希望我滿足了這種期望。
提示：這篇文章沒(méi)有討論在ASP.NET, WCF, WPF, WWF等中的新特性。僅僅講了關(guān)于內(nèi)核的新特性。
這個(gè)特性已經(jīng)被吹噓過(guò)度并且每個(gè).NET布道者都談?wù)撍?。但是這仍然是我喜歡的并且你會(huì)知道為什么從這里只有幾行。
異步和等待是標(biāo)記，它們標(biāo)記當(dāng)任務(wù)（線程）結(jié)束時(shí)控制應(yīng)該恢復(fù)到代碼的位置。
讓我們嘗試通過(guò)下面的代碼來(lái)搞清上面聲明的含義。如果你明白下面代碼的流程：
Static void main()從開(kāi)始處調(diào)用Method()方法。
Method()方法產(chǎn)生一個(gè)名為L(zhǎng)ongTask的任務(wù)（線程），線程將等待10秒。
同時(shí)，在調(diào)用了任務(wù)之后，控制又回到Method()方法繼續(xù)執(zhí)行剩下的代碼。換句話說(shuō)，正如調(diào)用時(shí)多線程的（Task.Run…）,LongTask仍在運(yùn)行。例如，等待10秒并且Method()方法剩下的代碼也在執(zhí)行。
現(xiàn)在在相同的情景下，我們想要第3步執(zhí)行得不一樣。我們想要在LongTask()執(zhí)行完成后，控制應(yīng)該回到Method方法執(zhí)行接下來(lái)的代碼。“異步”和“等待”關(guān)鍵字能夠幫助實(shí)現(xiàn)上面的功能。
這里有三個(gè)關(guān)于關(guān)鍵字“異步”和“等待”的重點(diǎn)需要記住：
異步和等待是一對(duì)關(guān)鍵字。你不能獨(dú)立使用它們。
異步應(yīng)用于方法。這個(gè)關(guān)鍵字是一個(gè)標(biāo)志，是說(shuō)該方法會(huì)有一個(gè)等待關(guān)鍵字。
等待關(guān)鍵字標(biāo)記了任務(wù)恢復(fù)執(zhí)行的位置。所以你總是發(fā)現(xiàn)這個(gè)關(guān)鍵字與Task關(guān)聯(lián)。
下面是前面討論的代碼的修訂版本，這里我們應(yīng)用了異步與等待。所有其他的步驟仍然如前所述，但是“步驟3”將在“步驟2”完成之后執(zhí)行。簡(jiǎn)單來(lái)說(shuō)就是控制在任務(wù)完成之后回到Method()方法。
現(xiàn)在你已經(jīng)閱讀了“異步”與“等待”的內(nèi)容，讓我來(lái)提個(gè)問(wèn)題。上面的代碼同樣也能通過(guò)Task.Wait或者Task.ContinueWith實(shí)現(xiàn)，那么它們有什么不同？我把這個(gè)問(wèn)題留作給你的家庭作業(yè)。
Zip是最為人所接受的文件格式之一。Zip格式以某些內(nèi)置的名字被幾乎所有操作系統(tǒng)支持。
在Windows操作系統(tǒng)中，它以“壓縮文件”的名稱實(shí)現(xiàn)。
在MAC操作系統(tǒng)中，它以“文檔實(shí)用程序”的名稱實(shí)現(xiàn)。
現(xiàn)在在.NET中我們對(duì)執(zhí)行Zip壓縮沒(méi)有內(nèi)置的支持。許多開(kāi)發(fā)者實(shí)用第三方組件如“DotnetZip”。在.NET4.5中，Zip屬性內(nèi)置于框架本身，以System.IO.Compression的命名空間內(nèi)置。
第一步你需要引用兩個(gè)命名空間：
System.IO.Compression.FileSystem
System.IO.Compression
接下來(lái)引用如下兩個(gè)命名空間：
using System.IO.Compression;
如果你想要從文件夾壓縮文件你可以調(diào)用如下所示的CreateFromDirectory函數(shù)。
ZipFile.CreateFromDirectory(@"D:\data",@"D:\data.zip");
如果你想要解壓，你可以調(diào)用如下代碼所示的ExtractToDirectory函數(shù)。
ZipFile.ExtractToDirectory(@"D:\data.zip", @"D:\data\unzip");
“正則表達(dá)式”一直是做驗(yàn)證首選的方式。如果你是正則表達(dá)式的新手，請(qǐng)看正則表達(dá)式，我解釋了正則表達(dá)式是如何執(zhí)行的。但是正因?yàn)檎齽t表達(dá)式的典型邏輯解析使得它暴露于DOS攻擊下。讓我們?cè)囍斫鈩偛盼艺f(shuō)的。
作為例子請(qǐng)考慮這樣的正則表達(dá)式-“^(\d+)$”。這個(gè)正則表達(dá)式表明只能有數(shù)字。你也可以看正則表達(dá)式符號(hào)圖，它標(biāo)明了這個(gè)正則表達(dá)式會(huì)如何求值?，F(xiàn)在讓我們假設(shè)要驗(yàn)證“123456X”。這將有6條路徑如下圖所示。
但如果我們?cè)俣嗉右粋€(gè)數(shù)字進(jìn)去，將會(huì)有7條路徑。換句話說(shuō)，隨著字符長(zhǎng)度的增加，正則表達(dá)式將會(huì)花更多時(shí)間執(zhí)行。也就是說(shuō)，求值時(shí)間與字符長(zhǎng)度成線性比例。
現(xiàn)在讓我們把之前定義的正則式從“^(\d+)$”變?yōu)椤癪(\d+)+$”。如果你看正則表達(dá)式符號(hào)圖它將相當(dāng)復(fù)雜。如果我們現(xiàn)在試著驗(yàn)證“123456X”，將會(huì)有32條路徑。如果你再增加一個(gè)字符，路徑數(shù)將會(huì)增加到64。
換句話說(shuō)，上面的正則表達(dá)式中時(shí)間開(kāi)銷(xiāo)與字符數(shù)目為成倍關(guān)系。
現(xiàn)在你可能要問(wèn)的是，這很重要嗎？線性上升的求值時(shí)間可以被黑客利用來(lái)進(jìn)行DOS（拒絕服務(wù)）攻擊。他們可以部署一個(gè)長(zhǎng)而且是足夠長(zhǎng)的字符串來(lái)使你的應(yīng)用永遠(yuǎn)掛起。
對(duì)于這個(gè)問(wèn)題合適的解決方法是在正則表達(dá)式執(zhí)行上設(shè)置超時(shí)時(shí)間。好消息是，在.NET4.5中你可以定義一個(gè)超時(shí)屬性如下代碼所示。所以如果你收到任何懷有惡意的字符串，應(yīng)用不會(huì)永遠(yuǎn)在循環(huán)中執(zhí)行。
重慶分公司
重慶分公司
try
{
var regEx = new Regex(@”^(\d+)+$”, RegexOptions.Singleline, TimeSpan.FromSeconds(2));
var match = regEx.Match(“123453109839109283090492309480329489812093809x”);
}
catch (RegexMatchTimeoutException ex)
{
Console.WriteLine(“Regex Timeout”);
}
我們都知道.NET代碼是半編譯的格式。在運(yùn)行時(shí)，JIT（Just-in-Time）編譯器執(zhí)行并且轉(zhuǎn)換這種半編譯的IL代碼為機(jī)器原生代碼。對(duì)JIT最大的抱怨之一是當(dāng).NET應(yīng)用初次執(zhí)行的時(shí)候，它運(yùn)行得很慢因?yàn)镴IT在忙著轉(zhuǎn)換IL代碼到機(jī)器代碼。
為了降低這個(gè)啟動(dòng)時(shí)間，在.NET4.5中有稱為“優(yōu)化配置文件”的內(nèi)容。配置文件不過(guò)是一個(gè)記錄了應(yīng)用在啟動(dòng)運(yùn)行中需要的方法列表的簡(jiǎn)單文件。所以當(dāng)應(yīng)用開(kāi)始后，后臺(tái)的JIT執(zhí)行并且開(kāi)始轉(zhuǎn)換這些方法的IL代碼為機(jī)器/原生語(yǔ)言。
這個(gè)后臺(tái)JIT在多個(gè)處理器上編譯啟動(dòng)方法從而進(jìn)一步降低啟動(dòng)時(shí)間。另外請(qǐng)注意你需要多核處理器來(lái)實(shí)現(xiàn)配置文件優(yōu)化。如果你沒(méi)有多核處理器那么這個(gè)設(shè)定會(huì)被忽略。
為了創(chuàng)建“配置文件”這個(gè)文件，首先你需要引入System.Runtime命名空間。然后你可以調(diào)用靜態(tài)類ProfileOptimization的SetProfileRoot和StartProfile方法。現(xiàn)在當(dāng)應(yīng)用啟動(dòng)后臺(tái)JIT，它將會(huì)讀取配置文件并且在后臺(tái)編譯啟動(dòng)方法從而降低啟動(dòng)時(shí)間。
using System.Runtime;
// Call the Setprofilerroot and Startprofile method
ProfileOptimization.SetProfileRoot(@"D:\ProfileFile");
ProfileOptimization.StartProfile("ProfileFile");重要提示：ASP.NET 4.5和Silverlight 5應(yīng)用默認(rèn)支持Profileoptimization。所以上述代碼在這些技術(shù)中無(wú)需編寫(xiě)。
垃圾回收在.NET應(yīng)用中是一項(xiàng)真正繁重的任務(wù)。當(dāng)是ASP.NET應(yīng)用的時(shí)候，它變得更繁重。ASP.NET應(yīng)用在服務(wù)器運(yùn)行，許多客戶端向服務(wù)器發(fā)送請(qǐng)求從而產(chǎn)生對(duì)象負(fù)荷，使得垃圾回收確實(shí)努力清理不需要的對(duì)象。
在.NET4.0中，當(dāng)垃圾回收運(yùn)行清理的時(shí)候，所有的應(yīng)用程序線程都暫停了。在上圖中你可以看到我們有3個(gè)應(yīng)用程序線程在執(zhí)行。有兩個(gè)垃圾回收運(yùn)行在不同的線程上。一個(gè)垃圾回收線程對(duì)應(yīng)一個(gè)邏輯處理器。現(xiàn)在應(yīng)用程序線程運(yùn)行并執(zhí)行它們的任務(wù)，伴隨著這些應(yīng)用程序線程的執(zhí)行它們也創(chuàng)建了操作對(duì)象。
在某個(gè)時(shí)間點(diǎn)，后臺(tái)垃圾回收運(yùn)行開(kāi)始清理。當(dāng)這些垃圾回收開(kāi)始清理的時(shí)候，它們暫停了所有的應(yīng)用程序線程。這使得服務(wù)器/應(yīng)用程序在那一刻不響應(yīng)了。
為了克服上述問(wèn)題，服務(wù)器垃圾回收被引進(jìn)了。在服務(wù)器垃圾回收機(jī)制中多創(chuàng)建了一個(gè)運(yùn)行在后臺(tái)的線程。這個(gè)線程在后臺(tái)運(yùn)行并持續(xù)清理2代對(duì)象（關(guān)于垃圾回收0,1和2代的視頻）從而降低主垃圾回收線程的開(kāi)銷(xiāo)。由于雙垃圾回收線程的執(zhí)行，主應(yīng)用程序線程很少被暫停，進(jìn)而增加了應(yīng)用程序吞吐量。為了使用服務(wù)器垃圾回收，我們需要使用gcServer XML標(biāo)簽并且將它置為true。
設(shè)置默認(rèn)應(yīng)用程序域的區(qū)域性
在上一個(gè)版本的.NET中如果我想設(shè)置區(qū)域性那么我需要在每個(gè)線程中設(shè)置。下面的示例程序演示了在線程級(jí)別設(shè)置區(qū)域性的痛苦。當(dāng)我們有大量多線程應(yīng)用程序的時(shí)候這是真正的痛苦。
CultureInfo cul = new CultureInfo(strCulture); Thread.CurrentThread.CurrentCulture = cul; Thread.CurrentThread.CurrentUICulture = cul;
在4.5中我們可以在應(yīng)用程序域級(jí)別設(shè)置區(qū)域性并且所有在這個(gè)應(yīng)用程序域當(dāng)中的線程都會(huì)繼承這個(gè)區(qū)域性。下面就是如何實(shí)現(xiàn)DefaultThreadCurrentCulture的示例代碼。
CultureInfo culture = CultureInfo.CreateSpecificCulture("fr-FR");
CultureInfo.DefaultThreadCurrentCulture = culture;數(shù)組支持超過(guò)2GB容量
我不確定在什么樣的情景下我們會(huì)需要2GB的容器。所以我個(gè)人并不清楚我們將在哪用到這個(gè)特性。如果我曾需要如此之大的容器我會(huì)把它分解成小份。但我確信在框架中啟用此功能應(yīng)該有個(gè)很好的理由。
控制臺(tái)支持Unicode編碼
我把這個(gè)特性留在討論范圍之外是因?yàn)榉浅Ｉ俚娜擞每刂婆_(tái)程序工作。我曾見(jiàn)過(guò)有人把控制臺(tái)用于學(xué)術(shù)目的?？偠灾?，我們現(xiàn)在也對(duì)控制臺(tái)應(yīng)用有了Unicode編碼支持。
引用
http://msdn.microsoft.com/en-us/library/ms171868.aspx
Mr Sukesh marla的精彩文章ASP.NET 4.5 new features
當(dāng)你有空的時(shí)候，一定來(lái)看看我的網(wǎng)站 www.questpond.com關(guān)于.NET4.5面試問(wèn)和答，我已經(jīng)在這方面有了不少努力。
看完上述內(nèi)容，你們掌握.NET Framework 4.5 有哪些特性的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！
