نظرات مطالب
مثال 9 هست.
مورد 9 خیلی جالب بود!
اشتراکها
ASP.NET Core 3.0 Preview 9 منتشر شد
To get started with ASP.NET Core in .NET Core 3.0 Preview 9 install the .NET Core 3.0 Preview 9 SDK.
If you’re on Windows using Visual Studio, install the latest preview of Visual Studio 2019.
.NET Core 3.0 Preview 9 requires Visual Studio 2019 16.3 Preview 3 or later.
LINQ یا همان Language-Integrated Query، یک زبان سادهی کوئری نوشتن یکپارچهی با دات نت است. به کمک آن میتوان اعمال پیچیدهای را بر روی اشیاء، به زبانی ساده بیان کرد و امروزه تقریبا توسط تمام توسعه دهندگان دات نت مورد استفاده قرار میگیرد. اما ... این سادگی، بهایی را نیز به همراه دارد: کمتر بودن سرعت اجرا و همچنین افزایش مصرف حافظه. با توجه به گستردگی استفادهی از LINQ، اگر بهبودی در این زمینه حاصل شود، بر روی کارآیی تمام برنامههای دات نتی تاثیر خواهد گذاشت و این امر در دات نت 7 محقق شدهاست. کارآیی متدهای LINQ to Objects در دات نت 7 (مانند متدهای Enumerable.Max, Enumerable.Min, Enumerable.Average, Enumerable.Sum) به شدت افزایش یافته و این افزایش گاهی حتی بیشتر از 10 برابر نسبت به نگارشهای قبلی دات نت است؛ اما چگونه به چنین کارآیی رسیدهاند؟
تدارک یک آزمایش برای بررسی میزان افزایش کارآیی متدهای LINQ در دات نت 7
در ادامه یک آزمایش سادهی بررسی کارآیی متدهای Enumerable.Max, Enumerable.Min, Enumerable.Average, Enumerable.Sum را با استفاده از کتابخانهی معروف BenchmarkDotNet مشاهده میکنید:
برای آزمایش آن، یکبار target framework پروژه را بر روی net6.0 و بار دیگر بر روی net7.0 قرار داده و برنامه را اجرا میکنیم. خلاصهی مفهومی نتایج حاصل به صورت زیر است که ... شگفتانگیز هستند!
در مورد کار با آرایهها:
- زمان اجرای یافتن Min در آرایههای کوچک، در دات نت 7، نسبت به دات نت 6، حدودا 10 برابر کاهش یافته و اگر این آرایه بزرگتر شود و برای مثال حاوی 10 هزار المان باشد، این زمان 20 برابر کاهش یافتهاست.
- این کاهش زمانها برای سایر متدهای LINQ نیز تقریبا به همین صورت است؛ منها متد Sum که اندازهی آرایه، تاثیری را بر روی نتیجهی نهایی ندارد.
- همچنین در دات نت 7، با فراخوانی متدهای LINQ، افزایش حافظهای مشاهده نمیشود.
در مورد کار با لیستها:
- در دات نت 6، اعمال صورت گرفتهی توسط LINQ بر روی آرایهها، نسبت به لیستها، همواره سریعتر است.
- در دات نت 7 هم در مورد مجموعههای کوچک، وضعیت همانند دات نت 6 است. اما اگر مجموعهها بزرگتر شوند، تفاوتی بین مجموعهها و آرایهها وجود ندارد و حتی وضعیت مجموعهها بهتر است: کارآیی کار با لیستها 32 برابر بیشتر شدهاست!
اما چگونه در دات نت 7، چنین بهبود کارآیی خیرهکنندهای در متدهای LINQ حاصل شدهاست؟
برای بررسی چگونگی بهبود کارآیی متدهای LINQ در دات نت 7 باید به نحوهی پیاده سازی آنها در نگارشهای مختلف دات نت مراجعه کرد. برای مثال پیاده سازی متد الحاقی Min تا دات نت 6 به صورت زیر است:
این متد نسبتا سادهاست. یک IEnumerable را دریافت کرده و سپس با استفاده از متد MoveNext، مقدار فعلی را با مقدار بعدی مقایسه میکند. در این مقایسه، کوچکترین مقدار ذخیره میشود تا در نهایت به انتهای مجموعه برسیم.
اما ... پیاده سازی این متد در دات نت 7 متفاوت است:
در اینجا در ابتدا سعی میشود تا یک ReadOnlySpan از مجموعهی ارائه شده، تهیه شود. اگر این کار میسر نشد، کدهای همان روش قبلی دات نت 6 که توضیح داده شد، اجرا میشود. البته در آزمایشی که ما تدارک دیدیم، چون از لیستها و آرایهها استفاده شده بود، همواره امکان تهیهی یک ReadOnlySpan از آنها میسر است. بنابراین به قسمت اجرایی همانند دات نت 6 نمیرسیم.
اما ... ReadOnlySpan چیست؟ نوعهای Span و ReadOnlySpan، یک ناحیهی پیوستهی مدیریت شده و مدیریت نشدهی حافظه را بیان میکنند. یک Span از نوع ref struct است؛ یعنی تنها میتواند بر روی stack قرار گیرد که مزیت آن، عدم نیاز به تخصیص حافظهی اضافی و بهبود کارآیی است. همچنین ساختار داخلی Span در سی شارپ 11 اندکی تغییر کردهاست که در آن از ref fields جهت دسترسی امن به این ناحیهی از حافظه استفاده میشود. پیشتر از نوع داخلی ByReference برای اشاره به ابتدای این ناحیهی از حافظه استفاده میشد که به همراه بررسی امنیتی در این باره نبود.
پس از دریافت ReadOnlySpan، به سطر زیر میرسیم:
که بررسی میکند آیا سخت افرار فعلی از قابلیتهای SIMD برخوردار است یا خیر؟ اگر بله، اینبار با استفاده از ریاضیات برداری شتاب یافتهی توسط سخت افزار، محاسبات را انجام میدهد:
بنابراین به صورت خلاصه در دات نت 7 با استفاده از بکارگیری نوعهای ویژهی Span و نوعهای برداری شتابیافتهی توسط اکثر سخت افزارهای امروزی، سبب بهبود قابل ملاحظهی کارآیی متدهای LINQ شدهاند.
تدارک یک آزمایش برای بررسی میزان افزایش کارآیی متدهای LINQ در دات نت 7
در ادامه یک آزمایش سادهی بررسی کارآیی متدهای Enumerable.Max, Enumerable.Min, Enumerable.Average, Enumerable.Sum را با استفاده از کتابخانهی معروف BenchmarkDotNet مشاهده میکنید:
using BenchmarkDotNet.Attributes; using BenchmarkDotNet.Running; using System.Collections.Generic; using System.Linq; [MemoryDiagnoser(displayGenColumns: false)] public partial class Program { static void Main(string[] args) => BenchmarkSwitcher.FromAssembly(typeof(Program).Assembly).Run(args); [Params (10, 10000)] public int Size { get; set; } private IEnumerable<int> items; [GlobalSetup] public void Setup() { items = Enumerable.Range(1, Size).ToArray(); } [Benchmark] public int Min() => items.Min(); [Benchmark] public int Max() => items.Max(); [Benchmark] public double Average() => items.Average(); [Benchmark] public int Sum() => items.Sum(); }
در مورد کار با آرایهها:
- زمان اجرای یافتن Min در آرایههای کوچک، در دات نت 7، نسبت به دات نت 6، حدودا 10 برابر کاهش یافته و اگر این آرایه بزرگتر شود و برای مثال حاوی 10 هزار المان باشد، این زمان 20 برابر کاهش یافتهاست.
- این کاهش زمانها برای سایر متدهای LINQ نیز تقریبا به همین صورت است؛ منها متد Sum که اندازهی آرایه، تاثیری را بر روی نتیجهی نهایی ندارد.
- همچنین در دات نت 7، با فراخوانی متدهای LINQ، افزایش حافظهای مشاهده نمیشود.
در مورد کار با لیستها:
- در دات نت 6، اعمال صورت گرفتهی توسط LINQ بر روی آرایهها، نسبت به لیستها، همواره سریعتر است.
- در دات نت 7 هم در مورد مجموعههای کوچک، وضعیت همانند دات نت 6 است. اما اگر مجموعهها بزرگتر شوند، تفاوتی بین مجموعهها و آرایهها وجود ندارد و حتی وضعیت مجموعهها بهتر است: کارآیی کار با لیستها 32 برابر بیشتر شدهاست!
اما چگونه در دات نت 7، چنین بهبود کارآیی خیرهکنندهای در متدهای LINQ حاصل شدهاست؟
برای بررسی چگونگی بهبود کارآیی متدهای LINQ در دات نت 7 باید به نحوهی پیاده سازی آنها در نگارشهای مختلف دات نت مراجعه کرد. برای مثال پیاده سازی متد الحاقی Min تا دات نت 6 به صورت زیر است:
public static int Min(this IEnumerable<int> source) { if (source == null) { ThrowHelper.ThrowArgumentNullException(ExceptionArgument.source); } int value; using (IEnumerator<int> e = source.GetEnumerator()) { if (!e.MoveNext()) { ThrowHelper.ThrowNoElementsException(); } value = e.Current; while (e.MoveNext()) { int x = e.Current; if (x < value) { value = x; } } } return value; }
اما ... پیاده سازی این متد در دات نت 7 متفاوت است:
public static int Min(this IEnumerable<int> source) => MinInteger(source); private static T MinInteger<T>(this IEnumerable<T> source) where T : struct, IBinaryInteger<T> { T value; if (source.TryGetSpan(out ReadOnlySpan<T> span)) { if (Vector.IsHardwareAccelerated && span.Length >= Vector<T>.Count * 2) { .... // Optimized implementation return ....; } } .... //Implementation as in .NET 6 }
اما ... ReadOnlySpan چیست؟ نوعهای Span و ReadOnlySpan، یک ناحیهی پیوستهی مدیریت شده و مدیریت نشدهی حافظه را بیان میکنند. یک Span از نوع ref struct است؛ یعنی تنها میتواند بر روی stack قرار گیرد که مزیت آن، عدم نیاز به تخصیص حافظهی اضافی و بهبود کارآیی است. همچنین ساختار داخلی Span در سی شارپ 11 اندکی تغییر کردهاست که در آن از ref fields جهت دسترسی امن به این ناحیهی از حافظه استفاده میشود. پیشتر از نوع داخلی ByReference برای اشاره به ابتدای این ناحیهی از حافظه استفاده میشد که به همراه بررسی امنیتی در این باره نبود.
پس از دریافت ReadOnlySpan، به سطر زیر میرسیم:
if (Vector.IsHardwareAccelerated && span.Length >= Vector<T>.Count * 2)
private static T MinInteger<T>(this IEnumerable<T> source) where T : struct, IBinaryInteger<T> { .... if (Vector.IsHardwareAccelerated && span.Length >= Vector<T>.Count * 2) { var mins = new Vector<T>(span); index = Vector<T>.Count; do { mins = Vector.Min(mins, new Vector<T>(span.Slice(index))); index += Vector<T>.Count; } while (index + Vector<T>.Count <= span.Length); value = mins[0]; for (int i = 1; i < Vector<T>.Count; i++) { if (mins[i] < value) { value = mins[i]; } } .... }
OneDev is an open source git hosting and CI/CD server. Unlike traditional code hosting platforms, it parses C# code to enable symbol search and navigation, both in source view and diff view
هر آنچه که مایکروسافت در جریان نطق اصلی کنفرانس بیلد 2015 معرفی کرد
فریمورک دات نت به صورت متن باز بر روی گیت هاب
فریمورک دات نت به صورت متن باز بر روی گیت هاب
در این مقاله قصد دارم راجعبه یک Extension در دات نت صحبت کنم که خیلی وقتها میتواند بسیار مفید و نجات بخش و همینطور در زمان کارتان تاثیر زیادی بگذارد. خیلی وقتها پیش آمده که داریم با یک سرویس بیرونی ارتباط برقرار میکنیم، اما هنگام فراخوانی کردن، با خطا مواجه میشویم و ما متوجه دلیل خطای رخ داده در آن لحظه نمیشویم. برای خود من بارها پیش آمده که Propertyهای اطلاعات ورودی برای وب سرویس را بصورت Pascal Case داده باشم، ولی سرویس بیرونی فقط بصورت Camel Case برای آن قابل قبول بودهاست و من بعد از ساعتها بررسی متوجه این موضوع میشدم و یا ممکن بود یک Property با مقدار نادرست ارسال میکردم و یا ممکن بود یک Property را اصلا ارسال نمیکردم و یا حتی اینکه یک Header را درست نمیفرستادم و کلی از این موضوعات که با آنها برخورد کردیم و با صرف زمان، مشکل را حل کردیم. این Extension کار ما را برای حل این مسائل خیلی راحت میکند.
حالا چطور و چگونه ازش استفاده کنیم؟!
این Extension کارش این است، وقتی HttpClient ما مقدار دهی شده و آمادهی برای ارسال درخواست به سرویس بیرونی است، میتوانیم قبل ارسال، آن را فراخوانی کنیم و یک خروجی Curl از درخواستی را که داریم میفرستیم، ببینیم. سپس خروجی Curl را در ترمینال صدا بزنیم و نتیجه را ببینیم. همینطور میتوانیم به Postman خود Import کنیم و با داکیومنتی که داده شده، بررسی کنیم و مشکل را دقیقتر بررسی کنیم.
نحوه Import کردن Curl در Postman
جای دیگری که نقش این Extension میتواند تاثیر گذار باشد، زمانی است که ما از نحوهی فراخوانی سرویسهای بیرونی خود که در سیستم نوشته شده، هیچ داکیومنت یا Postman Collection ای نداریم. ما با این Extension با خروجی Curl که در اختیارمان میگذارد، میتوانیم Collection خود را ایجاد کنیم و در اختیار هم تیمیهای خود قرار دهیم. میبینید که چقدر کارها را ساده و راحت میکند!
استفاده از این Extension بسیار ساده و سریع است و شما با نوشتن یک خط میتوانید آن را فراخوانی کنید:
حالا چطور و چگونه ازش استفاده کنیم؟!
این Extension کارش این است، وقتی HttpClient ما مقدار دهی شده و آمادهی برای ارسال درخواست به سرویس بیرونی است، میتوانیم قبل ارسال، آن را فراخوانی کنیم و یک خروجی Curl از درخواستی را که داریم میفرستیم، ببینیم. سپس خروجی Curl را در ترمینال صدا بزنیم و نتیجه را ببینیم. همینطور میتوانیم به Postman خود Import کنیم و با داکیومنتی که داده شده، بررسی کنیم و مشکل را دقیقتر بررسی کنیم.
نحوه Import کردن Curl در Postman
open the Postman -> click on the Import button -> select the Raw text tab -> paste the curl script here -> then press the Continue button -> at the end press the button import.
استفاده از این Extension بسیار ساده و سریع است و شما با نوشتن یک خط میتوانید آن را فراخوانی کنید:
آدرس Nuget Package
این Extension سه(۳) راه برای نمایش Curl دارد:
۱- چاپ در Console
پارامتر دوم، کانفیگ هست که شما میتوانید بنا به نیاز، آنها را تغییر دهید (پیش فرض آن null است). مثال و توضیحات کانفیگ به شرح زیر است:
- مقدارTurnOn پیش فرض فعال است؛ درصورت غیرفعال کردن جنریتور، غیر فعال میشود و عمل ایجاد اسکریپت را انجام نمیدهد.
- با مقدارNeedAddDefaultHeaders میتوانید مشخص کنید در صورت داشتن هدرهای پیش فرض، در خروجی Curl اضافه شود یا خیر. پیش فرض آن فعال هست.
- مقدارEnableCodeBeautification اگر فعال باشد اسکریپتهای چاپ شده در Console را به ازای هر HttpMethod، با رنگ متفاوتی نشان میدهد؛ برای خوانایی بهتر اسکریپت. بصورت پیش فرض غیر فعال است.
۲- ذخیره در فایل
پارامتر دوم کانفیگ هست که شما میتوانید بنا به نیاز، آنها را تغییر دهید (پیش فرض آن null است).
مثال و توضیحات کانفیگ به شرح زیر است:
- مقدارFilename را اگر وارد کنید، میتوانید نام فایلی را که ایجاد میشود، مشخص کنید. در صورت مقدار ندادن، پیش فرض تاریخ روز جاری را اعمال میکند. مثال: 20220910.curl
- مقدارPath را میتوانید در صورت داشتن مسیری خاص، مشخص کنید. در غیر این صورت بصورت پیش فرض اطلاعات را در مسیر ProjectDirectory\bin\Debug\netX ذخیره میکند.
- مقدارTurnOn پیش فرض آن فعال است. درصورت غیرفعال کردن جنریتور غیر فعال میشود و عمل ایجاد اسکریپت را انجام نمیدهد.
- با مقدار NeedAddDefaultHeaders میتوانید مشخص کنید در صورت داشتن هدرهای پیش فرض، در خروجی Curl اضافه شود یا خیر. پیش فرض آن فعال هست.
۳- ذخیره در متغیر
لینک آدرس GitHub پروژه جهت دیدن سورس پروژه و دیدن مثالهای بیشتر و همینطور برای دیدن قابلیتهای بیشتر این extension.
این Extension سه(۳) راه برای نمایش Curl دارد:
۱- چاپ در Console
httpClient.GenerateCurlInConsole(httpRequestMessage, null);
httpClient.GenerateCurlInConsole( httpRequestMessage, configs => { configs.TurnOn = true; configs.NeedAddDefaultHeaders = true; configs.EnableCodeBeautification = false; });
- با مقدارNeedAddDefaultHeaders میتوانید مشخص کنید در صورت داشتن هدرهای پیش فرض، در خروجی Curl اضافه شود یا خیر. پیش فرض آن فعال هست.
- مقدارEnableCodeBeautification اگر فعال باشد اسکریپتهای چاپ شده در Console را به ازای هر HttpMethod، با رنگ متفاوتی نشان میدهد؛ برای خوانایی بهتر اسکریپت. بصورت پیش فرض غیر فعال است.
۲- ذخیره در فایل
httpClient.GenerateCurlInFile(httpRequestMessage, null);
مثال و توضیحات کانفیگ به شرح زیر است:
httpClient.GenerateCurlInFile( httpRequestMessage, configs => { configs.Filename = "your filename"; configs.Path = "your path"; configs.TurnOn = true; configs.NeedAddDefaultHeaders = true; });
- مقدارPath را میتوانید در صورت داشتن مسیری خاص، مشخص کنید. در غیر این صورت بصورت پیش فرض اطلاعات را در مسیر ProjectDirectory\bin\Debug\netX ذخیره میکند.
- مقدارTurnOn پیش فرض آن فعال است. درصورت غیرفعال کردن جنریتور غیر فعال میشود و عمل ایجاد اسکریپت را انجام نمیدهد.
- با مقدار NeedAddDefaultHeaders میتوانید مشخص کنید در صورت داشتن هدرهای پیش فرض، در خروجی Curl اضافه شود یا خیر. پیش فرض آن فعال هست.
۳- ذخیره در متغیر
httpClient.GenerateCurlInString(httpRequestMessage);
لینک آدرس GitHub پروژه جهت دیدن سورس پروژه و دیدن مثالهای بیشتر و همینطور برای دیدن قابلیتهای بیشتر این extension.
خوشحال میشوم اگه نظری دارید راجع به پروژه و یا مشکلی دیدید در سورس کد به من اطلاع بدهید و خیلی خوشحال میشوم اگر در تکمیل و پیاده سازی این پروژه مشارکت کنید و اگر این پروژه براتون جذاب و یا مفید بود استار بدهید.
کد زیر را در نظر بگیرید :
به نظر شما چه چیزی در خروجی نمایش داده میشود؟
خطی که text2 تعریف شده است را تغییر میدهیم :
اما چرا در کد اولی اینگونه نبود؟
بنابراین text1 و text2 در کد اولی واقعا یکی هستند و یک نمونه برای آنها ایجاد شده است.
البته چند نکته در اینجا هست :
اگر text1 و text2 به صورت string تعریف شوند، نتیجه text1==text2 در هر دو حالت فوق برابر true است. چون عملگر == در کلاس string یکبار دیگر overload شده است:
این که کدام یک از overloadها اجرا شوند (کلاس پایه، کلاس اصلی، ...) به نوع دو متغییر اطراف == بستگی دارد. مثلا در کد زیر :
اولین نتیجه true و دومی false است. چون در اولی عملگر == تعریف شده در کلاس string مورد استفاده قرار میگیرد اما در دومی عملگر == تعریف شده در کلاس object.
اگر دقت نشود این رفتار مشکلزا میشود. مثلا حالتی را در نظر بگیرید که text1 ورودی کاربر است و text2 از بانک اطلاعاتی خوانده شده است و با اینکه مقادیر یکسان دارند نتیجه == آنها false است. اگر تعریف عملگرها در کلاس object به صورت virtual بود و در کلاسهای دیگر override میشد، این تغییر نوعها تاثیری نداشت. اما عملگرها به صورت static تعریف میشوند و امکان override شدن ندارند. به همین خاطر کلاس object متدی به اسم Equals در اختیار گذاشته که کلاسها آنرا override میکنند و معمولا از این متد برای سنجش برابری دو کلاس استفاده میشود :
object text1 = "test"; object text2 = "test"; object num1 = 1; object num2 = 1; Console.WriteLine("text1 == text2 : " + (text1 == text2)); Console.WriteLine("num1 == num2 : " + (num1 == num2));
به نظر شما چه چیزی در خروجی نمایش داده میشود؟
هر چهار متغییر text1 و text2 و num1 و num2 از نوع object هستند. با اینکه مقدار text1 و text2 یکی و مقدار num1 و num2 هم یکی است، نتیجه text1==text2 برابر true است اما num1==num2 برابر false.
خطی که text2 تعریف شده است را تغییر میدهیم :
object text2 = "test".ToLower();
اینبار با این که باز مقدار text1 و text2 یکی و هر دو "test" است، اما نتیجه text1==text2 برابر false است. انتظار ما هم همین است. دو object ایجاد شده است و یکی نیستند. تنها در صورتی باید نتیجه == آنها true باشد که هر دو به یک object اشاره کنند.
اما چرا در کد اولی اینگونه نبود؟
دلیل این کار برمیگردد به رفتار داتنت نسبت به رشتههایی که به صورت صریح در برنامه تعریف میشوند. CLR یک جدول برای ذخیره رشتهها به نام intern pool برای برنامه میسازد. هر رشتهای تعریف میشود، اگر در intern pool رشتهای با همان مقدار وجود نداشته باشد، یک رشته جدید ایجاد و به جدول اضافه میشود، و اگر موجود باشد متغییر جدید فقط به آن اشاره میکند. در واقع اگر 100 جای برنامه حتی در کلاسهای مختلف، رشتههایی با مقادیر یکسان وجود داشته باشند، برای همه آنها یک نمونه وجود دارد.
بنابراین text1 و text2 در کد اولی واقعا یکی هستند و یک نمونه برای آنها ایجاد شده است.
البته چند نکته در اینجا هست :
اگر text1 و text2 به صورت string تعریف شوند، نتیجه text1==text2 در هر دو حالت فوق برابر true است. چون عملگر == در کلاس string یکبار دیگر overload شده است:
public sealed class String : ... { ... public static bool operator ==(string a, string b) { return string.Equals(a, b); } ... }
این که کدام یک از overloadها اجرا شوند (کلاس پایه، کلاس اصلی، ...) به نوع دو متغییر اطراف == بستگی دارد. مثلا در کد زیر :
string text1 = "test"; string text2 = "test".ToLower(); Console.WriteLine("text1 == text2 (string) : " + (text1 == text2)); Console.WriteLine("text1 == text2 (object) : " + ((object)text1 == (object)text2));
اولین نتیجه true و دومی false است. چون در اولی عملگر == تعریف شده در کلاس string مورد استفاده قرار میگیرد اما در دومی عملگر == تعریف شده در کلاس object.
اگر دقت نشود این رفتار مشکلزا میشود. مثلا حالتی را در نظر بگیرید که text1 ورودی کاربر است و text2 از بانک اطلاعاتی خوانده شده است و با اینکه مقادیر یکسان دارند نتیجه == آنها false است. اگر تعریف عملگرها در کلاس object به صورت virtual بود و در کلاسهای دیگر override میشد، این تغییر نوعها تاثیری نداشت. اما عملگرها به صورت static تعریف میشوند و امکان override شدن ندارند. به همین خاطر کلاس object متدی به اسم Equals در اختیار گذاشته که کلاسها آنرا override میکنند و معمولا از این متد برای سنجش برابری دو کلاس استفاده میشود :
object text1 = "test"; object text2 = "test".ToLower(); Console.WriteLine("text1 Equals text2 : " + text1.Equals(text2)); Console.WriteLine("text1 Equals text2 : " + object.Equals(text1, text2));
البته یادآور میشوم که فقط رشتههایی که به صورت صریح در برنامه تعریف شدهاند، در intern pool قرار میگیرند و این فهرست شامل رشتههایی که از فایل یا بانک اطلاعاتی خوانده میشوند یا در برنامه تولید میشوند، نیست. این کار منطقی است وگرنه حافظه زیادی مصرف خواهد شد.
با استفاده از متد string.Intern میتوان یک رشته را که در intern pool وجود ندارد، به فهرست آن افزود. اگر رشته در intern pool وجود داشته باشد، reference آنرا بر میگرداند در غیر اینصورت یک reference به رشته جدید به intern pool اضافه میکند و آنرا برمیگرداند.
یک مورد استفاده آن هنگام lock روی رشتههاست. برای مثال در کد زیر DeviceId یک رشته است که از بانک اطلاعاتی خوانده میشود و باعث میشود که چند job همزمان به یک دستگاه وصل نشوند :
یک مورد استفاده آن هنگام lock روی رشتههاست. برای مثال در کد زیر DeviceId یک رشته است که از بانک اطلاعاتی خوانده میشود و باعث میشود که چند job همزمان به یک دستگاه وصل نشوند :
lock (job.DeviceId) { job.Execute(); }
اگر یک job با DeviceId برابر COM1 در حال اجرا باشد، این lock جلوی اجرای همزمان job دیگری با همین DeviceId را نمیگیرد. زیرا هر چند مقدار DeviceId دو job یکی است ولی به یک نمونه اشاره نمیکنند.
میتوان lock را اینگونه اصلاح کرد :
میتوان lock را اینگونه اصلاح کرد :
lock (string.Intern(job.DeviceId)) { job.Execute(); }