.NET Framework 4.5의 5가지 뛰어난 기능 공유

소개

.NET 4.5가 출시된 지 거의 1년이 되었습니다. 그러나 대부분의 Microsoft 최신 릴리스에서 .NET 개발자와의 통신 문제로 인해 개발자는 한두 가지 기능만 알고 있으며 다른 기능은 MSDN에만 남아 있으며 간단한 문서 형식으로 존재한다는 사실이 드러났습니다.

예를 들어, .NET 개발자에게 .NETFramework커널의 새로운 기능이 무엇인지 묻는다면 대부분은 async 및 wait라고 답할 것입니다(적어도 저와 대화한 사람들은 이러한 속성에 대해서만 이야기했습니다).

게다가 새로운 기능을 모두 이해하기는 어렵습니다. 왜냐하면 이러한 기능은 현재 개발 중인 작업에 비해 그다지 흥미롭지 않을 수 있기 때문입니다.

그래서 이 기사에서는 .NET 4.5 커널에서 제가 좋아하는 5가지 기능을 언급하고 싶습니다. 물론 이건 내 취향이지 당신의 취향은 아닐 수도 있다. 하지만 제가 하는 일은 이러한 기능을 선택할 때 더 큰 .NET 커뮤니티에 대해서도 생각하는 것이며, 그 기대에 부응하기를 바랍니다.

팁: 이 기사에서는 ASP.NET, WCF, WPF, WWF 등의 새로운 기능에 대해 논의하지 않습니다. 나는 커널의 새로운 기능에 대해서만 이야기했습니다.

기능 1: Async 및 Await(코드 개발자)

이 기능은 과장되었으며 모든 .NET 전도사들이 이에 대해 이야기합니다. 하지만 이것이 여전히 내가 좋아하는 것이고 여기에서 몇 줄 밖에 되지 않은 이유를 알게 될 것입니다.

Async 및 Wait는 작업(스레드)이 종료될 때 제어가 코드로 반환되어야 하는 위치를 표시하는 마커입니다.

다음 코드를 통해 위 문장의 의미를 알아보도록 하겠습니다. 다음 코드의 흐름을 이해하시면

1. Static void main()은 처음부터 Method() 메소드를 호출합니다.

2. Method() 메서드는 LongTask라는 작업(스레드)을 생성하고 스레드는 10초 동안 대기합니다.

3. 동시에 작업을 호출한 후 제어는 Method() 메서드로 반환되어 나머지 코드를 계속 실행합니다. 즉, LongTask는 멀티스레드(Task.Run...)라고 불리는 것처럼 여전히 실행 중입니다. 예를 들어 10초 동안 기다리면 Method() 메서드의 나머지 부분이 실행됩니다.

이제 동일한 시나리오에서 3단계를 다르게 수행하려고 합니다. LongTask() 실행이 완료된 후 제어가 Method 메서드로 반환되어 다음 코드를 실행하기를 원합니다. "async" 및 "await" 키워드는 위 기능을 달성하는 데 도움이 될 수 있습니다.

다음은 "async" 및 "await" 키워드에 대해 기억해야 할 세 가지 핵심 사항입니다.

1. Async 및 Wait는 A입니다. 키워드 쌍. 독립적으로 사용할 수는 없습니다.

2. 메서드에 비동기적으로 적용됩니다. 이 키워드는 플래그입니다. 이는 메소드에 wait 키워드가 있음을 의미합니다.

3. wait 키워드는 작업 실행이 재개되는 위치를 표시합니다. 따라서 항상 Task와 관련된 이 키워드를 찾을 수 있습니다.

아래는 앞에서 설명한 코드의 수정된 버전으로 async 및 Wait를 적용합니다. 다른 모든 단계는 위에서 설명한 대로 유지되지만, "2단계"가 완료된 후 "3단계"가 수행됩니다. 간단히 말해서 작업이 완료된 후 컨트롤은 Method() 메서드로 반환됩니다.

이제 'async'와 'await'에 대해 읽어보셨으니 질문 하나 드리겠습니다. 위 코드는 Task.Wait나 Task.ContinueWith를 통해서도 구현할 수 있는데, 둘 사이의 차이점은 무엇인가요? 이 질문을 숙제로 남겨두겠습니다.

특징 2: 편리성Zip압축(Zip 압축)

Zip은 가장 많이 사용되는 파일 형식 중 하나입니다. Zip 형식은 일부 내장 이름으로 거의 모든 운영 체제에서 지원됩니다.

• Windows 운영체제에서는 "압축파일"이라는 이름으로 구현됩니다.

• MAC 운영 체제에서는 "Document Utility"라는 이름으로 구현됩니다.

현재 .NET에는 Zip 압축 수행을 위한 기본 지원 기능이 없습니다. 많은 개발자가 "DotnetZip"과 같은 타사 구성 요소를 사용합니다. .NET 4.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: 정규식

타임아웃(timeout)

"정규식"은 항상 검증을 위해 선호되는 방법이었습니다. . 정규식을 처음 사용하는 경우 정규식이 어떻게 수행되는지 설명하는 정규식을 참조하세요. 그러나 DOS 공격에 노출되는 것은 바로 정규 표현식의 일반적인 논리적 구문 분석 때문입니다. 내가 방금 말한 것을 이해하려고 노력합시다.

예를 들어 "^(d+)$"라는 정규식을 고려해 보십시오. 이 정규 표현식은 숫자만 있을 수 있음을 나타냅니다. 정규식이 평가되는 방법을 보여주는 정규식 기호 다이어그램을 볼 수도 있습니다. 이제 "123456X"를 확인한다고 가정해 보겠습니다. 아래 이미지와 같이 6개의 경로가 있습니다.

그런데 숫자를 하나 더 추가하면 길이 7개가 됩니다. 즉, 문자 길이가 길어질수록 정규식을 실행하는 데 더 많은 시간이 걸립니다. 즉, 평가 시간은 문자 길이에 따라 선형적으로 늘어납니다.

이제 앞서 정의한 정규 표현식을 "^(d+)$"에서 "^(d+)+$"로 변경해 보겠습니다. 정규식 표기법 다이어그램을 보면 매우 복잡합니다. 이제 "123456X"를 확인하려고 하면 32개의 경로가 있습니다. 캐릭터를 1명 더 추가하면 경로 수가 64개로 늘어납니다.

즉, 위 정규식의 시간 오버헤드는 문자 수에 기하급수적으로 관련됩니다.

이제 여러분이 궁금해하실 수 있는 것은 이것이 중요합니까? 선형적으로 증가하는 평가 시간은 해커가 DOS(서비스 거부) 공격을 수행하는 데 악용될 수 있습니다. 애플리케이션이 영원히 중단될 만큼 길고 긴 문자열

을 배포할 수 있습니다.

이 문제에 대한 적절한 해결책은 정규식 실행에 시간 제한을 설정하는 것입니다. 좋은 소식은 .NET 4.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></gcserver>
   </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面试问和答，我已经在这方面有了不少努力。

위 내용은 .NET Framework 4.5의 5가지 뛰어난 기능 공유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!