.NET Framework 4.5 特性

此文爲轉載！

英文原文：Five Great .NET Framework 4.5 Features

　　簡介

　　自 .NET 4.5 發佈已通過了差很少 1 年了。可是隨着最近微軟大多數的發佈，與 .NET 開發者交流的問題顯示，開發者僅知道一到兩個特性，其餘的特性僅僅停留在 MSDN 並以簡單的文檔形式存在着。

　　好比說，當你問一個 .NET 開發者 .NET 框架內核中有什麼新東西的時候，他們中的大多數僅僅會說異步與等待（至少和我交談的人們僅僅談到了這些特性）。

　　另外也很難貫通全部的新特性。由於這些特性可能對於你目前正在開發的工做並不如聽上去那麼有趣。

　　因此在這篇文章中我想說起我喜歡的 5 個在 .NET4.5 內核中的特性。固然，這可能只是我喜歡的而並非你的。可是我所作的是當我選擇這些特性時我也想着較大的 .NET 社區，我但願我知足了這種指望。

　　提示：這篇文章沒有討論在 ASP.NET, WCF, WPF, WWF 等中的新特性。僅僅講了關於內核的新特性。

　　 特性1：異步與等待（代碼開發者）

　　這個特性已經被吹噓過分而且每一個 .NET 佈道者都談論它。可是這仍然是我喜歡的而且你會知道爲何從這裏只有幾行。

　　異步和等待是標記，它們標記當任務（線程）結束時控制應該恢復到代碼的位置。

　　讓咱們嘗試經過下面的代碼來搞清上面聲明的含義。若是你明白下面代碼的流程：

1. Static void main ()從開始處調用 Method ()方法。
2.  Method ()方法產生一個名爲 LongTask 的任務（線程），線程將等待 10 秒。
3.  同時，在調用了任務以後，控制又回到 Method ()方法繼續執行剩下的代碼。換句話說，正如調用時多線程的（Task.Run…）,LongTask 仍在運行。例如，等待 10 秒而且 Method ()方法剩下的代碼也在執行。

　　如今在相同的情景下，咱們想要第 3 步執行得不同。咱們想要在 LongTask ()執行完成後，控制應該回到 Method 方法執行接下來的代碼。「異步」和「等待」關鍵字可以幫助實現上面的功能。

　　這裏有三個關於關鍵字「異步」和「等待」的重點須要記住：

1. 異步和等待是一對關鍵字。你不能獨立使用它們。
2. 異步應用於方法。這個關鍵字是一個標誌，是說該方法會有一個等待關鍵字。
3. 等待關鍵字標記了任務恢復執行的位置。因此你老是發現這個關鍵字與 Task 關聯。

　　下面是前面討論的代碼的修訂版本，這裏咱們應用了異步與等待。全部其餘的步驟仍然如前所述，可是「步驟3」將在「步驟2」完成以後執行。簡單來講就是控制在任務完成以後回到 Method ()方法。

　　如今你已經閱讀了「異步」與「等待」的內容，讓我來提個問題。上面的代碼一樣也能經過 Task.Wait 或者 Task.ContinueWith 實現，那麼它們有什麼不一樣？我把這個問題留做給你的家庭做業。

　　特性2：便利 Zip 壓縮（Zip 壓縮）

　　Zip 是最爲人所接受的文件格式之一。Zip 格式以某些內置的名字被幾乎全部操做系統支持。

• 在 Windows 操做系統中，它以「壓縮文件」的名稱實現。
• 在 MAC 操做系統中，它以「文檔實用程序」的名稱實現。

　　如今在 .NET 中咱們對執行 Zip 壓縮沒有內置的支持。許多開發者實用第三方組件如「DotnetZip」。在 .NET4.5 中，Zip 屬性內置於框架自己，以 System.IO.Compression 的命名空間內置。

　　第一步你須要引用兩個命名空間：

• System.IO.Compression.FileSystem
• System.IO.Compression

　　接下來引用以下兩個命名空間：

using System.IO.Compression;

　　若是你想要從文件夾壓縮文件你能夠調用以下所示的 CreateFromDirectory 函數。

ZipFile.CreateFromDirectory (@"D:\data",@"D:\data.zip");

　　若是你想要解壓，你能夠調用以下代碼所示的 ExtractToDirectory 函數。

ZipFile.ExtractToDirectory (@"D:\data.zip", @"D:\data\unzip");

　　特性3：正則表達式超時（超時）

　　「正則表達式」一直是作驗證首選的方式。若是你是正則表達式的新手，請看正則表達式，我解釋了正則表達式是如何執行的。可是正由於正則表達式的典型邏輯解析使得它暴露於 DOS 攻擊下。讓咱們試着理解剛纔我說的。

　　做爲例子請考慮這樣的正則表達式-「^(\d+)$」。這個正則表達式代表只能有數字。你也能夠看正則表達式符號圖，它標明瞭這個正則表達式會如何求值。如今讓咱們假設要驗證「123456X」。這將有 6 條路徑以下圖所示。

　　但若是咱們再多加一個數字進去，將會有 7 條路徑。換句話說，隨着字符長度的增長，正則表達式將會花更多時間執行。也就是說，求值時間與字符長度成線性比例。

　　如今讓咱們把以前定義的正則式從「^(\d+)$」變爲「^(\d+)+$」。若是你看正則表達式符號圖它將至關複雜。若是咱們如今試着驗證「123456X」，將會有 32 條路徑。若是你再增長一個字符，路徑數將會增長到 64。

　　換句話說，上面的正則表達式中時間開銷與字符數目爲成倍關係。

　　如今你可能要問的是，這很重要嗎？線性上升的求值時間能夠被黑客利用來進行 DOS（拒絕服務）攻擊。他們能夠部署一個長並且是足夠長的字符串來使你的應用永遠掛起。

　　對於這個問題合適的解決方法是在正則表達式執行上設置超時時間。好消息是，在 .NET4.5 中你能夠定義一個超時屬性以下代碼所示。因此若是你收到任何懷有惡意的字符串，應用不會永遠在循環中執行。

try
{
  var regEx = new Regex (@」^(\d+)+$」, RegexOptions.Singleline, TimeSpan.FromSeconds (2));
  var match = regEx.Match (「123453109839109283090492309480329489812093809x」);
}
catch (RegexMatchTimeoutException ex)
{
  Console.WriteLine (「Regex Timeout」);
}

　　特性4：優化配置文件（提高啓動性能）

　　咱們都知道 .NET 代碼是半編譯的格式。在運行時，JIT（Just-in-Time）編譯器執行而且轉換這種半編譯的 IL 代碼爲機器原生代碼。對 JIT 最大的抱怨之一是當 .NET 應用初次執行的時候，它運行得很慢由於 JIT 在忙着轉換 IL 代碼到機器代碼。

　　爲了下降這個啓動時間，在 .NET4.5 中有稱爲「優化配置文件」的內容。配置文件不過是一個記錄了應用在啓動運行中須要的方法列表的簡單文件。因此當應用開始後，後臺的 JIT 執行而且開始轉換這些方法的 IL 代碼爲機器/原生語言。

　　這個後臺 JIT 在多個處理器上編譯啓動方法從而進一步下降啓動時間。另外請注意你須要多核處理器來實現配置文件優化。若是你沒有多核處理器那麼這個設定會被忽略。

　　爲了建立「配置文件」這個文件，首先你須要引入 System.Runtime 命名空間。而後你能夠調用靜態類 ProfileOptimization 的 SetProfileRoot 和 StartProfile 方法。如今當應用啓動後臺 JIT，它將會讀取配置文件而且在後臺編譯啓動方法從而下降啓動時間。

using System.Runtime;
// Call the Setprofilerroot and Startprofile method 
ProfileOptimization.SetProfileRoot (@"D:\ProfileFile");
ProfileOptimization.StartProfile ("ProfileFile");

　　重要提示：ASP.NET 4.5 和 Silverlight 5 應用默認支持 Profileoptimization。因此上述代碼在這些技術中無需編寫。

　　特性5：垃圾回收（垃圾後臺清理）

　　垃圾回收在 .NET 應用中是一項真正繁重的任務。當是 ASP.NET 應用的時候，它變得更繁重。ASP.NET 應用在服務器運行，許多客戶端向服務器發送請求從而產生對象負荷，使得垃圾回收確實努力清理不須要的對象。

　　在 .NET4.0 中，當垃圾回收運行清理的時候，全部的應用程序線程都暫停了。在上圖中你能夠看到咱們有 3 個應用程序線程在執行。有兩個垃圾回收運行在不一樣的線程上。一個垃圾回收線程對應一個邏輯處理器。如今應用程序線程運行並執行它們的任務，伴隨着這些應用程序線程的執行它們也建立了操做對象。

　　在某個時間點，後臺垃圾回收運行開始清理。當這些垃圾回收開始清理的時候，它們暫停了全部的應用程序線程。這使得服務器/應用程序在那一刻不響應了。

　　爲了克服上述問題，服務器垃圾回收被引進了。在服務器垃圾回收機制中多建立了一個運行在後臺的線程。這個線程在後臺運行並持續清理 2 代對象（關於垃圾回收0,1 和 2 代的視頻）從而下降主垃圾回收線程的開銷。因爲雙垃圾回收線程的執行，主應用程序線程不多被暫停，進而增長了應用程序吞吐量。爲了使用服務器垃圾回收，咱們須要使用 gcServer XML 標籤而且將它置爲 true。

<configuration> 
　　<runtime> 
　　　　<gcServer enabled="true"/> 
　　</runtime> 
</configuration>

　　另三個值得探索的特性

　　設置默認應用程序域的區域性

　　在上一個版本的 .NET 中若是我想設置區域性那麼我須要在每一個線程中設置。下面的示例程序演示了在線程級別設置區域性的痛苦。當咱們有大量多線程應用程序的時候這是真正的痛苦。

　　CultureInfo cul = new CultureInfo (strCulture);
　　Thread.CurrentThread.CurrentCulture = cul;
　　Thread.CurrentThread.CurrentUICulture = cul;

　　在 4.5 中咱們能夠在應用程序域級別設置區域性而且全部在這個應用程序域當中的線程都會繼承這個區域性。下面就是如何實現 DefaultThreadCurrentCulture 的示例代碼。

CultureInfo culture = CultureInfo.CreateSpecificCulture ("fr-FR");
CultureInfo.DefaultThreadCurrentCulture = culture;

　　數組支持超過 2GB 容量

　　我不肯定在什麼樣的情景下咱們會須要 2GB 的容器。因此我我的並不清楚咱們將在哪用到這個特性。若是我曾須要如此之大的容器我會把它分解成小份。但我確信在框架中啓用此功能應該有個很好的理由。

　　控制檯支持 Unicode 編碼

　　我把這個特性留在討論範圍以外是由於很是少的人用控制檯程序工做。我曾見過有人把控制檯用於學術目的。總而言之，咱們如今也對控制檯應用有了 Unicode 編碼支持。

　　引用

• http://msdn.microsoft.com/en-us/library/ms171868.aspx
• Mr Sukesh marla 的精彩文章 ASP.NET 4.5 new features

　　當你有空的時候，必定來看看個人網站 www.questpond.com 關於 .NET4.5 面試問和答，我已經在這方面有了很多努力。