क्या OutOfMemoryError को कैप्चर करना इतना बुरा विचार है?

Question

संभव डुप्लिकेट:
Catching java.lang.OutOfMemoryError

OutOfMemoryError हैं: क्योंकि यह स्मृति से बाहर है, और कोई और अधिक

फेंक दिया जब जावा वर्चुअल मशीन एक वस्तु आवंटित नहीं कर सकता स्मृति कचरा कलेक्टर

012 द्वारा उपलब्ध कराया जा सकता है

जावा का कहना है:

कोई त्रुटि फेंकने योग्य का एक उपवर्ग है कि गंभीर समस्याओं इंगित करता है कि एक उचित आवेदन को पकड़ने की कोशिश नहीं करनी चाहिए। ऐसी अधिकांश त्रुटियां असामान्य स्थितियां हैं।

यह सुनवाई की तरह लगता है:

आप डूब रहे हैं, तो उचित होना: यदि आप ऊपर की तरफ पानी के ऊपर अपने सिर रखने के लिए तैरने के लिए कोशिश नहीं करनी चाहिए। मृत्यु आमतौर पर असामान्य स्थितियों से होती है।

चलो एक परिदृश्य की कल्पना करें जहां कोई सेवा चला रहा है। किसी कारण से, एक ही सर्वर पर एक और एप्लीकेशन बहुत मेमोरी खा रहा है, जिससे आपकी सेवा में एक अप्रत्याशित ओओएम हो रहा है। क्या उपयोगकर्ता के लिए उपलब्ध रहने के लिए इस सेवा की स्मृति खपत को कम करने का प्रयास करना इतना बुरा विचार है?

या ओओएम फेंकने के बाद ऐसे समाधान के कार्यान्वयन को रोकने के लिए जेवीएम स्तर पर कुछ और मौलिक हो रहा है?

Answer 1

समस्या यह है कि ओओएम एक त्रुटि है जो सामान्य परिस्थितियों में नहीं होनी चाहिए। इसे पकड़कर और स्मृति को रिहा करने की कोशिश करके, आप किसी अन्य प्रकार के रिसाव या अनजान व्यवहार को कहीं और अस्पष्ट कर रहे हैं।

यदि आपको ओओएम मिलता है, तो शायद ऐसा इसलिए है क्योंकि आपने अधिक स्मृति का उपयोग करने के लिए JVM को कॉन्फ़िगर नहीं किया है।

Answer 2

आप उद्धृत

फेंक दिया जब जावा वर्चुअल मशीन एक वस्तु क्योंकि यह स्मृति से बाहर है आवंटित नहीं कर सकता है, और कोई अधिक स्मृति उपलब्ध कराया जा सकता है कचरा कलेक्टर द्वारा

उस समय आप खराब हो गए हैं। उस वर्णन का तात्पर्य है कि जावा/जेवीएम को संचालित करने के लिए पर्याप्त संसाधन नहीं मिल सकते हैं, और यदि यह सत्य है, तो समस्या को ठीक करने के लिए अधिक जावा कोड निष्पादित करना समस्याग्रस्त हो जाएगा।

एक अच्छी सादृश्य यह है कि आपकी कार गैस से बाहर हो गई है, और आप त्वरक पर कदम उठाकर इसे ठीक करना चाहते हैं।

एक बेहतर समाधान क्षमता की योजना है और बनाने के लिए है सुनिश्चित करें

1) आपके सर्वर को अपनी नौकरी
2) सेवाओं अपने सर्वर पर चल कल्पना के भीतर करते हैं और अधिक से अधिक उपभोग नहीं करते करने के लिए पर्याप्त स्मृति संसाधनों की एक निश्चित राशि।

Answer 3

यह एक बुरा विचार है। मुख्य रूप से क्योंकि OutOfMemoryErrorErrorException नहीं है - एक त्रुटि "गंभीर मुद्दों को इंगित करती है कि एक उचित अनुप्रयोग को पकड़ने की कोशिश नहीं करनी चाहिए।"

इसके बजाय, अपने संभव परिदृश्यों का विश्लेषण करते हैं और इस PDF

Answer 4

यह बेकार है में उपलब्ध कराई गई जानकारी के आधार पर फिक्स लागू होते हैं। क्योंकि फिलहाल त्रुटि पकड़ ली जाती है, आप ढेर स्मृति की इतनी कम हो सकती है कि कोई भी नई ऑब्जेक्ट सृजन एक नया ओओएमई फेंक सकता है। पकड़ में घुसपैठ के इस तरह के एक छोटे से मार्जिन होने का मतलब है कि आप केवल एक ही कार्रवाई बाहर निकलना है।

टेस्ट इस स्निपेट, और मुझे बताओ कि क्या अपने उत्पादन होता है:

 import java.util.LinkedList; 
     import java.util.List; 

     public class OOMErrorTest { 


     public static void main(String[] args) { 
      List<Long> ll = new LinkedList<Long>(); 

      try { 
       long l = 0; 
       while(true){ 
        ll.add(new Long(l++)); 
       } 
      } catch(OutOfMemoryError oome){   
       System.out.println("Error catched!!"); 
       System.out.println("size:" +ll.size()); 
      } 
      System.out.println("Test finished"); 
     } 

     } 

लेकिन सख्ती से बोला, हाँ, इन catchable हैं।

Answer 5

आप वास्तव में ओओएम से ठीक नहीं हो सकते हैं।

हालांकि कुछ भी कोशिश करने और पकड़ने का एक कारण है - "कैच-फेंकने योग्य" गुट ने मुझे बताया कि जब हमने एक परियोजना में ठीक से काम किया था, तो मैं ऐसा नहीं कर रहा था - यह एक कारण है: क्या हुआ यह लॉग करने का प्रयास करें। क्योंकि अगर आपको नहीं पता कि क्या हुआ यह पता लगाना मुश्किल है कि सॉफ़्टवेयर को बैक अप और चलाने के तरीके को कैसे प्राप्त किया जाए।

एक कारण भी एक बड़ा "लेकिन" है: यह आमतौर पर काम नहीं करेगा।

त्रुटियां आमतौर पर आपके चल रहे कोड के भीतर से तय नहीं की जा सकती हैं, यही कारण है कि वह अंतर है।