फ़ाइनलाइज़र: Difference between revisions
From Vigyanwiki
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{for|the video game|Finalizer (video game)}} | {{for|the video game|Finalizer (video game)}} | ||
{{for|the process related to optical disc media|Finalize (optical discs)}} | {{for|the process related to optical disc media|Finalize (optical discs)}} | ||
[[कंप्यूटर विज्ञान]] में, | [[कंप्यूटर विज्ञान]] में, फाइनलाइज़र या अंतिम विधि एक विशेष [[विधि (कंप्यूटर प्रोग्रामिंग)]] है जो अंतिम रूप देती है, आम तौर पर सफाई का कुछ रूप। वस्तु के विनाश के दौरान फाइनलाइज़र को निष्पादित किया जाता है, [[वस्तु निर्माण]] [[आवंटन रद्द]] से पहले, और [[प्रारंभकर्ता]] का पूरक होता है, जिसे मेमोरी प्रबंधन के बाद ऑब्जेक्ट निर्माण के दौरान निष्पादित किया जाता है। उचित उपयोग में कठिनाई और उनके द्वारा जोड़ी जाने वाली जटिलता के कारण फ़ाइनलाइज़र को कुछ लोगों द्वारा दृढ़ता से हतोत्साहित किया जाता है, और इसके बजाय विकल्प सुझाए जाते हैं, मुख्य रूप से [[निपटान पैटर्न]]<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 (प्रोग्रामिंग लैंग्वेज) और दोनों हो सकते हैं। [[संदर्भ गिनती]] का मामला (कचरा संग्रह का पता लगाने के बजाय), शब्दावली भिन्न होती है। तकनीकी उपयोग में, डिस्ट्रक्टर्स को संदर्भित करने के लिए फाइनलाइज़र का भी उपयोग किया जा सकता है, क्योंकि ये भी अंतिम रूप देते हैं, और कुछ सूक्ष्म भेद तैयार किए जाते हैं - #Terminology देखें। अंतिम शब्द का उपयोग उस वर्ग को इंगित करने के लिए भी किया जाता है जो वंशानुक्रम (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) नहीं हो सकता है; यह असंबंधित है। | ||
'''क्योंकि ये भी अंतिम रूप देते हैं, और कुछ सूक्ष्म भेद तैयार किए जाते हैं - #Terminology देखें। अंतिम शब्द का उपयोग उस वर्ग को इंगित करने के लिए भी किया जाता है जो वंशानुक्रम (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) नहीं हो सकता है; यह असंबंधित है।क्योंकि ये भी अंतिम रूप देते हैं, और | '''क्योंकि ये भी अंतिम रूप देते हैं, और कुछ सूक्ष्म भेद तैयार किए जाते हैं - #Terminology देखें। अंतिम शब्द का उपयोग उस वर्ग को इंगित करने के लिए भी किया जाता है जो वंशानुक्रम (ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग) नहीं हो सकता है; यह असंबंधित है।क्योंकि ये भी अंतिम रूप देते हैं, और''' | ||
== शब्दावली == | == शब्दावली == | ||
फाइनलाइज़र और फ़ाइनलाइज़ेशन बनाम विध्वंसक और विनाश की शब्दावली लेखकों के बीच भिन्न होती है और कभी-कभी अस्पष्ट होती है। | फाइनलाइज़र और फ़ाइनलाइज़ेशन बनाम विध्वंसक और विनाश की शब्दावली लेखकों के बीच भिन्न होती है और कभी-कभी अस्पष्ट होती है। | ||
सामान्य उपयोग में, | सामान्य उपयोग में, विध्वंसक एक विधि है जिसे नियतात्मक रूप से वस्तु के विनाश पर कहा जाता है, और मूलरूप सी ++ विध्वंसक है; जबकि फाइनलाइज़र को कचरा कलेक्टर द्वारा गैर-नियतात्मक रूप से कहा जाता है, और मूलरूप [[जावा (प्रोग्रामिंग भाषा)]] है <code>finalize</code> तरीके। | ||
उन भाषाओं के लिए जो संदर्भ गिनती के माध्यम से कचरा संग्रह को लागू करती हैं, शब्दावली भिन्न होती है, कुछ भाषाओं जैसे [[ उद्देश्य सी ]] और [[पर्ल]] डिस्ट्रक्टर का उपयोग करते हुए, और अन्य भाषाओं जैसे कि पायथन फ़ाइनलाइज़र का उपयोग करते हुए (प्रति युक्ति, पायथन कचरा एकत्र किया जाता है, लेकिन संदर्भ [[CPython]] कार्यान्वयन इसके बाद से संस्करण 2.0 संदर्भ गिनती और कचरा संग्रह के संयोजन का उपयोग करता है)। यह दर्शाता है कि संदर्भ गणना का परिणाम अर्ध-नियतात्मक वस्तु जीवनकाल में होता है: उन वस्तुओं के लिए जो | उन भाषाओं के लिए जो संदर्भ गिनती के माध्यम से कचरा संग्रह को लागू करती हैं, शब्दावली भिन्न होती है, कुछ भाषाओं जैसे [[ उद्देश्य सी ]] और [[पर्ल]] डिस्ट्रक्टर का उपयोग करते हुए, और अन्य भाषाओं जैसे कि पायथन फ़ाइनलाइज़र का उपयोग करते हुए (प्रति युक्ति, पायथन कचरा एकत्र किया जाता है, लेकिन संदर्भ [[CPython]] कार्यान्वयन इसके बाद से संस्करण 2.0 संदर्भ गिनती और कचरा संग्रह के संयोजन का उपयोग करता है)। यह दर्शाता है कि संदर्भ गणना का परिणाम अर्ध-नियतात्मक वस्तु जीवनकाल में होता है: उन वस्तुओं के लिए जो चक्र का हिस्सा नहीं हैं, वस्तुओं को निश्चित रूप से नष्ट कर दिया जाता है जब संदर्भ संख्या शून्य हो जाती है, लेकिन चक्र का हिस्सा होने वाली वस्तुओं को गैर-नियतात्मक रूप से नष्ट कर दिया जाता है। कचरा संग्रह के एक अलग रूप का हिस्सा। | ||
कुछ संकीर्ण तकनीकी उपयोगों में, कंस्ट्रक्टर और डिस्ट्रक्टर भाषा-स्तर के शब्द हैं, जिसका अर्थ है कि | कुछ संकीर्ण तकनीकी उपयोगों में, कंस्ट्रक्टर और डिस्ट्रक्टर भाषा-स्तर के शब्द हैं, जिसका अर्थ है कि वर्ग में परिभाषित विधियाँ, जबकि इनिशियलाइज़र और फ़ाइनलाइज़र कार्यान्वयन-स्तर की शर्तें हैं, जिसका अर्थ है वस्तु निर्माण या विनाश के दौरान बुलाई जाने वाली विधियाँ। इस प्रकार उदाहरण के लिए सी शार्प (प्रोग्रामिंग भाषा) के लिए मूल विनिर्देश | सी # भाषा विनाशकों को संदर्भित करती है, भले ही सी # कचरा-एकत्रित है, लेकिन सामान्य भाषा इंफ्रास्ट्रक्चर (सीएलआई) के लिए विनिर्देश, और इसके रनटाइम पर्यावरण के कार्यान्वयन के रूप में [[ सामान्य भाषा रनटाइम ]] (सीएलआर), जिसे फाइनलाइजर्स कहा जाता है। यह 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> यह शब्दावली भ्रमित करने वाली है, और इस प्रकार सी # स्पेक के अधिक हाल के संस्करण भाषा-स्तरीय पद्धति को finalizers के रूप में संदर्भित करते हैं।<ref name=csharpname/> | ||
एक अन्य भाषा जो इस शब्दावली भेद को नहीं बनाती है वह है डी। हालांकि डी कक्षाएं कचरा एकत्र की जाती हैं, उनके सफाई कार्यों को विध्वंसक कहा जाता है।<ref>[http://dlang.org/class.html#destructors Class destructors] Class destructors in D</ref> | एक अन्य भाषा जो इस शब्दावली भेद को नहीं बनाती है वह है डी। हालांकि डी कक्षाएं कचरा एकत्र की जाती हैं, उनके सफाई कार्यों को विध्वंसक कहा जाता है।<ref>[http://dlang.org/class.html#destructors Class destructors] Class destructors in D</ref> | ||
| Line 20: | Line 20: | ||
== प्रयोग करें == | == प्रयोग करें == | ||
फाइनलाइजेशन का उपयोग ज्यादातर सफाई के लिए, मेमोरी या अन्य संसाधनों को जारी करने के लिए किया जाता है: [[ मैनुअल मेमोरी प्रबंधन ]] के माध्यम से आवंटित मेमोरी को हटाने के लिए; यदि संदर्भ गणना का उपयोग किया जाता है तो संदर्भों को स्पष्ट करने के लिए (संदर्भ संख्या में कमी); संसाधनों को जारी करने के लिए, विशेष रूप से संसाधन अधिग्रहण प्रारंभिक (आरएआईआई) मुहावरे में है; या किसी वस्तु को अपंजीकृत करने के लिए। अंतिम रूप देने की मात्रा भाषाओं के बीच महत्वपूर्ण रूप से भिन्न होती है, C++ में व्यापक अंतिमीकरण से, जिसमें मैनुअल स्मृति प्रबंधन, संदर्भ गणना, और नियतात्मक वस्तु जीवन काल होता है; जावा में अक्सर कोई अंतिम रूप नहीं दिया जाता है, जिसमें गैर-नियतात्मक वस्तु जीवनकाल होता है और अक्सर ट्रेसिंग कचरा संग्राहक के साथ लागू किया जाता है। यह भी संभव है कि कम या कोई स्पष्ट (उपयोगकर्ता-निर्दिष्ट) अंतिम रूप न हो, लेकिन संकलक, दुभाषिया, या रनटाइम द्वारा निष्पादित महत्वपूर्ण अंतर्निहित अंतिमकरण; [[स्वचालित संदर्भ गिनती]] के मामले में यह सामान्य है, जैसा कि पायथन के सीपीथॉन संदर्भ कार्यान्वयन में, या ऐप्पल के ऑब्जेक्टिव-सी के कार्यान्वयन में स्वचालित संदर्भ गणना में, जो दोनों अंतिम रूप से संदर्भों को स्वचालित रूप से तोड़ देते हैं। | फाइनलाइजेशन का उपयोग ज्यादातर सफाई के लिए, मेमोरी या अन्य संसाधनों को जारी करने के लिए किया जाता है: [[ मैनुअल मेमोरी प्रबंधन ]] के माध्यम से आवंटित मेमोरी को हटाने के लिए; यदि संदर्भ गणना का उपयोग किया जाता है तो संदर्भों को स्पष्ट करने के लिए (संदर्भ संख्या में कमी); संसाधनों को जारी करने के लिए, विशेष रूप से संसाधन अधिग्रहण प्रारंभिक (आरएआईआई) मुहावरे में है; या किसी वस्तु को अपंजीकृत करने के लिए। अंतिम रूप देने की मात्रा भाषाओं के बीच महत्वपूर्ण रूप से भिन्न होती है, C++ में व्यापक अंतिमीकरण से, जिसमें मैनुअल स्मृति प्रबंधन, संदर्भ गणना, और नियतात्मक वस्तु जीवन काल होता है; जावा में अक्सर कोई अंतिम रूप नहीं दिया जाता है, जिसमें गैर-नियतात्मक वस्तु जीवनकाल होता है और अक्सर ट्रेसिंग कचरा संग्राहक के साथ लागू किया जाता है। यह भी संभव है कि कम या कोई स्पष्ट (उपयोगकर्ता-निर्दिष्ट) अंतिम रूप न हो, लेकिन संकलक, दुभाषिया, या रनटाइम द्वारा निष्पादित महत्वपूर्ण अंतर्निहित अंतिमकरण; [[स्वचालित संदर्भ गिनती]] के मामले में यह सामान्य है, जैसा कि पायथन के सीपीथॉन संदर्भ कार्यान्वयन में, या ऐप्पल के ऑब्जेक्टिव-सी के कार्यान्वयन में स्वचालित संदर्भ गणना में, जो दोनों अंतिम रूप से संदर्भों को स्वचालित रूप से तोड़ देते हैं। फाइनलाइज़र में मनमाना कोड शामिल हो सकता है; विशेष रूप से जटिल उपयोग ऑब्जेक्ट को [[ वस्तु पूल ]] में स्वचालित रूप से वापस करना है। | ||
फाइनलाइजेशन के दौरान मेमोरी डीलोकेशन C++ जैसी भाषाओं में आम है जहां मैनुअल मेमोरी मैनेजमेंट मानक है, लेकिन प्रबंधित भाषाओं में भी होता है जब मेमोरी को प्रबंधित हीप के बाहर आवंटित किया गया है (बाह्य रूप से भाषा के लिए); जावा में यह [[ जावा मूल इंटरफ़ेस ]] (JNI) और के साथ होता है <code>ByteBuffer</code> नॉन-ब्लॉकिंग I/O (जावा) में ऑब्जेक्ट | नया I/O (NIO)। यह उत्तरार्द्ध कचरा संग्रहकर्ता के इन बाहरी संसाधनों को ट्रैक करने में असमर्थ होने के कारण समस्याएँ पैदा कर सकता है, इसलिए उन्हें आक्रामक रूप से पर्याप्त रूप से एकत्र नहीं किया जाएगा, और अप्रबंधित मेमोरी को समाप्त करने के कारण आउट-ऑफ़-मेमोरी त्रुटियाँ पैदा कर सकता है - देशी मेमोरी का इलाज करके इससे बचा जा सकता है | फाइनलाइजेशन के दौरान मेमोरी डीलोकेशन C++ जैसी भाषाओं में आम है जहां मैनुअल मेमोरी मैनेजमेंट मानक है, लेकिन प्रबंधित भाषाओं में भी होता है जब मेमोरी को प्रबंधित हीप के बाहर आवंटित किया गया है (बाह्य रूप से भाषा के लिए); जावा में यह [[ जावा मूल इंटरफ़ेस ]] (JNI) और के साथ होता है <code>ByteBuffer</code> नॉन-ब्लॉकिंग I/O (जावा) में ऑब्जेक्ट | नया I/O (NIO)। यह उत्तरार्द्ध कचरा संग्रहकर्ता के इन बाहरी संसाधनों को ट्रैक करने में असमर्थ होने के कारण समस्याएँ पैदा कर सकता है, इसलिए उन्हें आक्रामक रूप से पर्याप्त रूप से एकत्र नहीं किया जाएगा, और अप्रबंधित मेमोरी को समाप्त करने के कारण आउट-ऑफ़-मेमोरी त्रुटियाँ पैदा कर सकता है - देशी मेमोरी का इलाज करके इससे बचा जा सकता है संसाधन के रूप में और डिस्पोजल पैटर्न का उपयोग करते हुए, जैसा कि नीचे चर्चा की गई है। | ||
फ़ाइनलाइज़र आमतौर पर बहुत कम आवश्यक होते हैं और विध्वंसक की तुलना में बहुत कम उपयोग किए जाते हैं। वे बहुत कम आवश्यक हैं क्योंकि कचरा संग्रह स्मृति प्रबंधन को स्वचालित करता है, और बहुत कम उपयोग किया जाता है क्योंकि वे आम तौर पर निश्चित रूप से निष्पादित नहीं होते हैं - उन्हें समय पर ढंग से या बिल्कुल भी नहीं बुलाया जा सकता है, और निष्पादन वातावरण की भविष्यवाणी नहीं की जा सकती है - और इस प्रकार कोई भी क्लीनअप जो निश्चित रूप से किया जाना चाहिए, इसके बजाय किसी अन्य विधि द्वारा किया जाना चाहिए, अक्सर मैन्युअल रूप से निपटान पैटर्न के माध्यम से। विशेष रूप से, जावा और पायथन दोनों इस बात की गारंटी नहीं देते हैं कि फाइनलाइजर्स को कभी भी बुलाया जाएगा, और इस प्रकार उन्हें सफाई के लिए भरोसा नहीं किया जा सकता है। | फ़ाइनलाइज़र आमतौर पर बहुत कम आवश्यक होते हैं और विध्वंसक की तुलना में बहुत कम उपयोग किए जाते हैं। वे बहुत कम आवश्यक हैं क्योंकि कचरा संग्रह स्मृति प्रबंधन को स्वचालित करता है, और बहुत कम उपयोग किया जाता है क्योंकि वे आम तौर पर निश्चित रूप से निष्पादित नहीं होते हैं - उन्हें समय पर ढंग से या बिल्कुल भी नहीं बुलाया जा सकता है, और निष्पादन वातावरण की भविष्यवाणी नहीं की जा सकती है - और इस प्रकार कोई भी क्लीनअप जो निश्चित रूप से किया जाना चाहिए, इसके बजाय किसी अन्य विधि द्वारा किया जाना चाहिए, अक्सर मैन्युअल रूप से निपटान पैटर्न के माध्यम से। विशेष रूप से, जावा और पायथन दोनों इस बात की गारंटी नहीं देते हैं कि फाइनलाइजर्स को कभी भी बुलाया जाएगा, और इस प्रकार उन्हें सफाई के लिए भरोसा नहीं किया जा सकता है। | ||
उनके निष्पादन पर प्रोग्रामर नियंत्रण की कमी के कारण, आमतौर पर किसी भी लेकिन सबसे तुच्छ संचालन के लिए फाइनलाइज़र से बचने की सिफारिश की जाती है। विशेष रूप से, विध्वंसक में अक्सर किए जाने वाले ऑपरेशन आमतौर पर अंतिम रूप देने वालों के लिए उपयुक्त नहीं होते हैं। | उनके निष्पादन पर प्रोग्रामर नियंत्रण की कमी के कारण, आमतौर पर किसी भी लेकिन सबसे तुच्छ संचालन के लिए फाइनलाइज़र से बचने की सिफारिश की जाती है। विशेष रूप से, विध्वंसक में अक्सर किए जाने वाले ऑपरेशन आमतौर पर अंतिम रूप देने वालों के लिए उपयुक्त नहीं होते हैं। सामान्य विरोधी प्रतिमान फाइनलाइज़र लिखना है जैसे कि वे विध्वंसक थे, जो अनावश्यक और अप्रभावी दोनों हैं, अंतिम रूप देने वालों और विध्वंसकों के बीच अंतर के कारण। यह सी ++ प्रोग्रामर के बीच विशेष रूप से आम है, क्योंकि रिसोर्स एक्विजिशन इज़ इनिशियलाइज़ेशन (RAII) मुहावरे के बाद मुहावरेदार C ++ में डिस्ट्रक्टर्स का भारी उपयोग किया जाता है। | ||
== सिंटेक्स == | == सिंटेक्स == | ||
फाइनलाइज़र का उपयोग करने [[जावास्क्रिप्ट (प्रोग्रामिंग भाषा)]] में C++/CLI, C Sharp (प्रोग्रामिंग लैंग्वेज)|C#, [[ स्वच्छ (प्रोग्रामिंग भाषा) ]], [[ जाओ (प्रोग्रामिंग भाषा) ]], Java (प्रोग्रामिंग लैंग्वेज), JavaScript (प्रोग्रामिंग लैंग्वेज) और Python (प्रोग्रामिंग लैंग्वेज) शामिल हैं। वाक्य-विन्यास भाषा के अनुसार काफी भिन्न होता है। | फाइनलाइज़र का उपयोग करने [[जावास्क्रिप्ट (प्रोग्रामिंग भाषा)]] में C++/CLI, C Sharp (प्रोग्रामिंग लैंग्वेज)|C#, [[ स्वच्छ (प्रोग्रामिंग भाषा) ]], [[ जाओ (प्रोग्रामिंग भाषा) ]], Java (प्रोग्रामिंग लैंग्वेज), JavaScript (प्रोग्रामिंग लैंग्वेज) और Python (प्रोग्रामिंग लैंग्वेज) शामिल हैं। वाक्य-विन्यास भाषा के अनुसार काफी भिन्न होता है। | ||
जावा में, फाइनलाइज़र | जावा में, फाइनलाइज़र विधि है जिसे कहा जाता है <code>finalize</code>, जो ओवरराइड करता है <code>Object.finalize</code> तरीका।<ref name=java_Object.finalize>java.lang, क्लास ऑब्जेक्ट: [http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html# finalize() finalize]</ref> | ||
JavaScript में, [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry finalizationRegistry] आपको किसी वस्तु के कूड़ा-कचरा एकत्र करने पर कॉलबैक का अनुरोध करने की अनुमति देता है। | JavaScript में, [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry finalizationRegistry] आपको किसी वस्तु के कूड़ा-कचरा एकत्र करने पर कॉलबैक का अनुरोध करने की अनुमति देता है। | ||
पायथन में, फाइनलाइज़र | पायथन में, फाइनलाइज़र विधि है जिसे कहा जाता है <code>__del__</code>. | ||
पर्ल में, फ़ाइनलाइज़र | पर्ल में, फ़ाइनलाइज़र विधि है जिसे कहा जाता है <code>DESTROY</code>. | ||
सी # में, | सी # में, अंतिमकर्ता (मानक के पुराने संस्करणों में विनाशक कहा जाता है) एक विधि है जिसका नाम कक्षा का नाम है <code>~</code> पूर्वसर्ग, के रूप में <code>~Foo</code> - यह सी ++ डिस्ट्रक्टर के समान सिंटैक्स है, और इन विधियों को मूल रूप से डिस्ट्रक्टर्स कहा जाता था, अलग-अलग व्यवहार होने के बावजूद, सी ++ के साथ सादृश्य द्वारा, लेकिन इसके कारण होने वाले भ्रम के कारण इसका नाम बदलकर फाइनल कर दिया गया।<ref name=csharpname>{{harvnb|Jagger|Perry|Sestoft|2007|p=[https://books.google.com/books?id=g6axWRRpJZwC&dq=destructor+finalizer&pg=PA542 542]|ps=, "In the previous version of this standard, what is now referred to as a “finalizer” was called a “destructor”. Experience has shown that the term “destructor” caused confusion and often resulted in incorrect expectations, especially to programmers knowing C++. In C++, a destructor is called in a determinate manner, whereas, in C#, a finalizer is not. To get determinate behavior from C#, one should use <code>Dispose.</code>"}}</ref> | ||
सी ++/सीएलआई में, जिसमें विनाशक और फाइनलाइज़र दोनों हैं, | सी ++/सीएलआई में, जिसमें विनाशक और फाइनलाइज़र दोनों हैं, विनाशक एक विधि है जिसका नाम कक्षा का नाम है <code>~</code> पूर्वसर्ग, के रूप में <code>~Foo</code> (जैसा कि सी # में), और फाइनलाइज़र एक विधि है जिसका नाम कक्षा का नाम है <code>!</code> पूर्वसर्ग, के रूप में <code>!Foo</code>. | ||
गो फाइनलाइजर्स को कॉल करके सिंगल पॉइंटर पर लागू किया जाता है <code>runtime.SetFinalizer</code> मानक पुस्तकालय में काम करता है।<ref>{{Cite web|url=https://golang.org/pkg/runtime/#SetFinalizer|title=Runtime package - runtime - PKG.go.dev}}</ref> | गो फाइनलाइजर्स को कॉल करके सिंगल पॉइंटर पर लागू किया जाता है <code>runtime.SetFinalizer</code> मानक पुस्तकालय में काम करता है।<ref>{{Cite web|url=https://golang.org/pkg/runtime/#SetFinalizer|title=Runtime package - runtime - PKG.go.dev}}</ref> | ||
| Line 46: | Line 46: | ||
== कार्यान्वयन == | == कार्यान्वयन == | ||
फाइनलाइज़र को तब कहा जाता है जब [[वस्तु (कंप्यूटर विज्ञान)]] कचरा एकत्र किया जाता है - वस्तु कचरा (पहुंच योग्य) बनने के बाद, लेकिन इससे पहले कि उसकी मेमोरी को हटा दिया जाए। कचरा संग्राहक के विवेक पर अंतिम रूप से गैर-नियतात्मक रूप से होता है, और कभी नहीं हो सकता है। यह विनाशकों के साथ विरोधाभासी है, जिन्हें नियतात्मक रूप से कहा जाता है जैसे ही कोई वस्तु अब उपयोग में नहीं होती है, और अनियंत्रित कार्यक्रम समाप्ति के मामले को छोड़कर हमेशा कहा जाता है। ऑब्जेक्ट-विशिष्ट संचालन करने की आवश्यकता के कारण फ़ाइनलाइज़र अक्सर [[उदाहरण विधि]]याँ हैं। | |||
कचरा संग्राहक को वस्तु के पुनरुत्थान की संभावना का भी ध्यान रखना चाहिए। आमतौर पर यह पहले फाइनलाइजर्स को निष्पादित करके किया जाता है, फिर जांच की जाती है कि क्या कोई वस्तु फिर से जीवित हो गई है, और यदि ऐसा है, तो उनके विनाश को रद्द कर दिया गया है। यह अतिरिक्त जांच संभावित रूप से महंगी है - | कचरा संग्राहक को वस्तु के पुनरुत्थान की संभावना का भी ध्यान रखना चाहिए। आमतौर पर यह पहले फाइनलाइजर्स को निष्पादित करके किया जाता है, फिर जांच की जाती है कि क्या कोई वस्तु फिर से जीवित हो गई है, और यदि ऐसा है, तो उनके विनाश को रद्द कर दिया गया है। यह अतिरिक्त जांच संभावित रूप से महंगी है - साधारण कार्यान्वयन सभी कचरे की फिर से जाँच करता है यदि एक भी वस्तु को अंतिम रूप दिया जाता है - और इस तरह दोनों धीमा हो जाता है और कचरा संग्रह को जटिल बना देता है। इस कारण से, फ़ाइनलाइज़र वाली वस्तुओं को फ़ाइनलाइज़र के बिना वस्तुओं की तुलना में कम बार एकत्र किया जा सकता है (केवल कुछ चक्रों पर), संसाधन लीक जैसे शीघ्र अंतिमकरण पर निर्भर होने के कारण होने वाली समस्याओं को बढ़ा देता है। | ||
यदि किसी वस्तु को पुनर्जीवित किया जाता है, तो आगे का प्रश्न है कि क्या इसके फाइनलाइज़र को फिर से नष्ट कर दिया जाता है, जब इसे नष्ट कर दिया जाता है - विनाशकों के विपरीत, फाइनलाइज़र को संभावित रूप से कई बार बुलाया जाता है। यदि अंतिम रूप देने वालों को पुनर्जीवित वस्तुओं के लिए बुलाया जाता है, तो वस्तुएं बार-बार खुद को पुनर्जीवित कर सकती हैं और अविनाशी हो सकती हैं; यह Python 3.4 से पहले Python के CPython कार्यान्वयन में और C# जैसी CLR भाषाओं में होता है। इससे बचने के लिए, जावा, ऑब्जेक्टिव-सी (कम से कम हाल के ऐप्पल कार्यान्वयन में), और पायथन 3.4 से पायथन सहित कई भाषाओं में, वस्तुओं को एक बार में अंतिम रूप दिया जाता है, जिसके लिए ट्रैकिंग की आवश्यकता होती है यदि वस्तु को अभी तक अंतिम रूप दिया गया है। | यदि किसी वस्तु को पुनर्जीवित किया जाता है, तो आगे का प्रश्न है कि क्या इसके फाइनलाइज़र को फिर से नष्ट कर दिया जाता है, जब इसे नष्ट कर दिया जाता है - विनाशकों के विपरीत, फाइनलाइज़र को संभावित रूप से कई बार बुलाया जाता है। यदि अंतिम रूप देने वालों को पुनर्जीवित वस्तुओं के लिए बुलाया जाता है, तो वस्तुएं बार-बार खुद को पुनर्जीवित कर सकती हैं और अविनाशी हो सकती हैं; यह Python 3.4 से पहले Python के CPython कार्यान्वयन में और C# जैसी CLR भाषाओं में होता है। इससे बचने के लिए, जावा, ऑब्जेक्टिव-सी (कम से कम हाल के ऐप्पल कार्यान्वयन में), और पायथन 3.4 से पायथन सहित कई भाषाओं में, वस्तुओं को एक बार में अंतिम रूप दिया जाता है, जिसके लिए ट्रैकिंग की आवश्यकता होती है यदि वस्तु को अभी तक अंतिम रूप दिया गया है। | ||
| Line 56: | Line 56: | ||
== समस्याएं == | == समस्याएं == | ||
कार्यान्वयन के आधार पर, अंतिमकर्ता बड़ी संख्या में समस्याएं पैदा कर सकते हैं, और इस प्रकार कई अधिकारियों द्वारा दृढ़ता से हतोत्साहित किया जाता है।<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 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>Hans-J. Boehm, Finalization, Threads, and the Java™ Technology-Based Memory Model, JavaOne Conference, 2005.</ref> | ||
* फ़ाइनलाइज़र डेडलॉक का कारण बन सकता है यदि सिंक्रोनाइज़ेशन मैकेनिज़्म जैसे ताले का उपयोग किया जाता है, | * फ़ाइनलाइज़र डेडलॉक का कारण बन सकता है यदि सिंक्रोनाइज़ेशन मैकेनिज़्म जैसे ताले का उपयोग किया जाता है, निर्दिष्ट क्रम में नहीं चलने और संभवतः समवर्ती रूप से चलने के कारण। | ||
* प्रोग्राम समाप्ति के दौरान चलाए जाने वाले फ़ाइनलाइज़र सामान्य रनटाइम वातावरण पर भरोसा नहीं कर सकते हैं, और इस प्रकार गलत धारणाओं के कारण विफल हो सकते हैं - इस कारण फ़ाइनलाइज़र अक्सर समाप्ति के दौरान नहीं चलते हैं। | * प्रोग्राम समाप्ति के दौरान चलाए जाने वाले फ़ाइनलाइज़र सामान्य रनटाइम वातावरण पर भरोसा नहीं कर सकते हैं, और इस प्रकार गलत धारणाओं के कारण विफल हो सकते हैं - इस कारण फ़ाइनलाइज़र अक्सर समाप्ति के दौरान नहीं चलते हैं। | ||
इसके अलावा, प्रोग्रामिंग त्रुटियों के कारण या अप्रत्याशित रीचैबिलिटी के कारण कचरा होने की उम्मीद से परे पहुंच योग्य वस्तुओं के कारण अंतिम रूप से चलने में विफल हो सकते हैं। उदाहरण के लिए, जब पायथन | इसके अलावा, प्रोग्रामिंग त्रुटियों के कारण या अप्रत्याशित रीचैबिलिटी के कारण कचरा होने की उम्मीद से परे पहुंच योग्य वस्तुओं के कारण अंतिम रूप से चलने में विफल हो सकते हैं। उदाहरण के लिए, जब पायथन अपवाद को पकड़ता है (या अपवाद इंटरएक्टिव मोड में नहीं पकड़ा जाता है), यह स्टैक फ्रेम का संदर्भ रखता है जहां अपवाद उठाया गया था, जो उस स्टैक फ्रेम से संदर्भित वस्तुओं को जीवित रखता है। | ||
जावा में, | जावा में, सुपरक्लास में फ़ाइनलाइज़र उपवर्ग में कचरा संग्रह को धीमा कर सकता है, क्योंकि फ़ाइनलाइज़र संभावित रूप से उपवर्ग में फ़ील्ड्स को संदर्भित कर सकता है, और इस प्रकार फ़ाइनलाइज़र के चलने के बाद, अगले चक्र तक फ़ील्ड को कचरा एकत्र नहीं किया जा सकता है।<ref name=certjava/>[[वंशानुक्रम पर रचना]] का उपयोग करके इससे बचा जा सकता है। | ||
== संसाधन प्रबंधन == | == संसाधन प्रबंधन == | ||
{{main|Resource management (computing)}} | {{main|Resource management (computing)}} | ||
संसाधनों को जारी करने के लिए फ़ाइनलाइज़र का उपयोग करने के लिए | |||