🅰️ 📙 🐃 आईडी-प्रयोज्य - कि आपकी माँ ने संसाधनों को मुक्त करने के बारे में बात नहीं की। भाग 1 🚵🏾 🧔🏽 💎

यह लेख के पहले भाग का अनुवाद है। लेख 2008 में लिखा गया था। 10 वर्षों के बाद, लगभग अपनी प्रासंगिकता खो दी।

संसाधनों की निर्धारक रिलीज - एक आवश्यकता

20 से अधिक वर्षों के कोडिंग अनुभव के दौरान, मैंने कभी-कभी समस्याओं को हल करने के लिए अपनी भाषाओं को विकसित किया। वे सरल, अनिवार्य भाषाओं से लेकर पेड़ों के लिए विशेष नियमित अभिव्यक्तियों तक थे। भाषा बनाते समय, कई सिफारिशें हैं और कुछ सरल नियमों का उल्लंघन नहीं किया जाना चाहिए। उनमें से एक:

कभी भी एक अपवाद भाषा न बनाएं जिसमें संसाधनों की कोई निर्धारक रिहाई न हो।

लगता है कि .NET रनटाइम किन सिफारिशों का पालन नहीं करता है, और परिणामस्वरूप, इसके आधार पर सभी भाषाएं?

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

.NET Finalize विधि का उपयोग करके संसाधनों के गैर-निर्धारक रिलीज का समर्थन करता है, जिसका विशेष अर्थ है। संसाधनों के निर्धारक जारी करने के लिए, Microsoft ने IDisposable इंटरफ़ेस (और अन्य कक्षाएं, जिन्हें हम बाद में चर्चा करेंगे) भी जोड़ा। फिर भी, रनटाइम के लिए IDisposable एक सामान्य इंटरफ़ेस है, जैसे हर कोई। "दूसरी-दर" की यह स्थिति कुछ कठिनाइयों का निर्माण करती है।

C # में, "गरीबों के लिए निर्धारक रिलीज" को try और finally try या using करके लागू किया जा सकता है (जो लगभग एक ही बात है)। Microsoft लंबे समय से चर्चा कर रहा है कि क्या लिंक मायने रखता है या नहीं, और यह मुझे लगता है कि गलत निर्णय लिया गया था। नतीजतन, संसाधनों के निर्धारक रिलीज के लिए, आपको finally निर्माणों using उपयोग करते हुए अनाड़ी \ _ का उपयोग करने की आवश्यकता होती है या IDisposable.Dispose एक सीधा कॉल होता है, जो त्रुटियों से भरा होता है। एक C ++ प्रोग्रामर के लिए, जो shared_ptr<T> का उपयोग करने के लिए उपयोग किया जाता है shared_ptr<T> दोनों विकल्प आकर्षक नहीं हैं। (अंतिम वाक्य स्पष्ट करता है कि लेखक का ऐसा संबंध कहां है - लगभग।

IDisposable

आईडीसोफाइल मिसोफ़रो द्वारा प्रस्तावित संसाधनों के निर्धारक रिलीज के लिए एक समाधान है। एक निम्नलिखित मामलों के लिए है:

किसी भी प्रकार का जो प्रबंधित ( IDisposable ) संसाधनों का मालिक है । एक प्रकार का आवश्यक रूप से स्वयं का होना चाहिए, अर्थात्, जीवन समय, संसाधनों का प्रबंधन करें, न कि केवल उन्हें देखें।
कोई भी प्रकार जो अप्रबंधित संसाधनों का मालिक है।
कोई भी प्रकार जो प्रबंधित और अप्रबंधित दोनों संसाधनों का मालिक है।
किसी भी प्रकार को एक वर्ग से विरासत में मिला है जो IDisposable लागू करता है। मैं उन वर्गों से विरासत में मिलने की सिफारिश नहीं करता जो स्वयं के अप्रबंधित संसाधन हैं। बेहतर लगाव का उपयोग करें।

IDisposable संसाधनों को निर्धारक रूप से मुक्त IDisposable मदद करता है, लेकिन इसकी अपनी समस्याएं हैं।

मुश्किलें IDisposable - प्रयोज्यता

काफी बोझिल वस्तुओं IDisposable उपयोग IDisposable लिए IDisposable ऑब्जेक्ट IDisposable हैं। एक using एक निर्माण में लिपटे होना चाहिए। बुरी खबर यह है कि सी # एक प्रकार के साथ उपयोग using अनुमति नहीं देता है जो IDisposable लागू नहीं करता है। इसलिए, प्रोग्रामर को यह समझने के लिए कि क्या using करना लिखना आवश्यक है, या बस हर जगह using using लिखना आवश्यक है, और फिर कंपाइलर शपथ लेता है, यह समझने के लिए प्रोग्रामर को हर बार संदर्भित करना चाहिए।

प्रबंधित C ++ इस संबंध में बहुत बेहतर है। यह संदर्भ प्रकारों के लिए स्टैक सेमेंटिक्स का समर्थन करता है, जो केवल उन प्रकारों के लिए using करता है जहां आवश्यक हो। C # किसी भी प्रकार के साथ लिखने की क्षमता से लाभान्वित हो सकता है।

इस समस्या को हल किया जा सकता है। कोड विश्लेषण उपकरण। मामलों को बदतर बनाने के लिए, यदि आप उपयोग करना भूल जाते हैं, तो कार्यक्रम परीक्षणों को पारित कर सकता है, लेकिन "खेतों में" काम करते समय दुर्घटना हो सकती है।

लिंक को गिनने के बजाय, IDisposable की एक और समस्या है - मालिक का निर्धारण करना। जब C ++ में shared_ptr<T> की अंतिम प्रतिलिपि कार्यक्षेत्र से बाहर हो जाती है, तो संसाधनों को तुरंत मुक्त कर दिया जाता है, यह सोचने की कोई आवश्यकता नहीं है कि वे कैसे मुक्त हैं। IDisposable इसके विपरीत, प्रोग्रामर को यह निर्धारित करने के लिए मजबूर करता है कि कौन वस्तु का "मालिक" है और इसे जारी करने के लिए जिम्मेदार है। कभी-कभी स्वामित्व स्पष्ट होता है: जब एक वस्तु दूसरे को IDisposable और खुद ही IDisposable लागू कर देती है, इसलिए यह बाल वस्तुओं की रिहाई के लिए जिम्मेदार होता है। कभी-कभी किसी ऑब्जेक्ट का जीवनकाल कोड के एक ब्लॉक से निर्धारित होता है, और प्रोग्रामर बस इस ब्लॉक का using करता है। फिर भी, ऐसे कई मामले हैं जहां एक वस्तु का कई स्थानों पर उपयोग किया जा सकता है और इसका जीवनकाल निर्धारित करना मुश्किल है (हालांकि इस मामले में संदर्भ गणना बस ठीक होगी)।

मुश्किलें IDisposable - पिछड़ी संगतता

वर्ग के लिए IDisposable को जोड़ना और कार्यान्वित इंटरफेस की सूची से IDisposable को हटाना एक परिवर्तन है। यदि आप इंटरफ़ेस या बेस क्लास के संदर्भ में पास की गई अपनी कक्षाओं में से किसी एक में IDisposable जोड़ते हैं तो क्लाइंट कोड, जो कि IDisposable उम्मीद नहीं करता, मुफ्त संसाधन नहीं देगा।

Microsoft स्वयं इस समस्या में भाग गया। IEnumerator IDisposable से विरासत IEnumerator नहीं मिला है, और IEnumerator<T> विरासत IEnumerator<T> मिला है। यदि आप IEnumerator<T> कोड IEnumerator<T> जो IEnumerator प्राप्त करता है, तो Dispose नहीं कहा जाएगा।

यह दुनिया का अंत नहीं है, लेकिन यह कुछ द्वितीयक सार पहचान देता है।

मुश्किलें IDisposable - एक वर्ग पदानुक्रम डिजाइन करना

पदानुक्रम डिजाइन के क्षेत्र में IDisposable कारण सबसे बड़ी कमी यह है कि प्रत्येक वर्ग और इंटरफ़ेस को यह अनुमान लगाना होगा कि क्या IDisposable की आवश्यकता उसके वंशजों को होगी।

यदि इंटरफ़ेस को IDisposable विरासत में नहीं मिलता है, लेकिन इंटरफ़ेस को लागू IDisposable वाली कक्षाएं भी IDisposable लागू करती हैं, तो अंतिम कोड या तो नियतात्मक रिलीज़ को अनदेखा करेगा, या यह जाँचना होगा कि क्या वस्तु IDisposable इंटरफ़ेस को लागू करती है या नहीं। लेकिन इसके लिए, उपयोग करने वाले निर्माण का उपयोग करना संभव नहीं होगा और आपको एक बदसूरत try और finally लिखना होगा।

संक्षेप में, IDisposable पुन: प्रयोज्य सॉफ्टवेयर के विकास को जटिल बनाता है। मुख्य कारण ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के सिद्धांतों में से एक का उल्लंघन है - इंटरफ़ेस और कार्यान्वयन का पृथक्करण। संसाधनों की रिहाई एक कार्यान्वयन विवरण होनी चाहिए। Microsoft ने संसाधनों के निर्धारक रिलीज को एक द्वितीय श्रेणी इंटरफ़ेस बनाने का निर्णय लिया।

नहीं-सुंदर समाधानों में से एक यह है कि सभी वर्गों को IDisposable लागू किया जाए, लेकिन अधिकांश वर्गों के लिए, IDisposable.Dispose । IDisposable.Dispose कुछ भी नहीं करेगा। लेकिन यह बहुत सुंदर नहीं है।

IDisposable साथ एक और कठिनाई संग्रह है। उनमें कुछ संग्रह "स्वयं" वस्तुएं हैं, और कुछ नहीं। हालाँकि, संग्रह स्वयं IDisposable कार्यान्वित नहीं करते हैं। प्रोग्रामर को संग्रह में वस्तुओं पर IDisposable.Dispose को कॉल करना याद रखना चाहिए, या संग्रह की कक्षाओं के अपने वंशज बनाना चाहिए जो स्वामित्व के लिए IDisposable को लागू करते हैं।

मुश्किलें IDisposable - अतिरिक्त "गलत" स्थिति

वस्तु के जीवनकाल की परवाह किए बिना, किसी भी समय स्पष्ट रूप से IDisposable कहा जा सकता है। अर्थात्, प्रत्येक ऑब्जेक्ट में एक "रिलीज़ किया गया" राज्य जोड़ा जाता है, जिसमें किसी ObjectDisposedException को फेंकने की अनुशंसा की जाती है। स्थिति की जाँच करना और अपवादों को फेंकना एक अतिरिक्त खर्च है।

प्रत्येक छींक की जांच करने के बजाय, "मुक्त" स्थिति में वस्तु को "अपरिभाषित व्यवहार" के रूप में मुक्त स्मृति में कॉल के रूप में एक्सेस करने पर विचार करना बेहतर है।

मुश्किलें IDisposable - कोई गारंटी नहीं

IDisposable सिर्फ एक इंटरफेस है। एक वर्ग जो IDisposable लागू करता है वह नियतात्मक रिलीज का समर्थन करता है, लेकिन इसकी गारंटी नहीं देता है। ग्राहक कोड के लिए, Dispose को कॉल न करना ठीक है। इसलिए, एक ऐसा वर्ग जो IDisposable को लागू करता है, दोनों को नियतात्मक और गैर-नियतात्मक रिलीज का समर्थन करना चाहिए।

कॉम्प्लेक्सिटीज़ आईडीइज़ोफ़ॉर्म - कॉम्प्लेक्स कार्यान्वयन

Microsoft IDisposable को लागू IDisposable लिए एक पैटर्न प्रदान करता है । (पहले एक आम तौर पर भयानक पैटर्न था, लेकिन अपेक्षाकृत हाल ही में, .NET 4 की उपस्थिति के बाद, इस लेख के प्रभाव के साथ प्रलेखन को सही किया गया था। .NET पुस्तकों के पुराने संस्करणों में, आप पुराने संस्करण पा सकते हैं। - लगभग। )

IDisposable.Dispose को बिल्कुल नहीं बुलाया जा सकता है, इसलिए वर्ग में मुक्त संसाधनों के लिए एक अंतिम रूप शामिल होना चाहिए।
IDisposable.Dispose को कई बार कॉल किया जा सकता है और दिखाई देने वाले दुष्प्रभावों के बिना काम करना चाहिए। इसलिए, यह जांचना आवश्यक है कि क्या विधि पहले से ही कॉल की गई है या नहीं।
फाइनलर्स को एक अलग थ्रेड में बुलाया जाता है और इसे IDisposable.Dispose से पहले बुलाया जा सकता IDisposable.Dispose । ऐसे "दौड़" से बचने के लिए GC.SuppressFinalize उपयोग GC.SuppressFinalize है।

इसके अलावा:

फाइनलर्स को बुलाया जाता है, जिसमें ऑब्जेक्ट्स शामिल होते हैं जो कंस्ट्रक्टर में एक अपवाद फेंकते हैं। इसलिए, रिलीज़ कोड को आंशिक रूप से प्रारंभिक ऑब्जेक्ट के साथ काम करना चाहिए।
CriticalFinalizerObject से विरासत में प्राप्त एक वर्ग में एक IDisposable को लागू IDisposable लिए गैर-तुच्छ निर्माण की आवश्यकता होती है। void Dispose(bool disposing) एक वायरल विधि है और इसे विवश निष्पादन क्षेत्र में निष्पादित किया जाना चाहिए, जिसके लिए RuntimeHelpers.PrepareMethod कॉल की आवश्यकता होती है।

मुश्किलों को दूर करने के लिए उपयुक्त नहीं है

किसी ऑब्जेक्ट को बंद करना - अक्सर समानांतर या अतुल्यकालिक थ्रेड्स के कार्यक्रमों में होता है। उदाहरण के लिए, एक वर्ग एक अलग थ्रेड का उपयोग करता है और इसे ManualResetEvent उपयोग करना चाहता है। यह IDisposable.Dispose में किया जा सकता है, लेकिन यह एक त्रुटि हो सकती है यदि कोड फाइनल में कहा जाता है।

अंतिम रूप में सीमाओं को समझने के लिए, आपको यह समझने की आवश्यकता है कि कचरा कलेक्टर कैसे काम करता है। नीचे एक सरलीकृत आरेख है जिसमें पीढ़ियों से संबंधित कई विवरण, कमजोर लिंक, वस्तुओं का पुनरुद्धार, पृष्ठभूमि कचरा संग्रह, आदि को छोड़ दिया गया है।

.NET गारबेज कलेक्टर मार्क-एंड-स्वीप एल्गोरिथ्म का उपयोग करता है। सामान्य तौर पर, तर्क इस तरह दिखता है:

सभी सूत्र रोकें।
सभी रूट ऑब्जेक्ट्स लें: स्टैक, वैरिएबल फ़ील्ड्स, GCHandle ऑब्जेक्ट्स, GCHandle कतार पर चर। अनुप्रयोग डोमेन (प्रोग्राम समाप्ति) उतारने के मामले में, यह माना जाता है कि स्टैक और स्थिर फ़ील्ड में चर जड़ नहीं हैं।
पुनरावर्ती वस्तुओं से सभी लिंक के माध्यम से जाते हैं और उन्हें "पहुंच योग्य" के रूप में चिह्नित करते हैं।
अन्य सभी वस्तुओं के माध्यम से जाना, जिनमें विध्वंसक (फाइनल) होते हैं, उन्हें पहुंच योग्य घोषित करते हैं, और उन्हें अंतिम रूप से कतार में डालते हैं ( GC.SuppressFinalize GC को ऐसा नहीं करने के लिए कहता है)। वस्तुओं को अप्रत्याशित क्रम में पंक्तिबद्ध किया जाता है।

पृष्ठभूमि में, अंतिम रूप देने की एक धारा (या कई) काम करती है:

कतार से एक वस्तु लेता है और अपने अंतिम रूप को शुरू करता है। एक ही समय में विभिन्न वस्तुओं के कई फाइनल को चलाना संभव है।
ऑब्जेक्ट को कतार से हटा दिया जाता है, और यदि कोई और इसे संदर्भित नहीं करता है, तो यह अगले कचरा संग्रह में साफ हो जाएगा।

अब यह स्पष्ट होना चाहिए कि अंतिम रूप से प्रबंधित संसाधनों तक पहुंचना असंभव क्यों है - आपको नहीं पता कि अंतिम रूप से किस क्रम में कहा जाता है। यहां तक कि IDisposable.Dispose कॉल करना। IDisposable.Dispose किसी अन्य ऑब्जेक्ट का उपयोग करना त्रुटि का कारण बन सकता है, क्योंकि संसाधन रिलीज़ कोड किसी अन्य थ्रेड में काम कर सकता है।

कुछ अपवाद हैं जब आप एक फाइनल से प्रबंधित संसाधनों तक पहुँच सकते हैं:

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

सामान्य मामले में, अंतिम संसाधनों से प्रबंधित संसाधनों का उपयोग न करना बेहतर है। फिर भी, गैर-तुच्छ सॉफ़्टवेयर के लिए पूर्णता का तर्क आवश्यक है। Windows.Forms इसमें Application.Exit विधि में पूर्ण तर्क Windows.Forms । जब आप अपने कंपोनेंट लाइब्रेरी को विकसित कर रहे होते हैं, तो सबसे अच्छी बात यह होती है कि पूरा करने के लिए लॉजिक के साथ IDisposable । IDisposable.Dispose मामले में सामान्य समाप्ति।

Microsoft भी इस समस्या में भाग गया। StreamWriter वर्ग एक Stream ऑब्जेक्ट का मालिक है (नवीनतम संस्करण में कंस्ट्रक्टर मापदंडों के आधार पर - लगभग। प्रति। )। StreamWriter.Close बफर को फ्लश करता है और Stream.Close कॉल Stream.Close (यह भी होता है कि यदि using में लिपटा हो - लगभग। )। यदि StreamWriter बंद नहीं है, तो बफर फ्लश नहीं किया जाता है और डेटा चैट खो जाता है। Microsoft ने अंतिम रूप से अंतिम रूप से पुनर्परिभाषित नहीं किया, इस प्रकार पूर्ण समस्या का "समाधान" किया। तर्क पूरा करने की आवश्यकता का एक बड़ा उदाहरण।

मैं पढ़ने की सलाह देता हूं

इस लेख में .NET इंटर्नल्स के बारे में बहुत सी जानकारी जेफरी रिक्टर के CLR C # के माध्यम से आती है। यदि आपके पास यह अभी तक नहीं है, तो इसे खरीद लें । गंभीरता से। यह किसी भी C # प्रोग्रामर के लिए आवश्यक ज्ञान है।

अनुवादक से निष्कर्ष

अधिकांश .NET प्रोग्रामर इस लेख में वर्णित समस्याओं का सामना कभी नहीं करेंगे। .NET एब्सट्रैक्शन के स्तर को बढ़ाने के लिए विकसित होगा और अप्रबंधित संसाधनों की "बाजीगरी" की आवश्यकता को कम करेगा। फिर भी, यह लेख इस मायने में उपयोगी है कि यह सरल चीजों के गहन विवरण और कोड डिजाइन पर उनके प्रभाव का वर्णन करता है।

अगला भाग उदाहरणों के एक समूह के साथ .NET में प्रबंधित और अप्रबंधित संसाधनों के साथ काम करने के तरीके की एक विस्तृत चर्चा होगी।

आईडी-प्रयोज्य - कि आपकी माँ ने संसाधनों को मुक्त करने के बारे में बात नहीं की। भाग 1