जावा में संसाधनों को ठीक से मुक्त करना

जावा प्रोग्रामर के बीच संसाधनों को गलत तरीके से मुक्त करना सबसे आम तौर पर की गई त्रुटियों में से एक है। इस लेख में संसाधन से मेरा मतलब सब कुछ होगा जो java.io.Closeable इंटरफ़ेस को लागू करता है। तो, इस बिंदु पर सही है।

हम OutputStream के उदाहरण पर विचार करेंगे। कार्य: इनपुट के लिए एक OutputStream प्राप्त करें, इसके साथ कुछ उपयोगी कार्य करें, OutputStream बंद करें।

गलत निर्णय नंबर 1

 OutputStream stream = openOutputStream(); // -   stream stream.close(); 

यह समाधान खतरनाक है क्योंकि यदि कोई अपवाद कोड में फेंक दिया जाता है, तो stream.close () नहीं कहा जाएगा। एक संसाधन रिसाव होगा (कनेक्शन बंद नहीं होगा, फ़ाइल विवरणक को मुक्त नहीं किया जाएगा, आदि)

गलत निर्णय नं। २

चलो पिछले कोड को ठीक करने का प्रयास करते हैं। हम try-finally :

 OutputStream stream = openOutputStream(); try { // -   stream } finally { stream.close(); } 

अब close() हमेशा कहा जाएगा (क्योंकि finally ): संसाधन वैसे भी मुक्त हो जाएगा। सब कुछ सही होने लगता है। क्या ऐसा है?

नहीं।

समस्या इस प्रकार है। close() विधि एक अपवाद फेंक सकती है। और अगर एक ही समय में संसाधन के साथ काम करने के लिए मुख्य कोड भी एक अपवाद फेंकता है, तो यह close() से अपवाद से आगे निकल जाएगा। मूल त्रुटि के बारे में जानकारी खो जाएगी: हम कभी नहीं जान पाएंगे कि मूल अपवाद का क्या कारण है।

गलत निर्णय संख्या 3

आइए स्थिति को ठीक करने का प्रयास करें। यदि stream.close() "मुख्य" अपवाद को पकड़ सकता है, तो चलो close() से अपवाद को "निगल" दें:

 OutputStream stream = openOutputStream(); try { // -   stream } finally { try { stream.close(); } catch (Throwable unused) { //  } } 

अब सब ठीक लगने लगा है। हम चाय पीने जा सकते हैं।

कोई फर्क नहीं पड़ता कि कैसे। यह समाधान पिछले वाले से भी बदतर है। क्यों?

क्योंकि हमने अभी close() से अपवाद को पकड़ा और निगल लिया था। कहते हैं कि outputStream एक FileOutputStream है, जो FileOutputStream लिपटा हुआ है। चूँकि BufferedOutputStream में अंतर्निहित स्ट्रीम पर flush() करता है, इसलिए संभावना है कि वह इसे close() कॉल के दौरान कॉल करेगा। अब कल्पना करें कि जिस फाइल को हम लिख रहे हैं वह लॉक है। फिर close() विधि एक IOException को फेंक IOException , जिसे सफलतापूर्वक खाया जाएगा। उपयोगकर्ता डेटा का एक भी बाइट फ़ाइल में नहीं लिखा गया था, और हमने इसके बारे में कुछ भी नहीं सीखा। सूचना गुम हो गई।

यदि हम इस समाधान की तुलना पिछले वाले से करते हैं, तो हम कम से कम यह पता लगाएंगे कि कुछ बुरा हुआ है। यहां, सभी त्रुटि जानकारी गायब हो जाती है।

नोट: यदि OutputStream बजाय InputStream उपयोग किया जाता है, तो इस कोड को जीवन का अधिकार है। तथ्य यह है कि अगर एक अपवाद InputStream.close() में फेंक दिया जाता है, तो (सबसे अधिक संभावना है) कोई भी बुरा परिणाम नहीं होगा, क्योंकि हम पहले से ही इस धारा से जो कुछ भी चाहते थे, उस पर विचार करते हैं। इसका मतलब है कि InputStream और OutputStream का पूरी तरह से अलग शब्दार्थ है।

इम्पेक्ट सॉल्यूशन

तो, संसाधन संसाधन कोड सही कैसे दिखता है?

हमें यह विचार करने की आवश्यकता है कि यदि मुख्य कोड एक अपवाद फेंकता है, तो इस अपवाद को पूर्ववर्ती की तुलना में अधिक लेना चाहिए, जिसे close() विधि द्वारा फेंका जा सकता है। यह इस तरह दिखता है:

 OutputStream stream = openOutputStream(); Throwable mainThrowable = null; try { // -   stream } catch (Throwable t) { //   mainThrowable = t; //      throw t; } finally { if (mainThrowable == null) { //    .   close() stream.close(); } else { try { stream.close(); } catch (Throwable unused) { // ,      //     ( ) } } } 

इस निर्णय के नुकसान स्पष्ट हैं: बोझिल और कठिन। इसके अलावा, यदि मुख्य कोड अपवाद को फेंकता है, तो close() से अपवाद close() बारे में जानकारी खो जाती है। इसके अलावा openOutputStream() null वापस आ सकता है, और फिर एक NullPointerException को NullPointerException जाएगा (यदि एक और जोड़कर हल किया जाए, जो और भी अधिक बोझिल कोड की ओर जाता है)। अंत में, यदि हमारे पास दो संसाधन हैं (उदाहरण के लिए, InputStream और OutputStream ) या अधिक, तो कोड बस असहनीय जटिल हो जाएगा।

सही समाधान (जावा 7)

जावा 7 ने try-with-resources निर्माण का try-with-resources शुरू किया। हम इसका उपयोग करते हैं:

 try (OutputStream stream = openOutputStream()) { // -   stream } 

और वह यह है।

यदि एक अपवाद मुख्य कोड में और close() विधि में फेंका जाता है, तो पहला अपवाद प्राथमिकता होगा, और दूसरा अपवाद दबा दिया जाएगा, लेकिन इसके बारे में जानकारी सहेज ली Throwable.addSuppressed(Throwable exception) विधि का उपयोग करके, जिसे जावा संकलक द्वारा अंतर्निहित कहा जाता है):

 Exception in thread "main" java.lang.RuntimeException: Main exception at A$1.write(A.java:16) at A.doSomething(A.java:27) at A.main(A.java:8) Suppressed: java.lang.RuntimeException: Exception on close() at A$1.close(A.java:21) at A.main(A.java:9) 

सही समाधान (Google अमरूद का उपयोग करके जावा 6)

जावा 6 में, अकेले मानक पुस्तकालय के उपकरण अपरिहार्य हैं। हालाँकि, हमारी सहायता के लिए अद्भुत Google अमरूद पुस्तकालय आता है। वर्ग com.google.common.io.Closer (गरीबों के लिए try-with-resources ) अमरूद 14.0 में दिखाई दिया है, जिसकी मदद से उपरोक्त अपूर्ण समाधान को सरल बनाया जा सकता है:

 Closer closer = Closer.create(); try { OutputStream stream = closer.register(openOutputStream()); // -   stream } catch (Throwable e) { //     (  Error') throw closer.rethrow(e); } finally { closer.close(); } 

समाधान जावा 7 की तुलना में काफी लंबा है, लेकिन अपूर्ण समाधान की तुलना में बहुत कम है। आउटपुट लगभग जावा 7 जैसा ही होगा।

Closer इसमें संसाधनों की एक मनमानी राशि ( register(...) विधि) का भी समर्थन करता है। दुर्भाग्य से, Closer एक वर्ग है जो @Beta एनोटेशन के साथ चिह्नित है, जिसका अर्थ है कि यह लाइब्रेरी के भविष्य के संस्करणों (विलोपन तक) में महत्वपूर्ण बदलावों से गुजर सकता है।

निष्कर्ष

संसाधनों को सही ढंग से जारी करना उतना आसान नहीं है जितना लगता है (केवल जावा 7 में)। इस पर हमेशा ध्यान दें। InputStream और OutputStream ( Reader और Writer ) को अलग-अलग तरीके से संभाला जाता है (कम से कम जावा 6 में)!

परिवर्धन / सुधार का स्वागत है!

अगली बार मैं यह बताने की योजना बना रहा हूं कि NullPointerException कैसे निपटें।