मेरे पास एक जावा एप्लिकेशन है जो system.gc() को आमंत्रित करना चाहता है। क्या यह स्मृति जारी करने के लिए एक उचित तरीका है? या कोई अन्य सलाह? वास्तव में सराहना!जावा एप्लिकेशन में स्मृति प्रबंधित करने के लिए 'System.gc()' को एक अच्छा तरीका बुला रहा है?
बस चर का संदर्भ देना बंद करें। आपको System#gc() स्वयं को आमंत्रित करने की आवश्यकता नहीं है। यदि JVM OutOfMemoryError के किनारे पर है, तो निश्चित रूप से जीसी चलाएगा।
यदि वेरिएबल्स को संदर्भित करना बंद करना एक विकल्प नहीं है क्योंकि आप वास्तव में की आवश्यकता है, तो आपको किसी भी मेमोरी लीक को ठीक/साफ करने के लिए अपने एप्लिकेशन को प्रोफ़ाइल करने की आवश्यकता है और/या स्टार्टअप पर बस JVM को और स्मृति दें।
का उपयोग करके किसी को भी देखा है यह भी ध्यान दें कि System.gc() को कॉल करने से यह गारंटी नहीं मिलती है कि कचरा कलेक्टर भाग जाएगा। यह सिर्फ एक अनुरोध है, जिसे सम्मानित किया जा सकता है या नहीं। –
'gc()' को कॉल करने के बाद से एक भयानक अभ्यास है, वास्तव में एक सिस्टम प्रॉपर्टी है जिसे कॉल को अनदेखा करने के लिए सेट किया जा सकता है। – erickson
जीसी() के साथ आप केवल जेआरई से कहते हैं कि इसे कचरा कलेक्टर कहला जाना चाहिए। कभी-कभी यह सुझाव उपयोगी हो सकता है लेकिन ज्यादातर मामलों में बस सभी संदर्भों को शून्य पर सेट करना सही तरीका है।
ज्यादातर मामलों में संदर्भों को केवल दायरे से बाहर निकलने का सही तरीका है। – EJP
जावा में कचरा संग्रह स्पष्ट रूप से आमंत्रित करना आवश्यक नहीं है। यह वर्चुअल मशीन द्वारा स्वचालित रूप से किया जाता है।
पुस्तक हेड फर्स्ट जावा का कहना है कि प्रत्येक चर (उदाहरण या स्थानीय चर) के पास गुंजाइश है, जब गुंजाइश गुम हो जाती है तो ऑब्जेक्ट्स के बारे में बात करते समय वेरिएबल मौजूद नहीं होता है, यह कहता है कि ऑब्जेक्ट कचरे के लिए योग्य है कलेक्टर जब उसका अंतिम लाइव संदर्भ गायब हो जाता है।
यह सही है लेकिन वह पुस्तक एक मानक संदर्भ नहीं है। आपको जेएलएस या जेवीएम विशिष्टता का हवाला देना चाहिए। – EJP
System.gc() पर कॉल न करें। कचरा कलेक्टर चलाने से अनावश्यक रूप से आपके कार्यक्रम के प्रदर्शन को बर्बाद करने का एक शानदार तरीका है। JVM जब कचरा इकट्ठा करेगा कचरा इकट्ठा करेगा।
जावा प्लेटफार्म का सबसे बड़ा लाभ सफल स्वचालित कचरा संग्रह है। इसका इस्तेमाल करें।
सॉफ्ट & कमजोर संदर्भ डेटा पर पकड़ने का एक शानदार तरीका है जिसे आप स्मृति में रखना चाहते हैं लेकिन मेमोरी तंग होने के बिना कर सकते हैं।
सामान्य संदर्भ मजबूत हैं, यानी कोई वस्तु अंतिम रूप से प्राप्त नहीं होती है या कचरा एकत्र नहीं होता है जबकि कोई इसका मजबूत संदर्भ रखता है। यदि आप किसी ऑब्जेक्ट में सॉफ़्ट रेफरेंस रखते हैं, तो ऑब्जेक्ट स्वचालित रूप से फ्लैश होने पर आउटऑफ मेमरी स्थिति तक स्मृति में रहेगा। एक वीक रेफरेंस किसी भी समय फ्लश होने की संभावना है लेकिन यह उन अवसरों के लिए उपयोगी हो सकता है जहां ऑब्जेक्ट धारण करना कुछ डिस्क ओवरहेड बचाता है।
इन विशेषताओं के कारण संदर्भ डेटा को फ़्लश करने के बारे में चिंता किए बिना संदर्भ कैशिंग के लिए बहुत अच्छे हैं, अगर स्मृति तंग हो रही है। एक संदर्भ बनाने के लिए
सबसे आसान तरीका है इस तरह है:
Reference<MyClass> r = new SoftReference<MyClass>(new MyClass())
अब आप संदर्भ चारों ओर गुजरती हैं। आप वस्तु प्राप्त करने के लिए इच्छा जब आप Reference.get
MyClass myClass = r.get();
if (myClass != null) {
// do something
}
else {
// Oh dear class isn't there, go to plan b
}
जब तक MyClass बूलियन तक फैला नहीं जाता है, यह वास्तव में मान्य नोटेशन नहीं है :) –
हाँ, मैंने एक शून्य जांच को याद किया, – locka
System.gc (फोन()) पूर्ण संग्रह है, जो विशेष रूप से बुरा है अगर आप ठहराव बार के बारे में परवाह है और समवर्ती या G1 कलेक्टरों उपयोग कर रहे हैं शुरू हो जाएगा।
जब तक आप एक विशिष्ट कारण को अलग नहीं करते हैं कि आपको विभिन्न व्यवहार की आवश्यकता है, तो आपको कचरा संग्रह के साथ नहीं खेलना चाहिए ... आप किसी भी लाभ को देखने से अधिक प्रदर्शन को नुकसान पहुंचाएंगे।
अपडेट करेगा, यह जवाडोक में यह नहीं कहता है। अगर पूर्ण संग्रह शुरू करने के बारे में कहीं भी कोई कथन है तो मैंने इसे 20 वर्षों में कभी नहीं देखा है। 'System.gc()' कुछ भी या कुछ भी नहीं कर सकता है। – EJP
केवल बहुत ही विशिष्ट परिस्थितियों में और कठोर प्रोफाइलिंग द्वारा साबित होने के बाद, gc() स्पष्ट रूप से आमंत्रित करना एक अच्छा विचार होगा। इसे कभी भी कार्यात्मक अंतर नहीं करना चाहिए, लेकिन को बहुत निश्चित परिदृश्यों के तहत प्रदर्शन लाभ माना जा सकता है।
उदाहरण के लिए, कहें कि आप जावा के साथ एक वीडियो गेम बना रहे थे और आप कुछ ही मिनटों के बीच ब्रेक में आते हैं। यह कचरा कलेक्टर को स्पष्ट रूप से उजागर करने के लिए एक अच्छी जगह साबित हो सकता है यदि यह खेल रहा है (जो गेमप्ले के लिए विघटनकारी हो सकता है) के दौरान जीसी चक्र होने का मौका कम हो जाता है।
संक्षेप में, यह उन समयों के लिए आरक्षित होना चाहिए जहां आप रनटाइम से बेहतर जानते हैं, जब जीसी सबसे वांछनीय है, और फिर, इसका उपयोग केवल इसके समावेश को उचित बनाने के लिए कठोर प्रोफाइलिंग के बाद किया जाना चाहिए।
http://stackoverflow.com/questions/3499937/for-java-as-free-in-c-or-delete-in-c/ – JBirch
पर एक नज़र डालें, इसी तरह के प्रश्न: http://stackoverflow.com/प्रश्न/66540/सिस्टम-जीसी-इन-जावा, http://stackoverflow.com/questions/2414105/why-is-it-a-bad-practice-to-call-system-gc, http: // stackoverflow .com/प्रश्न/2373792/संबंधित-कचरा-संग्रह-क्यों-हम-ज़रूरत-टू-कॉल-सिस्टम-जीसी, http://stackoverflow.com/questions/1083935/what-exactly-takes-place-behind -the-scenes-when-you-call-system-gc, आदि, इत्यादि। –
मैंने कभी भी 'system.gc() ' –