डिस्पोजेबल पैटर्न (डिस्पोजेबल डिजाइन सिद्धांत)

मुझे लगता है कि लगभग कोई भी प्रोग्रामर जो .NET का उपयोग करता है, अब कहेगा कि यह पैटर्न केक का एक टुकड़ा है। यह मंच पर उपयोग किया जाने वाला सबसे प्रसिद्ध पैटर्न है। हालांकि, यहां तक ​​कि सबसे सरल और प्रसिद्ध समस्या डोमेन में गुप्त क्षेत्र होंगे, जिन्हें आपने कभी नहीं देखा है। तो, चलो पहले-टाइमर और बाकी सभी (ताकि आप में से प्रत्येक मूल बातें याद कर सकें) के लिए शुरुआत से पूरी बात का वर्णन करें। इन अनुच्छेदों को मत छोड़ो - मैं तुम्हें देख रहा हूँ!

अगर मैं पूछता हूं कि आईडीडीसोपायिक क्या है, तो आप निश्चित रूप से कहेंगे कि यह है

public interface IDisposable { void Dispose(); } 

इंटरफ़ेस का उद्देश्य क्या है? मेरा मतलब है, अगर हम एक स्मार्ट कचरा संग्रहकर्ता है जो हमारे बजाय स्मृति को साफ करता है, तो हमें मेमोरी को साफ करने की आवश्यकता क्यों है, इसलिए हमें इसके बारे में सोचने की ज़रूरत नहीं है। हालांकि, कुछ छोटे विवरण हैं।

यह अध्याय रूसी से संयुक्त रूप से लेखक द्वारा और पेशेवर अनुवादकों द्वारा अनुवादित किया गया था । आप रूसी या अंग्रेजी से किसी अन्य भाषा में अनुवाद करने में हमारी मदद कर सकते हैं, मुख्यतः चीनी या जर्मन में।

इसके अलावा, यदि आप हमें धन्यवाद देना चाहते हैं, तो आप सबसे अच्छा तरीका यह कर सकते हैं कि हमें गितुब पर एक स्टार देना है या रिपॉजिटरी को फोर्क करना है github / sidristij / dotnetbook ।

एक ग़लतफ़हमी है कि IDisposable मानव रहित संसाधनों को जारी IDisposable काम करता है। यह केवल आंशिक रूप से सच है और इसे समझने के लिए, आपको बस मानव रहित संसाधनों के उदाहरणों को याद रखने की आवश्यकता है। क्या File वर्ग एक अप्रबंधित संसाधन है? नहीं। शायद DbContext एक अप्रबंधित संसाधन है? नहीं, फिर से। एक अप्रबंधित संसाधन कुछ ऐसा है जो .NET टाइप सिस्टम से संबंधित नहीं है। कुछ ऐसा मंच नहीं बना, जो कुछ इसके दायरे से बाहर हो। एक साधारण उदाहरण एक ऑपरेटिंग सिस्टम में एक खोला फ़ाइल हैंडल है। एक हैंडल एक संख्या है जो विशिष्ट रूप से खोली गई फ़ाइल को पहचानती है - नहीं, आपके द्वारा नहीं - एक ऑपरेटिंग सिस्टम द्वारा। अर्थात्, सभी नियंत्रण संरचनाएं (उदाहरण के लिए फ़ाइल सिस्टम में फ़ाइल की स्थिति, विखंडन और अन्य सेवा की जानकारी के मामले में फ़ाइल टुकड़े, एक सिलेंडर की संख्या, एक सिर या एक HDD का क्षेत्र) एक ओएस के अंदर हैं, लेकिन नहीं .NET मंच। .NET प्लेटफ़ॉर्म पर पास किया गया एकमात्र अप्रबंधित संसाधन IntPtr संख्या है। यह संख्या FileSafeHandle द्वारा लिपटी हुई है, जो कि फाइल वर्ग द्वारा लिपटे अपनी बारी में है। इसका मतलब है कि फ़ाइल वर्ग अपने आप में एक अप्रबंधित संसाधन नहीं है, लेकिन एक अप्रबंधित संसाधन को शामिल करने के लिए IntPtr के रूप में एक अतिरिक्त परत का उपयोग करता है - एक खुली हुई फ़ाइल का संभाल। आप उस फाइल को कैसे पढ़ते हैं? WinAPI या Linux OS में विधियों का एक सेट का उपयोग करना।

मल्टीथ्रेडेड या मल्टीप्रोसेसर प्रोग्राम्स में सिंक्रोनाइज़ेशन प्राइमेटिव्स अप्रबंधित संसाधनों का दूसरा उदाहरण हैं। यहाँ डेटा सरणियाँ हैं जो P / Invoke से गुजरती हैं और म्यूटेक्स या सेमाफोर भी हैं।

ध्यान दें कि OS किसी अनुप्रयोग के लिए अप्रबंधित संसाधन के हैंडल को केवल पास नहीं करता है। यह प्रक्रिया द्वारा खोले गए हैंडल की तालिका में उस हैंडल को भी बचाता है। इस प्रकार, ओएस एप्लिकेशन समाप्ति के बाद संसाधनों को सही ढंग से बंद कर सकता है। यह सुनिश्चित करता है कि आपके आवेदन से बाहर निकलने के बाद संसाधन वैसे भी बंद रहेंगे। हालांकि, किसी एप्लिकेशन का रनिंग टाइम अलग-अलग हो सकता है जो लंबे संसाधन लॉकिंग का कारण बन सकता है।

ठीक है। अब हमने मानव रहित संसाधनों को कवर किया। हमें इन मामलों में आईडीसिसोपयोगी उपयोग करने की आवश्यकता क्यों है? क्योंकि .NET फ्रेमवर्क का कोई पता नहीं है कि इसके क्षेत्र के बाहर क्या हो रहा है। यदि आप OS API का उपयोग करके कोई फ़ाइल खोलते हैं, तो .NET को इसके बारे में कुछ नहीं पता होगा। यदि आप अपनी खुद की जरूरतों के लिए एक मेमोरी रेंज आवंटित करते हैं (उदाहरण के लिए VirtualAlloc का उपयोग करके), .NET को भी कुछ नहीं पता होगा। यदि यह नहीं पता है, यह एक VirtualAlloc कॉल द्वारा कब्जा की गई मेमोरी जारी नहीं करेगा। या, यह ओएस एपीआई कॉल के माध्यम से सीधे खोली गई फ़ाइल को बंद नहीं करेगा। ये अलग और अप्रत्याशित परिणाम पैदा कर सकते हैं। यदि आप इसे जारी किए बिना बहुत अधिक मेमोरी आवंटित करते हैं तो आप आउटऑफमैमोरी प्राप्त कर सकते हैं (उदाहरण के लिए केवल एक संकेतक को शून्य करने के लिए)। या, यदि आप ओएस के माध्यम से एक फ़ाइल साझा पर फ़ाइल को बिना बंद किए खोलते हैं, तो आप फ़ाइल को लंबे समय तक उस फ़ाइल साझा पर लॉक कर देंगे। फ़ाइल साझा उदाहरण विशेष रूप से अच्छा है क्योंकि जब आप किसी सर्वर के साथ कनेक्शन बंद करते हैं तो भी IIS की तरफ लॉक रहेगा। आपके पास लॉक जारी करने के अधिकार नहीं हैं और आपको विशेष सॉफ्टवेयर का उपयोग करके व्यवस्थापकों से iisreset या मैन्युअल रूप से संसाधन बंद करने के लिए कहना होगा।
एक दूरस्थ सर्वर पर यह समस्या हल करने के लिए एक जटिल कार्य बन सकता है।

इन सभी मामलों को एक प्रकार की प्रणाली और एक प्रोग्रामर के बीच बातचीत के लिए एक सार्वभौमिक और परिचित प्रोटोकॉल की आवश्यकता होती है। यह उन प्रकारों को स्पष्ट रूप से पहचानना चाहिए जिन्हें जबरन बंद करने की आवश्यकता होती है। आईडीसोपायरी इंटरफ़ेस बिल्कुल इसी उद्देश्य को पूरा करता है। यह निम्नलिखित तरीके से कार्य करता है: यदि किसी प्रकार में आईडीसॉरोफ़िक इंटरफ़ेस का कार्यान्वयन होता है, तो आपको उस प्रकार की आवृत्ति के साथ काम समाप्त करने के बाद डिस्पोज़ () कॉल करना होगा।

तो, इसे कॉल करने के दो मानक तरीके हैं। आमतौर पर आप इसे एक विधि के भीतर या इकाई उदाहरण के जीवनकाल के भीतर जल्दी से उपयोग करने के लिए एक इकाई उदाहरण बनाते हैं।

पहला तरीका किसी उदाहरण को using(...){ ... } लपेटना है। इसका अर्थ है कि आप उपयोग-संबंधी ब्लॉक के समाप्त होने के बाद किसी वस्तु को नष्ट करने का निर्देश देते हैं, अर्थात डिस्पोज को बुलाने के लिए ()। दूसरा तरीका ऑब्जेक्ट को नष्ट करना है, जब इसका जीवनकाल खत्म हो जाता है, तो उस ऑब्जेक्ट के संदर्भ में जिसे हम जारी करना चाहते हैं। लेकिन .NET के पास एक अंतिम विधि के अलावा कुछ भी नहीं है जो किसी वस्तु के स्वत: नष्ट होने का अर्थ है, है ना? हालाँकि, अंतिम रूप देना उचित नहीं है क्योंकि हम नहीं जानते कि इसे कब बुलाया जाएगा। इस बीच, हमें एक निश्चित समय पर एक ऑब्जेक्ट जारी करने की आवश्यकता है, उदाहरण के लिए, जब हम एक खुली फाइल के साथ काम खत्म करते हैं। यही कारण है कि हमें अपने स्वामित्व वाले सभी संसाधनों को जारी करने के लिए आईडीसिसोपयोगी और कॉल डिस्पोज़ को लागू करने की भी आवश्यकता है। इस प्रकार, हम प्रोटोकॉल का पालन करते हैं , और यह बहुत महत्वपूर्ण है। क्योंकि अगर कोई इसका अनुसरण करता है, तो सभी प्रतिभागियों को समस्याओं से बचने के लिए ऐसा ही करना चाहिए।

आईडीसोपायरी को लागू करने के विभिन्न तरीके

आइए सरल से जटिल तक आइडिसोप्रयोग के कार्यान्वयन को देखें। IDis प्रयोज्य का उपयोग करना सबसे पहला और सरल तरीका है:

 public class ResourceHolder : IDisposable { DisposableResource _anotherResource = new DisposableResource(); public void Dispose() { _anotherResource.Dispose(); } } 

यहाँ, हम एक संसाधन का एक उदाहरण बनाते हैं जो आगे डिस्पोज़ () द्वारा जारी किया जाता है। केवल एक चीज जो इस कार्यान्वयन को असंगत बनाती है, वह यह है कि आप अभी भी इसके Dispose() बाद उदाहरण के साथ काम कर सकते हैं Dispose() :

 public class ResourceHolder : IDisposable { private DisposableResource _anotherResource = new DisposableResource(); private bool _disposed; public void Dispose() { if(_disposed) return; _anotherResource.Dispose(); _disposed = true; } [MethodImpl(MethodImplOptions.AggressiveInlining)] private void CheckDisposed() { if(_disposed) { throw new ObjectDisposedException(); } } } 

CheckDisposed () को एक वर्ग के सभी सार्वजनिक तरीकों में पहली अभिव्यक्ति के रूप में कहा जाना चाहिए। प्राप्त ResourceHolder श्रेणी संरचना एक अप्रबंधित संसाधन को नष्ट करने के लिए अच्छी लगती है, जो कि DisposableResource । हालांकि, यह संरचना एक लिपटे हुए मानव रहित संसाधन के लिए उपयुक्त नहीं है। आइए एक अप्रबंधित संसाधन के साथ उदाहरण देखें।

 public class FileWrapper : IDisposable { IntPtr _handle; public FileWrapper(string name) { _handle = CreateFile(name, 0, 0, 0, 0, 0, IntPtr.Zero); } public void Dispose() { CloseHandle(_handle); } [DllImport("kernel32.dll", EntryPoint = "CreateFile", SetLastError = true)] private static extern IntPtr CreateFile(String lpFileName, UInt32 dwDesiredAccess, UInt32 dwShareMode, IntPtr lpSecurityAttributes, UInt32 dwCreationDisposition, UInt32 dwFlagsAndAttributes, IntPtr hTemplateFile); [DllImport("kernel32.dll", SetLastError=true)] private static extern bool CloseHandle(IntPtr hObject); } 

पिछले दो उदाहरणों के व्यवहार में क्या अंतर है? पहले वाला दो प्रबंधित संसाधनों की परस्पर क्रिया का वर्णन करता है। इसका मतलब है कि यदि कोई प्रोग्राम सही तरीके से काम करता है, तो संसाधन वैसे भी जारी किया जाएगा। चूंकि DisposableResource प्रबंधित होता है, .NET CLR इसके बारे में जानता है और यदि इसका व्यवहार गलत है, तो इससे मेमोरी रिलीज़ करेगा। ध्यान दें कि मैं सचेत रूप से यह नहीं मानता हूं कि DisposableResource सोर्स क्या टाइप करता है। किसी भी तरह का तर्क और ढांचा हो सकता है। इसमें प्रबंधित और अप्रबंधित दोनों संसाधन हो सकते हैं। यह हमें बिल्कुल चिंता नहीं करनी चाहिए । कोई भी हमें हर बार तीसरे पक्ष के पुस्तकालयों को विघटित करने के लिए नहीं कहता है और देखें कि वे प्रबंधित या अप्रबंधित संसाधनों का उपयोग करते हैं या नहीं। और यदि हमारा प्रकार अप्रबंधित संसाधन का उपयोग करता है, तो हम इससे अनभिज्ञ नहीं हो सकते। हम FileWrapper वर्ग में ऐसा करते हैं। तो, इस मामले में क्या होता है? यदि हम अप्रबंधित संसाधनों का उपयोग करते हैं, तो हमारे पास दो परिदृश्य हैं। पहला है जब सबकुछ ठीक है और डिस्पोजल कहा जाता है। दूसरा वह है जब कुछ गलत होता है और डिस्पोज फेल हो जाता है।

आइए सीधे कहते हैं कि यह गलत क्यों हो सकता है:

• यदि हम using(obj) { ... } उपयोग using(obj) { ... } , तो कोड के एक आंतरिक ब्लॉक में एक अपवाद दिखाई दे सकता है। यह अपवाद finally ब्लॉक द्वारा पकड़ा जाता है, जिसे हम नहीं देख सकते हैं (यह सी # का सिंथेटिक चीनी है)। इस ब्लॉक को डिस्पोज़ली रूप से डिस्पोज़ किया जाता है। हालाँकि, ऐसे मामले हैं जब ऐसा नहीं होता है। उदाहरण के लिए, न तो catch और न ही finally StackOverflowException को StackOverflowException । आपको यह हमेशा याद रखना चाहिए। क्योंकि यदि कुछ थ्रेड पुनरावर्ती हो जाते हैं और StackOverflowException कुछ बिंदु पर होती है, तो .NET उन संसाधनों के बारे में भूल जाएगा जो इसे उपयोग करते हैं लेकिन जारी किए गए हैं। यह पता नहीं है कि मानव रहित संसाधनों को कैसे जारी किया जाए। वे तब तक मेमोरी में रहेंगे जब तक ओएस उन्हें जारी नहीं करता, यानी जब आप किसी प्रोग्राम से बाहर निकलते हैं, या किसी एप्लिकेशन के समापन के कुछ समय बाद भी।
• अगर हम Dispose () को दूसरे Dispose () से कहते हैं। फिर, हम इसे प्राप्त करने में विफल हो सकते हैं। यह अनुपस्थित दिमाग वाले ऐप डेवलपर का मामला नहीं है, जो डिस्पोज़ () को कॉल करना भूल गया। यह अपवादों का सवाल है। हालांकि, ये केवल अपवाद नहीं हैं जो किसी एप्लिकेशन के थ्रेड को क्रैश करते हैं। यहां हम उन सभी अपवादों के बारे में बात करते हैं जो एक एल्गोरिथ्म को बाहरी डिस्पोज़ () को कॉल करने से रोकेंगे जो हमारे डिस्पोज़ () को कॉल करेंगे।

ये सभी मामले निलंबित अप्रबंधित संसाधनों का निर्माण करेंगे। इसका कारण यह है कि कचरा संग्रहकर्ता को यह नहीं पता है कि यह उन्हें इकट्ठा करना चाहिए। अगले चेक पर यह सब पता चल सकता है कि हमारे FileWrapper प्रकार के साथ किसी ऑब्जेक्ट ग्राफ का अंतिम संदर्भ खो गया है। इस मामले में, मेमोरी को संदर्भों के साथ वस्तुओं के लिए फिर से विभाजित किया जाएगा। हम इसे कैसे रोक सकते हैं?

हमें किसी वस्तु के अंतिम रूप को लागू करना चाहिए। The फाइनल ’का नाम इस तरह रखा गया है। यह विध्वंसक नहीं है क्योंकि C # में अंतिम रूप से कॉल करने के समान तरीकों और C ++ में विध्वंसक के कारण ऐसा लग सकता है। अंतर यह है कि एक अंतिम रूप से वैसे भी कहा जाएगा, एक विध्वंसक (साथ ही Dispose() विपरीत। कचरा संग्रहण शुरू होने पर एक अंतिम रूप से कहा जाता है (अब यह जानने के लिए पर्याप्त है, लेकिन चीजें थोड़ी अधिक जटिल हैं)। इसका उपयोग संसाधनों की गारंटीकृत रिहाई के लिए किया जाता है यदि कुछ गलत हो जाता है । हमें मानवरहित संसाधनों को जारी करने के लिए एक अंतिम रूप देना चाहिए । फिर से, क्योंकि GC को शुरू करने पर एक अंतिम रूप से कहा जाता है, हम नहीं जानते कि यह सामान्य रूप से कब होता है।

चलो हमारे कोड का विस्तार करें:

 public class FileWrapper : IDisposable { IntPtr _handle; public FileWrapper(string name) { _handle = CreateFile(name, 0, 0, 0, 0, 0, IntPtr.Zero); } public void Dispose() { InternalDispose(); GC.SuppressFinalize(this); } private void InternalDispose() { CloseHandle(_handle); } ~FileWrapper() { InternalDispose(); } /// other methods } 

हमने अंतिम रूप देने की प्रक्रिया के बारे में जानकारी के साथ उदाहरण को बढ़ाया और संसाधन जानकारी खोने के खिलाफ आवेदन सुरक्षित किया अगर डिस्पोज () नहीं कहा जाता है। हमें GC भी कहा जाता है। अगर डिस्पोज़ () को सफलतापूर्वक कहा जाता है, तो उस प्रकार के उदाहरण को अंतिम रूप देने के लिए दबाएं। एक ही संसाधन को दो बार जारी करने की आवश्यकता नहीं है, है ना? इस प्रकार, हम कोड के एक यादृच्छिक क्षेत्र को भी जाने देते हैं जो समानांतर में अंतिमकरण के साथ चलने की संभावना है, कुछ समय बाद अंतिमकरण कतार को कम करते हैं। अब, उदाहरण को और भी बढ़ाते हैं।

 public class FileWrapper : IDisposable { IntPtr _handle; bool _disposed; public FileWrapper(string name) { _handle = CreateFile(name, 0, 0, 0, 0, 0, IntPtr.Zero); } public void Dispose() { if(_disposed) return; _disposed = true; InternalDispose(); GC.SuppressFinalize(this); } [MethodImpl(MethodImplOptions.AggressiveInlining)] private void CheckDisposed() { if(_disposed) { throw new ObjectDisposedException(); } } private void InternalDispose() { CloseHandle(_handle); } ~FileWrapper() { InternalDispose(); } /// other methods } 

अब एक अप्रबंधित संसाधन को इनकैप करने वाले एक प्रकार का हमारा उदाहरण पूर्ण दिखता है। दुर्भाग्य से, दूसरा Dispose() वास्तव में मंच का एक मानक है और हम इसे कॉल करने की अनुमति देते हैं। ध्यान दें कि लोग अक्सर कॉलिंग कोड की समस्याओं से बचने के लिए Dispose() की दूसरी कॉल की अनुमति देते हैं और यह गलत है। हालाँकि, आपके पुस्तकालय का एक उपयोगकर्ता जो MS प्रलेखन को देखता है, वह ऐसा नहीं सोच सकता है और डिस्पोज़ () के कई कॉल की अनुमति देगा। अन्य सार्वजनिक तरीकों को कॉल करने से किसी भी वस्तु की अखंडता नष्ट हो जाएगी। यदि हमने ऑब्जेक्ट को नष्ट कर दिया है, तो हम इसके साथ काम नहीं कर सकते। इसका मतलब है कि हमें प्रत्येक सार्वजनिक पद्धति की शुरुआत में CheckDisposed कॉल करना होगा।

हालांकि, इस कोड में एक गंभीर समस्या है जो इसे काम करने से रोकती है जैसा कि हमने इरादा किया था। यदि हमें याद है कि कचरा संग्रह कैसे काम करता है, तो हम एक विशेषता को नोटिस करेंगे। कचरा इकट्ठा करते समय, जीसी मुख्य रूप से ऑब्जेक्ट से सीधे विरासत में मिली हर चीज को अंतिम रूप देता है । इसके बाद यह उन वस्तुओं से संबंधित है जो क्रिटिकल फ़ाइनलीज़रऑबजेक्ट को लागू करते हैं। यह दोनों वर्गों के लिए एक समस्या बन जाती है जिसे हमने इनहेरिट ऑब्जेक्ट को डिज़ाइन किया है। हम नहीं जानते कि वे किस क्रम में "अंतिम मील" पर आएंगे। हालाँकि, एक उच्च-स्तरीय ऑब्जेक्ट किसी अनवांटेड संसाधन के साथ किसी ऑब्जेक्ट को अंतिम रूप देने के लिए अपने अंतिम रूप का उपयोग कर सकता है। हालांकि, यह एक महान विचार की तरह नहीं है। अंतिम रूप देने का क्रम यहाँ बहुत मददगार होगा। इसे सेट करने के लिए, कम-स्तरीय प्रकार एक एन्कैप्सुलेटेड अनवांटेड संसाधन के साथ CriticalFinalizerObject से विरासत में मिला होना चाहिए।

दूसरा कारण अधिक गहरा है। कल्पना कीजिए कि आपने एक ऐसा एप्लिकेशन लिखने की हिम्मत की है जो स्मृति का अधिक ध्यान नहीं रखता है। यह कैशिंग और अन्य सूक्ष्मताओं के बिना, भारी मात्रा में स्मृति आवंटित करता है। एक दिन यह एप्लिकेशन OutOfMemoryException के साथ क्रैश हो जाएगा। जब ऐसा होता है, तो कोड विशेष रूप से चलता है। यह कुछ भी आवंटित नहीं कर सकता है, क्योंकि यह दोहराया अपवाद को जन्म देगा, भले ही पहले वाला पकड़ा जाए। इसका मतलब यह नहीं है कि हमें वस्तुओं के नए उदाहरण नहीं बनाने चाहिए। यहां तक ​​कि एक सरल विधि कॉल इस अपवाद को फेंक सकती है, उदाहरण के लिए अंतिम रूप देना। मैं आपको याद दिलाता हूं कि जब आप उन्हें पहली बार कॉल करते हैं तो तरीके संकलित होते हैं। यह सामान्य व्यवहार है। हम इस समस्या को कैसे रोक सकते हैं? काफी आसानी से। यदि आपकी ऑब्जेक्ट क्रिटिकल फ़ाइनलीज़रऑबजेक्ट से विरासत में मिली है, तो इस प्रकार के सभी तरीकों को मेमोरी में लोड करने पर सीधे संकलित किया जाएगा। इसके अलावा, यदि आप [PrePrepareMethod] विशेषता के साथ तरीकों को चिह्नित करते हैं, तो वे पूर्व-संकलित भी होंगे और कम संसाधन स्थिति में कॉल करने के लिए सुरक्षित होंगे।

वह महत्वपूर्ण क्यों है? जो लोग गुजर जाते हैं उन पर बहुत अधिक प्रयास क्यों करते हैं? क्योंकि अप्रबंधित संसाधनों को लंबे समय तक एक प्रणाली में निलंबित किया जा सकता है। कंप्यूटर को पुनरारंभ करने के बाद भी। यदि कोई उपयोगकर्ता आपके एप्लिकेशन में फ़ाइल साझा से एक फ़ाइल खोलता है, तो पूर्व को दूरस्थ होस्ट द्वारा लॉक किया जाएगा और टाइमआउट पर जारी किया जाएगा या जब आप फ़ाइल को बंद करके एक संसाधन जारी करेंगे। यदि फ़ाइल खोलने पर आपका एप्लिकेशन क्रैश हो जाता है, तो इसे रिबूट के बाद भी जारी नहीं किया जाएगा। जब तक रिमोट होस्ट इसे जारी नहीं करता तब तक आपको लंबा इंतजार करना होगा। इसके अलावा, आपको फाइनल में अपवादों की अनुमति नहीं देनी चाहिए। यह CLR और एप्लिकेशन के त्वरित क्रैश की ओर जाता है, क्योंकि आप कोशिश करने वाले में अंतिम रूप से कॉल को नहीं पकड़ सकते ... कैच । मेरा मतलब है, जब आप किसी संसाधन को जारी करने की कोशिश करते हैं, तो आपको यह सुनिश्चित करना चाहिए कि इसे जारी किया जा सकता है। अंतिम लेकिन कम महत्वपूर्ण तथ्य नहीं: यदि CLR असामान्य रूप से एक डोमेन को लोड करता है, तो CriticalFinalizerObject से प्राप्त किए गए प्रकारों के अंतिम रूप को भी कहा जाएगा, जो ऑब्जेक्ट से सीधे विरासत में मिला है।

यह अनुवादक पेशेवर अनुवादकों द्वारा लेखक की भाषा से रूसी से अनुवादित है । आप स्रोत के रूप में पाठ के रूसी और अंग्रेजी संस्करणों का उपयोग करके चीनी या जर्मन सहित किसी भी अन्य भाषा में इस पाठ के अनुवादित संस्करण बनाने में हमारी सहायता कर सकते हैं।

इसके अलावा, यदि आप "धन्यवाद" कहना चाहते हैं, तो सबसे अच्छा तरीका जो आप चुन सकते हैं, वह हमें जीथब या रिपॉजिटरी पर एक स्टार दे रहा है। https://github.com/sidristij/dotnetbook