भले ही जावा एप्लेट इन दिनों एक लोकप्रिय वेब तकनीक नहीं हैं, लेकिन जावा वर्चुअल मशीन को सीधे लिनक्स सर्वर पर तैनात करने के अनगिनत कारण हैं। यदि आप लिनक्स जावा कमांड को सीधे असतत हार्डवेयर पर या अपने स्वयं के वीएम के अंदर चलाने का प्रयास करते हैं, तो आपको "वीएम के प्रारंभ के दौरान त्रुटि हुई, ऑब्जेक्ट हीप के लिए पर्याप्त स्थान आरक्षित नहीं कर सका" संदेश मिल सकता है।
यह शायद अजीब लगता है क्योंकि आपके पास कमांड चलाने के लिए पर्याप्त रैम होने की संभावना अधिक है, लेकिन यह काफी हद तक भौतिक और आभासी मेमोरी पेजों के उपयोग के तरीके में एक विशिष्ट विचित्रता के कारण है। कुछ अपेक्षाकृत बड़े आकारों को निर्दिष्ट करने से आप इस संदेश को पूरी तरह से बायपास कर सकते हैं और जावा कमांड को वैसे ही चला सकते हैं जैसे आप किसी अन्य को करेंगे।
विधि 1:कमांड लाइन विकल्पों का उपयोग करना
यदि आपने जावा चलाने की कोशिश की है और यह संदेश प्राप्त किया है, तो आप शायद यह सुनिश्चित करने के लिए पहले ही फ्री कमांड चला चुके हैं कि प्रोग्राम को चलाने के लिए मेमोरी की पर्याप्त आपूर्ति है।
ध्यान दें कि हमारी परीक्षण मशीन पर हमारे पास लगभग 2.3 जीबी की भौतिक रैम थी और वर्चुअल मेमोरी का एक भी पृष्ठ अभी तक उपयोग नहीं किया गया था। यदि आप देखते हैं कि आपके पास मेमोरी क्रंच है, तो आप इसे फिर से कोशिश करने से पहले अन्य चीजों को बंद करना चाहेंगे जो आप चला रहे हैं। दूसरी ओर, जिन लोगों ने पाया कि उनके पास बहुत सारी मुफ्त मेमोरी है, वे सीधे एक आकार निर्दिष्ट करने का प्रयास कर सकते हैं।
उदाहरण के लिए, हमारी मशीन पर हम कमांड को java -Xms256m -Xmx512M के रूप में चलाने में सक्षम थे और इसने काम किया जैसे कि अन्यथा इसकी उम्मीद की जाती। यह ढेर के आकार को बाधित करता है जिसे जावा वर्चुअल मशीन स्टार्टअप पर आरक्षित करने का प्रयास करती है। चूंकि एक अनियंत्रित वर्चुअल मशीन काल्पनिक रूप से असामान्य चीजें कर सकती है, यह त्रुटि संदेशों को अन्यथा मुक्त सिस्टम पर फेंक सकती है। सही संयोजन खोजने से पहले आप उन दो मूल्यों के साथ खेलना चाह सकते हैं।
यह एक मुद्दा हो सकता है चाहे आप इसे किस पर चला रहे हों क्योंकि JVM का उस VM के प्रकार से कोई लेना-देना नहीं है जिसका उपयोग आप GNU/Linux को चलाने के लिए कर रहे हैं।
विधि 2:परिवर्तन को स्थायी बनाने के लिए चर का निर्यात करना
जब आपको कोई मान मिलता है जो काम करता है तो आप इसे उस सत्र के लिए स्थायी बनाने के लिए निर्यात कर सकते हैं। उदाहरण के लिए, हमने बैश कमांड प्रॉम्प्ट से निर्यात _JAVA_OPTIONS='-Xms256M -Xmx512M' का उपयोग किया और इसने हमें अपने सर्वर से लॉग आउट होने तक बिना किसी अन्य विकल्प के जावा कमांड को चलाने की अनुमति दी।
जब हम दूसरे सत्र में लॉग इन करते हैं तो इसे फिर से चलाने की आवश्यकता होती है, इसलिए यदि आप अक्सर जावा कमांड का उपयोग करने की योजना बनाते हैं तो आप इसे किसी भी प्रासंगिक स्टार्टअप स्क्रिप्ट में जोड़ना चाहेंगे। हमने अपनी .bash_login फ़ाइल में लाइन जोड़ दी है और यह हर बार काम करती प्रतीत होती है जब हम इसे फिर से चलाने के बिना लॉगिन प्रॉम्प्ट का उपयोग करते हैं, हालांकि यदि आप एक अलग शेल के साथ काम कर रहे हैं तो आपको इसके लिए कोई अन्य स्थान ढूंढना पड़ सकता है।
आपने देखा होगा कि केवल कुछ हार्डवेयर कॉन्फ़िगरेशन ही इस त्रुटि संदेश को ट्रिगर करते हैं। ऐसा इसलिए है क्योंकि यह आमतौर पर बहुत अधिक भौतिक RAM वाली मशीनों पर होता है, लेकिन इसका उपयोग करने के लिए कम सीमाएँ होती हैं। जावा केवल एक विशाल ब्लॉक आवंटित करने का प्रयास करेगा, यह बताने के लिए कि वह नहीं कर सकता, जिसे वह स्मृति से बाहर होने के रूप में व्याख्या करता है।
विधि 3:वर्तमान जावा विकल्प प्रिंट करना
यदि आप कमांड लाइन पर काम कर रहे हैं और आप वर्तमान में _JAVA_OPTIONS मान को सेट करने के लिए एक त्वरित संदर्भ चाहते हैं, तो बस echo $_JAVA_OPTIONS चलाएं और यह तुरंत वर्तमान मानों को प्रिंट कर लेगा। जब आप कोशिश करने के लिए सही अंकों का पता लगाने की कोशिश कर रहे हों तो समस्या निवारण के लिए यह उपयोगी है।
ध्यान रखें कि जब इस फिक्स को किसी अन्य खेल की आवश्यकता नहीं होनी चाहिए, तो जावा "ऑब्जेक्ट हीप के लिए पर्याप्त स्थान आरक्षित नहीं कर सका" संदेश को फेंक देगा यदि आप कभी भी वर्चुअल मेमोरी के छोटे छोर पर खुद को वास्तव में पाते हैं। यदि ऐसा है, तो आप दोबारा जांचना चाहेंगे कि वर्तमान में कौन सी प्रक्रियाएं चल रही हैं और यदि यह एक विकल्प है तो संभवतः सर्वर को पुनरारंभ करें। आप अधिक स्वैप स्थान भी बना सकते हैं, लेकिन यदि यह एक समस्या है तो इसे किसी अन्य तरीके से ठीक करने का प्रयास करना बेहतर है।
दुर्लभ मामले में कि आपकी सेटिंग्स सही लगती हैं लेकिन यह अभी भी काम नहीं कर रही है, सुनिश्चित करें कि आपने 64-बिट जावा पैकेज स्थापित किया है क्योंकि यह इस समस्या से प्रतिरक्षा होना चाहिए। निरंतर स्मृति आवश्यकताएँ केवल जावा के 32-बिट संस्करण पर लागू होती हैं। हमने पाया कि कुछ मामलों में 64-बिट संस्करण ने 32-बिट वर्चुअल मशीन बनाने की कोशिश की, इसलिए कमांड लाइन पर -d64 विकल्प निर्दिष्ट करने से यह हमारे लिए ठीक हो गया।