🤶🏽 🤷🏼 👉 अंतिम विधि के खतरे 🌜 🤟🏻 👩

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

तो, चलो स्पष्ट से कम सहज तक जाते हैं।

चूँकि पहले कचरा संग्रहण के दौरान अंतिम विधि को कॉल किया जाता है, जब आपकी वस्तु अनुपलब्ध हो जाती है, तो यह बहुत संभव है कि इसे बिल्कुल भी नहीं बुलाया जाएगा, क्योंकि आपका आवेदन इस कचरा संग्रह तक पहुँचने के बिना अपना काम पूरा कर सकता है। हालांकि, निश्चित रूप से, एक अद्भुत विधि System.runFinalizersOnExit (सच) है , जिसे कॉल करते हुए कार्यक्रम की शुरुआत में, अंतिम एप्लिकेशन विधि अभी भी सही एप्लिकेशन स्टॉप के दौरान पहले से ही अनुपलब्ध वस्तुओं के लिए काम करेगी।
JVM विनिर्देशन अंतिमकरण विधि के मल्टीथ्रेडिंग के मुद्दे को संबोधित नहीं करता है। हॉटस्पॉट में, सभी अंतिम तरीकों को एकल फाइनल थ्रेड में क्रमिक रूप से कहा जाएगा। हालाँकि, यदि आप System.runFinalization () विधि को कॉल करते हैं, तो एक और थ्रेड पैदा होगा जो वर्तमान को अवरुद्ध करेगा और कतार में उपयुक्त ऑब्जेक्ट होने पर तरीकों को अंतिम रूप देगा। इसके अलावा, यह अच्छी तरह से फाइनल की मुख्य धारा के समानांतर हो सकता है।
अंतिम विधि को ओवरराइड करने से मृत्यु के बाद ऑब्जेक्ट का जीवनकाल काफी लंबा हो जाता है, क्योंकि यह दूसरे कचरा संग्रह तक मेमोरी से हटाया नहीं जाएगा। और पहले दो बिंदुओं को देखते हुए, यदि अंतिम विधि आपके लिए कठिन है और / या इस तरह की बहुत सारी वस्तुएं होंगी, तो वस्तुएं अंतिम चरण में लंबे समय तक लटक सकती हैं और मेमोरी स्पेस पर कब्जा करना जारी रख सकती हैं।
अंतिम विधि के दौरान, आप ऑब्जेक्ट के संदर्भ को पुनर्स्थापित कर सकते हैं, उदाहरण के लिए, इसे कुछ स्थैतिक संदर्भ में रखकर, जिससे ऑब्जेक्ट फिर से जीवित हो जाए। इस तरह के युद्धाभ्यास का खतरा यह है कि दूसरी बार इस वस्तु पर अंतिम रूप देने की विधि को कभी नहीं कहा जाएगा। इसलिए, यदि किसी कारण से आपको वास्तव में इस ऑब्जेक्ट को पुनर्जीवित करने की आवश्यकता है, तो अंतिम विधि के अंदर एक प्रतिलिपि बनाना बेहतर है।
अंतिम विधि का उपयोग करते समय सबसे कष्टप्रद समस्याओं में से एक पुन: प्रतिपादन है। कल्पना करें कि आपके पास एक ओवरराइड फ़ाइनल विधि के साथ दो ऑब्जेक्ट हैं, जिनमें से एक दूसरे को संदर्भित करता है। इसलिए, अगर ये ऑब्जेक्ट अप्राप्य हो गए हैं, तो अंतिम रूप से कॉल करने का क्रम यादृच्छिक क्रम में होगा। इस प्रकार, आपके पास किसी अन्य विधि की अंतिम विधि से पहले से ही अंतिम रूप दी गई वस्तु पर किसी विधि को कॉल करने का संभावित खतरा होगा और एक त्रुटि प्राप्त होगी। इसके अलावा, समस्या हर वस्तु पर नहीं होगी, जो डिबगिंग के समय सिरदर्द जोड़ देगी।
प्रसिद्ध पुस्तक "इफेक्टिव जावा: प्रोग्रामिंग लैंग्वेज गाइड" के लेखक जोशुआ ब्लोच के अनुसार, ओवरराइड फ़ाइनल विधि के साथ ऑब्जेक्ट के लिए, आवंटन और असेंबली एक नियमित ऑब्जेक्ट की तुलना में 430 गुना धीमी हो सकती है।
विधि निकाय में फेंके गए किसी भी अपवाद को अनदेखा किया जाएगा।
हमें पद्धति के अंत में super.finalize () कॉल करना नहीं भूलना चाहिए। और पिछले पैराग्राफ को देखते हुए, आपको अंततः ब्लॉक में ऐसा करने की आवश्यकता है।

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

अंतिम विधि के खतरे

More articles: