मेमोरी से जावा हीप स्पेस

Question

मेरा एप्लिकेशन वर्तमान में बहुत सारी मेमोरी का उपभोग करता है क्योंकि यह भौतिकी सिमुलेशन चला रहा है। मुद्दा यह है कि लगातार 51 वें अनुकरण में, जावा आमतौर पर स्मृति से ढेर स्थान की वजह से एक त्रुटि फेंक देगा (मेरा कार्यक्रम अंततः हजारों सिमुलेशन चलाता है)।

क्या वैसे भी मैं केवल ढेर की जगह नहीं बढ़ा सकता लेकिन मेरे कार्यक्रम को संशोधित कर सकता हूं ताकि हर दौड़ के बाद हीप स्पेस को मंजूरी दे ताकि मैं सिमुलेशन की मनमाना संख्या चला सकूं?

धन्यवाद

-edit-

धन्यवाद दोस्तों। सिम्युलेटर सॉफ़्टवेयर को हर रन के बाद जानकारी साफ़ नहीं कर रहा था और मेरे पास उन सभी को एक सरणी सूची में संग्रहीत किया गया था।

Answer 1

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

Answer 2

अधिक मेमोरी (java -Xmx1024M YourClass) के लिए -Xmx जोड़ने का प्रयास करें, और उन संदर्भों को संदर्भित करना न भूलें जिन्हें आपको और अधिक (स्मृति लीक) की आवश्यकता नहीं है।

Answer 3

नहीं। जब भी ऐसा लगता है तो ढेर कचरा कलेक्टर द्वारा साफ़ किया जाता है। आप इसे चलाने के लिए कह सकते हैं (System.gc() के साथ) लेकिन इसे चलाने की गारंटी नहीं है।

पहले -Xmx256m

Answer 4

की स्थापना द्वारा स्मृति में वृद्धि का कोई उपाय नहीं गतिशील ढेर प्रोग्राम के बढ़ाने के लिए के बाद से ढेर जब जावा वर्चुअल मशीन शुरू कर दिया है आवंटित किया जाता है नहीं है की कोशिश करो।

हालांकि, अगर आप 1024

को स्मृति स्थापित करने के लिए इस आदेश

java -Xmx1024M YourClass 

उपयोग कर सकते हैं या, आप एक न्यूनतम अधिकतम

java -Xms256m -Xmx1024m YourClassNameHere 

Answer 5

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

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

Answer 6

इस समस्या का निदान करने में सहायता के लिए आप विभिन्न प्रकार के टूल का उपयोग कर सकते हैं। जेडीके में JVisualVM शामिल है जो आपको अपनी चल रही प्रक्रिया से जुड़ने की अनुमति देगा और दिखाएगा कि कौन से ऑब्जेक्ट्स नियंत्रण से बाहर हो सकते हैं। नेटबीन्स के चारों ओर एक रैपर है जो काफी अच्छी तरह से काम करता है। ग्रहण में एक्लिप्स मेमोरी विश्लेषक है जो कि मैं अक्सर उपयोग करता हूं, बस बड़ी डंप फ़ाइलों को थोड़ा बेहतर तरीके से संभालने लगता है। एक कमांड लाइन विकल्प भी है, -XX:+HeapDumpOnOutOfMemoryError जो आपको एक फ़ाइल देगा जो मूल रूप से आपकी प्रक्रिया मेमोरी का स्नैपशॉट होगा जब आपका प्रोग्राम क्रैश हो जाएगा। आप इसे देखने के लिए उपरोक्त उल्लिखित टूल का उपयोग कर सकते हैं, इस तरह की समस्याओं का निदान करते समय यह वास्तव में बहुत मदद कर सकता है।

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

Answer 7

आप स्मृति का एक बहुत का उपयोग करने और मेमोरी लीक का सामना कर रहे हैं, तो आप यदि आप कई तत्वों से प्रत्येक के साथ ArrayList या HashMap रों की एक बड़ी संख्या का उपयोग कर रहे जांच करना चाह सकते।

एक ArrayList को dynamic array के रूप में कार्यान्वित किया गया है। सूर्य/ओरेकल से स्रोत कोड से पता चलता है कि जब एक नया तत्व पूर्ण ArrayList में डाला जाता है, तो मूल सरणी के 1.5 गुना आकार की एक नई सरणी बनाई जाती है, और तत्वों की प्रतिलिपि बनाई जाती है। इसका मतलब यह है कि आप प्रत्येक ArrayList में 50% तक का स्थान बर्बाद कर सकते हैं, जब तक कि आप इसकी trimToSize विधि को कॉल न करें। या बेहतर अभी भी, यदि आप उन तत्वों की संख्या जानते हैं जिन्हें आप हाथ से पहले डालने जा रहे हैं, तो कन्स्ट्रक्टर को प्रारंभिक क्षमता के साथ इसकी तर्क के रूप में कॉल करें।

मैंने HashMap के लिए स्रोत कोड की जांच नहीं की है, लेकिन पहली नज़र में ऐसा लगता है कि प्रत्येक HashMap में सरणी लंबाई दो की शक्ति होनी चाहिए, जिससे इसे गतिशील सरणी का एक और कार्यान्वयन किया जा सके। ध्यान दें कि HashSet अनिवार्य रूप से HashMap के आसपास एक रैपर है।

Answer 8

मुझे भी एक ही समस्या का सामना करना पड़ा। मैंने निम्नलिखित चरणों का पालन करके निर्माण करके हल किया।

-> भागो विन्यास

BaseDirectory के रूप में अपनी परियोजना का चयन करें -> परियोजना पर राइट क्लिक करें RunAs का चयन करें। लक्ष्यों के स्थान पर ग्रहण दें: ग्रहण

-> दूसरे टैब में -एमएमएक्स 1024 मीटर वीएम तर्क के रूप में दें।

Answer 9

मैं यह जोड़ना चाहता हूं कि यह समस्या सामान्य जावा मेमोरी लीक के समान है।

जब JVM कचरा कलेक्टर समय के साथ आपके जावा/जावा ईई अनुप्रयोग की "अपशिष्ट" स्मृति को साफ़ करने में असमर्थ है, तो OutOfMemoryError: Java heap space परिणाम होगा।

यह पहली बार एक उचित निदान प्रदर्शन करने के लिए महत्वपूर्ण है:

• verbose:gc सक्षम करें। यह आपको समय के साथ स्मृति बढ़ते पैटर्न को समझने की अनुमति देगा।
• JVM Heap Dump उत्पन्न और विश्लेषण करें। यह आपको अपने एप्लिकेशन मेमोरी पदचिह्न को समझने और स्मृति रिसाव के स्रोत को इंगित करने की अनुमति देगा।
• आप जावा प्रोफाइलर्स और रनटाइम मेमोरी लीक विश्लेषक का उपयोग भी कर सकते हैं जैसे Plumbr साथ ही इस कार्य के साथ आपकी सहायता के लिए।