संसाधनों को बंद करने के लिए मुझे अंततः उपयोग करने की आवश्यकता क्यों है?

Question

अधिकांश समय, केवल एक चीज मैं एक अंत में के लिए इस्तेमाल किया ब्लॉक दिखाई है की तरह

FileInputStream f; 
try{ 
    f= new FileInputStream("sample.txt"); 
    //something that uses f and sometimes throws an exception 
} 
catch(IOException ex){ 
    /* Handle it somehow */ 
} 
finally{ 
    f.close(); 
} 

कुछ मेरा प्रश्न है, अगर f की गुंजाइश संलग्न ब्लॉक, इसलिए हम अंत में में इसे बंद करने की आवश्यकता है के साथ समाप्त होता ?

Answer 1

क्योंकि कचरा संग्रह संसाधन सफाई के समान ही नहीं है।

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

फ़ाइल हैंडल और किसी भी अन्य संसाधन के साथ ही। अपने आप के बाद साफ करो।

Answer 2

ठीक है आपने एक बुरा उदाहरण दिया है - मुझे संदेह है कि आपका मतलब FileInputStream जैसा था - लेकिन मूल कारण यह है कि जावा में निर्धारिती अंतिमकरण नहीं है।

के दायरे चरf ब्लॉक उस में (नहीं try ब्लॉक) घोषित की गई साथ समाप्त होता है, लेकिन इसका मतलब यह नहीं है कि जरूरी नहीं "लाइव" वस्तु किसी भी अधिक के लिए संदर्भ देखते हैं - और कचरा कलेक्टर न तो वस्तु को अंतिम रूप देगा और न ही कचरा इसे किसी भी निर्धारिक तरीके से इकट्ठा करेगा।

जब तक कि आप मनमाने ढंग से समय के लिए लटकते संसाधनों को छोड़ना नहीं चाहते हैं (और कचरा संग्रह में देरी करते हैं, क्योंकि अंतिम रूप से स्मृति को अंततः रिलीज़ होने से पहले संग्रह के अतिरिक्त दौर की आवश्यकता होती है), आपको स्पष्ट रूप से संसाधन बंद करना चाहिए।

मूल रूप से जावा उसी तरह से RAII का समर्थन करता है जिस तरह से C++ करता है; आपको इसका उपयोग करने की कोशिश नहीं करनी चाहिए जैसे कि यह सी ++ था।

Answer 3

कारण यह है कि जावा गारंटी नहीं देता है कि जैसे ही कोई विशेष संदर्भ इसके दायरे से बाहर हो जाता है, एक वस्तु कचरा-संग्रहित हो जाएगी। इसलिए उन ऑब्जेक्ट्स के लिए जो सीमित सिस्टम संसाधनों को संदर्भित करते हैं, जैसे फाइल डिस्क्रिप्टर, कचरा संग्रह की प्रतीक्षा करने के लिए पर्याप्त नहीं है।

नोट हालांकि, java.io.File वास्तव में ऐसी वस्तु नहीं है।

Answer 4

क्योंकि अंततः हर बार कहा जाता है, भले ही आपको अपवाद उठाया गया हो। अंत में ब्लॉक आपको बीमा करता है कि फ़ाइल/कनेक्शन बंद हो जाएगा।

Answer 5

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