फ़ाइनलाइज़र: Difference between revisions

[[कंप्यूटर विज्ञान]] में,  फाइनलाइज़र या अंतिम विधि एक विशेष [[विधि (कंप्यूटर प्रोग्रामिंग)]] है | जो अंतिम रूप देती है | सामान्यतः सफाई का कुछ रूप ऑब्जेक्ट के विनाश के समय  फाइनलाइज़र को निष्पादित किया जाता है | [[वस्तु निर्माण|ऑब्जेक्ट निर्माण]] से पहले, और  [[प्रारंभकर्ता]] का पूरक होता है | जिसे मेमोरी प्रबंधन के बाद ऑब्जेक्ट निर्माण के समय निष्पादित किया जाता है। उचित उपयोग में कठिनाई और उनके द्वारा जोड़ी जाने वाली जटिलता के कारण फ़ाइनलाइज़र को कुछ लोगों द्वारा दृढ़ता से हतोत्साहित किया जाता है, और इसके अतिरिक्त विकल्प सुझाए जाते हैं | मुख्य रूप से [[निपटान पैटर्न|डिस्पोजल पैटर्न]]  <ref>{{harvnb|Jagger|Perry|Sestoft|2007|p=[https://books.google.com/books?id=g6axWRRpJZwC&dq=destructor+finalizer&pg=PA542 542]|ps=, "In C++, a destructor is called in a determinate manner, whereas, in [[C Sharp (programming language)|C#]], a finalizer is not. To get determinate behavior from C#, one should use <code>Dispose.</code>}}</ref> (समस्याएं देखें) है।

फ़ाइनलाइज़र शब्द का उपयोग अधिकतर [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ]] में किया जाता है। ऑब्जेक्ट-ओरिएंटेड और [[ कार्यात्मक प्रोग्रामिंग ]] [[ प्रोग्रामिंग भाषा ]] जो कचरा संग्रह (कंप्यूटर साइंस) का उपयोग करती हैं | जिनमें से मूलरूप स्मॉलटाक है। यह  [[ विनाशक (कंप्यूटर प्रोग्रामिंग) ]] के विपरीत है | जो नियतात्मक रूप से [[C++]] के नियतात्मक ऑब्जेक्ट जीवनकाल के साथ भाषाओं में अंतिम रूप देने के लिए कहा जाने वाला  विधि है।<ref>{{cite conference |last=Boehm |first=Hans-J. |year=2002 |title=विध्वंसक, अंतिम रूप देने वाले और तुल्यकालन|url=http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html |conference=[[Symposium on Principles of Programming Languages]] (POPL)}}</ref><ref>{{harvnb|Jagger|Perry|Sestoft|2007|p=[https://books.google.com/books?id=g6axWRRpJZwC&dq=destructor+finalizer&pg=PA542 542]|ps=, '''C++ destructors versus C# finalizers''' C++ destructors are determinate in the sense that they are run at known points in time, in a known order, and from a known thread. They are thus semantically ''very'' different from C# finalizers, which are run at unknown points in time, in an unknown order, from an unknown thread, and at the discretion of the garbage collector.}}</ref> ये सामान्यतः अनन्य होते हैं | भाषा में या तो फ़ाइनलाइज़र (यदि स्वचालित रूप से कचरा एकत्र किया जाता है) या विध्वंसक (यदि मैन्युअल रूप से मेमोरी प्रबंधित की जाती है), किन्तु दुर्लभ स्थितियों में  भाषा में C++/CLI और D (प्रोग्रामिंग लैंग्वेज) और दोनों हो सकते हैं। [[संदर्भ गिनती|संदर्भ गणना]] का स्थिति (कचरा संग्रह का पता लगाने के अतिरिक्त), शब्दावली अलग होती है। विधि उपयोग में, डिस्ट्रक्टर्स को संदर्भित करने के लिए फाइनलाइज़र का भी उपयोग किया जा सकता है | क्योंकि ये भी अंतिम रूप देते हैं, और कुछ सूक्ष्म भेद तैयार किए जाते हैं | शब्दावली देखें अंतिम शब्द का उपयोग उस वर्ग को इंगित करने के लिए भी किया जाता है | जो वंशानुक्रम (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) नहीं हो सकता है | यह असंबंधित है।

सामान्य उपयोग में,  विध्वंसक एक विधि है | जिसे नियतात्मक रूप से ऑब्जेक्ट के विनाश पर कहा जाता है, और मूलरूप C++ विध्वंसक है | जबकि  फाइनलाइज़र को कचरा कलेक्टर द्वारा गैर-नियतात्मक रूप से कहा जाता है, और मूलरूप [[जावा (प्रोग्रामिंग भाषा)]] <code>finalize</code> को अंतिम रूप देने के तरीके है |

उन भाषाओं के लिए जो संदर्भ गिनती के माध्यम से कचरा संग्रह को प्रयुक्त करती हैं | शब्दावली अलग होती है | कुछ भाषाओं जैसे [[ उद्देश्य सी | उद्देश्य C]] और [[पर्ल]] विनाशक का उपयोग करते हुए, और अन्य भाषाओं जैसे कि पायथन फ़ाइनलाइज़र का उपयोग करते हुए (प्रति युक्ति, पायथन कचरा एकत्र किया जाता है, किन्तु संदर्भ [[CPython|C पायथन]] कार्यान्वयन इसके बाद से संस्करण 2.0 संदर्भ गिनती और कचरा संग्रह के संयोजन का उपयोग करता है)। यह दर्शाता है कि संदर्भ गणना का परिणाम अर्ध-नियतात्मक ऑब्जेक्ट जीवनकाल में होता है | उन ऑब्जेक्ट के लिए जो  चक्र का भाग नहीं हैं  | ऑब्जेक्ट को निश्चित रूप से नष्ट कर दिया जाता है जब संदर्भ संख्या शून्य हो जाती है, किन्तु  चक्र का भाग होने वाली ऑब्जेक्ट को गैर-नियतात्मक रूप से नष्ट कर दिया जाता है। कचरा संग्रह के एक अलग रूप का भाग होता है ।

कुछ संकीर्ण विधि उपयोगों में, कंस्ट्रक्टर और विनाशक भाषा-स्तर के शब्द हैं | जिसका अर्थ है कि  वर्ग में परिभाषित विधियाँ, जबकि इनिशियलाइज़र और फ़ाइनलाइज़र कार्यान्वयन-स्तर की शर्तें हैं | जिसका अर्थ है ऑब्जेक्ट निर्माण या विनाश के समय बुलाई जाने वाली विधियाँ है। इस प्रकार उदाहरण के लिए C शार्प (प्रोग्रामिंग भाषा) के लिए मूल विनिर्देश C भाषा विनाशकों को संदर्भित करती है | तथापि C कचरा-एकत्रित है, किन्तु सामान्य भाषा इंफ्रास्ट्रक्चर (सीएलआई) के लिए विनिर्देश, और इसके रनटाइम पर्यावरण के कार्यान्वयन के रूप में [[ सामान्य भाषा रनटाइम ]] (सीएलआर), जिसे फाइनलाइजर्स कहा जाता है। यह C भाषा समिति के नोट्स में परिलक्षित होता है | जो भाग में पढ़ता है | C कंपाइलर डिस्ट्रक्टर्स को संकलित करता है | संभवतः उदाहरण फाइनलाइज़र एस <ref>In full: "We're going to use the term "destructor" for the member which executes when an instance is reclaimed. Classes can have destructors; structs can't. Unlike in C++, a destructor cannot be called explicitly. Destruction is non-deterministic – you can't reliably know when the destructor will execute, except to say that it executes at some point after all references to the object have been released. The destructors in an inheritance chain are called in order, from most descendant to least descendant. There is no need (and no way) for the derived class to explicitly call the base destructor. The C# compiler compiles destructors to the appropriate CLR representation. For this version that probably means an instance finalizer that is distinguished in metadata. CLR may provide static finalizers in the future; we do not see any barrier to C# using static finalizers.", May 12th, 1999.</ref><ref>[http://blogs.msdn.com/b/ericlippert/archive/2010/01/21/what-s-the-difference-between-a-destructor-and-a-finalizer.aspx What’s the difference between a destructor and a finalizer?], Eric Lippert, ''Eric Lippert’s Blog: Fabulous Adventures In Coding,'' 21 Jan 2010</ref> यह शब्दावली भ्रमित करने वाली है, और इस प्रकार C स्पेक के अधिक हाल के संस्करण भाषा-स्तरीय पद्धति को फ़ाइनलाइज़र के रूप में संदर्भित करते हैं।<ref name=csharpname/>

एक अन्य भाषा जो d इस शब्दावली भेद को नहीं बनाती है | चूँकि d कक्षाएं कचरा एकत्र की जाती हैं | उनके सफाई कार्यों को विध्वंसक कहा जाता है।<ref>[http://dlang.org/class.html#destructors Class destructors] Class destructors in D</ref>

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

फाइनलाइजेशन के समय मेमोरी डीलोकेशन C++ जैसी भाषाओं में सामान्य है | जहां मैनुअल मेमोरी मैनेजमेंट मानक है, किन्तु प्रबंधित भाषाओं में भी होता है | जब मेमोरी को प्रबंधित हीप के बाहर आवंटित किया गया है |(बाह्य रूप से भाषा के लिए) जावा में यह [[ जावा मूल इंटरफ़ेस ]] (जेएनआई) और के साथ होता है | <code>ByteBuffer</code> नॉन-ब्लॉकिंग I/O (जावा) में ऑब्जेक्ट नया I/O (एनआईओ) यह उत्तरार्द्ध कचरा संग्रहकर्ता के इन बाहरी संसाधनों को ट्रैक करने में असमर्थ होने के कारण समस्याएँ उत्पन्न कर सकता है | इसलिए उन्हें आक्रामक रूप से पर्याप्त रूप से एकत्र नहीं किया जाएगा, और अप्रबंधित मेमोरी को समाप्त करने के कारण आउट-ऑफ़-मेमोरी त्रुटियाँ उत्पन्न कर सकता है | देशी मेमोरी का इलाज करके इससे बचा जा सकता है | संसाधन के रूप में और डिस्पोजल पैटर्न का उपयोग करते हुए, जैसा कि नीचे चर्चा की गई है।

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

जावास्क्रिप्ट में, [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry finalizationRegistry] आपको किसी ऑब्जेक्ट के कूड़ा-कचरा एकत्र करने पर कॉलबैक का अनुरोध करने की अनुमति देता है।

फाइनलाइज़र को तब कहा जाता है | जब  [[वस्तु (कंप्यूटर विज्ञान)|ऑब्जेक्ट (कंप्यूटर विज्ञान)]] कचरा एकत्र किया जाता है  | ऑब्जेक्ट कचरा (पहुंच योग्य) बनने के बाद, किन्तु इससे पहले कि उसकी मेमोरी को हटा दिया जाए। कचरा संग्राहक के विवेक पर अंतिम रूप से गैर-नियतात्मक रूप से होता है, और कभी नहीं हो सकता है। यह विनाशकों के साथ विरोधाभासी है | जिन्हें नियतात्मक रूप से कहा जाता है | जैसे ही कोई ऑब्जेक्ट अब उपयोग में नहीं होती है, और अनियंत्रित कार्यक्रम समाप्ति के स्थिति को छोड़कर सदैव कहा जाता है। ऑब्जेक्ट-विशिष्ट संचालन करने की आवश्यकता के कारण फ़ाइनलाइज़र अधिकाशतः [[उदाहरण विधि]]याँ हैं।

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

कार्यान्वयन के आधार पर, अंतिमकर्ता बड़ी संख्या में समस्याएं उत्पन्न कर सकते हैं, और इस प्रकार कई अधिकारियों द्वारा दृढ़ता से हतोत्साहित किया जाता है।<ref name=certjava>"[https://www.securecoding.cert.org/confluence/display/java/MET12-J.+Do+not+use+finalizers MET12-J. Do not use finalizers]", Dhruv Mohindra, [https://www.securecoding.cert.org/confluence/display/java The CERT Oracle Secure Coding Standard for Java], [https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=18580918 05. Methods (MET)] {{Webarchive|url=https://web.archive.org/web/20140504105218/https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=18580918 |date=2014-05-04 }}</ref><ref>[https://docs.python.org/3/reference/datamodel.html#object.__del__ object.__del__(self)], ''[https://docs.python.org/3/reference/ The Python Language Reference],'' [https://docs.python.org/3/reference/datamodel.html 3. Data model]: "... <code>__del__()</code> methods should do the absolute minimum needed to maintain external invariants."</ref> इन समस्याओं में सम्मिलित हैं:<ref name=certjava/>* फाइनलाइजर्स को समय पर या बिल्कुल भी नहीं बुलाया जा सकता है, इसलिए उन पर राज्य को जारी रखने, दुर्लभ संसाधनों को जारी करने, या कुछ और महत्वपूर्ण करने के लिए विश्वास नहीं किया जा सकता है।

* फ़ाइनलाइज़र का परिणाम ऑब्जेक्ट पुनरुत्थान हो सकता है, जो अधिकाशतः  प्रोग्रामिंग त्रुटि होती है और जिसकी बहुत संभावना अधिक धीमी हो जाती है और कचरा संग्रहण को जटिल बना देती है।

* फाइनलाइज़र कचरा संग्रह के आधार पर चलाए जाते हैं, जो सामान्यतः प्रबंधित मेमोरी दबाव पर आधारित होते हैं - वे अन्य संसाधनों की कमी के स्थिति में नहीं चलते हैं, और इस प्रकार अन्य दुर्लभ संसाधनों के प्रबंधन के लिए उपयुक्त नहीं होते हैं।

* फ़ाइनलाइज़र  निर्दिष्ट क्रम में नहीं चलते हैं, और [[ वर्ग अपरिवर्तनीय ]]्स पर विश्वास नहीं कर सकते हैं (क्योंकि वे अन्य ऑब्जेक्ट्स को संदर्भित कर सकते हैं जिन्हें पहले ही अंतिम रूप दिया जा चुका है)।

* फ़ाइनलाइज़र के अपवादों को सामान्यतः नियंत्रित नहीं किया जा सकता है, क्योंकि फ़ाइनलाइज़र  अनिर्दिष्ट वातावरण में चलाया जाता है, और इसे या तो अनदेखा किया जा सकता है या अनियंत्रित प्रोग्राम समाप्ति का कारण बन सकता है।

* फाइनलाइज़र सिंक्रनाइज़ेशन मुद्दों का कारण बन सकता है, यहां तक ​​​​कि अनुक्रमिक (एकल-थ्रेडेड) कार्यक्रमों में भी, जब एक अलग धागे में अंतिम रूप दिया जाता है।<ref>Hans-J. Boehm, Finalization, Threads, and the Java™ Technology-Based Memory Model, JavaOne Conference, 2005.</ref>

* फ़ाइनलाइज़र डेडलॉक का कारण बन सकता है यदि सिंक्रोनाइज़ेशन मैकेनिज़्म जैसे ताले का उपयोग किया जाता है, निर्दिष्ट क्रम में नहीं चलने और संभवतः समवर्ती रूप से चलने के कारण।

* प्रोग्राम समाप्ति के समय चलाए जाने वाले फ़ाइनलाइज़र सामान्य रनटाइम वातावरण पर विश्वास नहीं कर सकते हैं, और इस प्रकार गलत धारणाओं के कारण विफल हो सकते हैं - इस कारण फ़ाइनलाइज़र अधिकाशतः समाप्ति के समय नहीं चलते हैं।

इसके अलावा, प्रोग्रामिंग त्रुटियों के कारण या अप्रत्याशित रीचैबिलिटी के कारण कचरा होने की उम्मीद से परे पहुंच योग्य ऑब्जेक्ट के कारण अंतिम रूप से चलने में विफल हो सकते हैं। उदाहरण के लिए, जब पायथन  अपवाद को पकड़ता है (या  अपवाद इंटरएक्टिव मोड में नहीं पकड़ा जाता है), यह स्टैक फ्रेम का संदर्भ रखता है जहां अपवाद उठाया गया था, जो उस स्टैक फ्रेम से संदर्भित ऑब्जेक्ट को जीवित रखता है।

जावा में,  सुपरक्लास में फ़ाइनलाइज़र  उपवर्ग में कचरा संग्रह को धीमा कर सकता है, क्योंकि फ़ाइनलाइज़र संभावित रूप से उपवर्ग में फ़ील्ड्स को संदर्भित कर सकता है, और इस प्रकार फ़ाइनलाइज़र के चलने के बाद, अगले चक्र तक फ़ील्ड को कचरा एकत्र नहीं किया जा सकता है।<ref name=certjava/>[[वंशानुक्रम पर रचना]] का उपयोग करके इससे बचा जा सकता है।

{{main|Resource management (computing)}}

इस प्रकार स्वचालित संसाधन प्रबंधन के लिए फाइनलाइजर्स का उपयोग करने के अतिरिक्त, कचरा-एकत्रित भाषाओं में संसाधनों को मैन्युअल रूप से प्रबंधित करना चाहिए, सामान्यतः निपटान पैटर्न का उपयोग करके। इस स्थिति में संसाधनों को अभी भी इनिशियलाइज़र में अधिग्रहित किया जा सकता है, जिसे स्पष्ट रूप से ऑब्जेक्ट इंस्टेंटेशन पर कहा जाता है, किन्तु निपटान विधि में जारी किया जाता है। निपटान विधि को स्पष्ट रूप से, या स्पष्ट रूप से C # के जैसे भाषा निर्माणों द्वारा कहा जा सकता है <code>using</code>, मई आपको <code>try</code>-साथ-संसाधन, या पायथन <code>with</code>.