जावा में मेमोरी कैसे खाली करें?

146

क्या जावा में मुफ्त मेमोरी का एक तरीका है, सी के free()फ़ंक्शन के समान है ? या जीसी पर एकमात्र विकल्प को शून्य और निर्भर करने के लिए ऑब्जेक्ट सेट कर रहा है?

java garbage-collection

— फेलिक्स
स्रोत

151

ठीक है ... चलो एक बात सीधे करते हैं। सिर्फ इसलिए कि आपको लगता है कि कुछ बुरा अभ्यास है और कुछ करने के लिए प्रोत्साहित करने के लिए नहीं, यह एक वोट के लायक नहीं बनाता है। यह एक स्पष्ट और वैध प्रश्न है, यह पूछने पर कि क्या कचरा संग्रहण पर भरोसा करने के साथ जावा में मेमोरी जारी करने का कोई तरीका है। हालांकि यह हतोत्साहित किया जा सकता है और आम तौर पर उपयोगी या एक अच्छा विचार नहीं है, आप यह नहीं जान सकते हैं कि ऐसे परिदृश्य नहीं हैं जहां फेलिक्स को जानने के साथ इसकी आवश्यकता हो सकती है। हो सकता है कि फेलिक्स इसका इस्तेमाल करने की योजना भी न बना रहा हो। वह यह जानना चाहता है कि क्या यह संभव है। यह किसी भी तरह से एक वोट के लायक नहीं है।

— डैनियल बिंगहैम

7

स्पष्टीकरण के लिए, जिसका उद्देश्य यह है कि इसे नीचे वोट दिया जाए - पिछले टिप्पणियों को जरूरी नहीं।

— डैनियल बिंगहैम

96

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

यह स्मृति प्रबंधन व्हाइटपेपर (PDF) यह बताने में मदद कर सकता है कि क्या हो रहा है।

आप यह System.gc()सुझाव देने के लिए भी कॉल कर सकते हैं कि कचरा संग्रहकर्ता तुरंत चलता है। हालाँकि, जावा रनटाइम अंतिम निर्णय लेता है, न कि आपका कोड।

जावा प्रलेखन के अनुसार ,

जीसी विधि को कॉल करने से पता चलता है कि जावा वर्चुअल मशीन खर्च की गई वस्तुओं को पुन: उपयोग करने के लिए अप्रयुक्त वस्तुओं को पुन: उपयोग करने की दिशा में खर्च करती है, जो कि वे वर्तमान में त्वरित पुन: उपयोग के लिए उपलब्ध हैं। जब विधि कॉल से नियंत्रण लौटाता है, तो जावा वर्चुअल मशीन ने सभी छोड़ी गई वस्तुओं से अंतरिक्ष को पुनः प्राप्त करने का एक अच्छा प्रयास किया है।

— डैनियल प्राइडेन
स्रोत

5

यह गारबेज कलेक्टर को चलाने के लिए बाध्य करता है। हालांकि यह मुक्त स्मृति के लिए मजबूर नहीं करता है ...

— पाब्लो सांता क्रूज़

13

नहीं पाब्लो, यह जीसी को चलने के लिए मजबूर नहीं करता है।

— जेसपर

1

मुझे एक बहुत विश्वसनीय व्यक्ति द्वारा बताया गया है कि सभी हॉटस्पॉट वीएम के कचरा संग्रहकर्ता System.gc()पूरी तरह से अनदेखा करते हैं ।

— एस्को जूल

1

WinXp जावा एसई जीसी पर हर System.gc () या लगभग हर पर चलता है लेकिन एपीआई डॉक्टर इसकी गारंटी नहीं देता है।

— तेओदोजान

2

@ पाब्लो सांता क्रूज़ का क्या मतलब है कि यह मुफ्त मेमोरी नहीं देता है? मैंने अभी-अभी अपने कार्यक्रम पर इसका परीक्षण किया था जिसमें लगता था कि रिसाव हुआ था और RAM का उपयोग स्थिर लग रहा था? और डैनियल ने कहा कि यह केवल यह सुझाव देता है कि कैसे राम के प्रतिशत का उपयोग हमेशा हर बार होता है जब मैंने विधि को बुलाया। आप लोग मुझे भ्रमित कर रहे हैं।

65

ऐसा प्रतीत नहीं होता है कि किसी ने स्पष्ट रूप से ऑब्जेक्ट रेफ़रेंस का उल्लेख किया है null, जो कि आप जिस "स्मृति" पर विचार करना चाहते हैं उसे "मुक्त" करने की एक वैध तकनीक है।

उदाहरण के लिए, मान लें कि आपने List<String>एक विधि की शुरुआत में घोषणा की थी जो आकार में बहुत बड़ी हो गई थी, लेकिन केवल विधि के माध्यम से आधे रास्ते तक आवश्यक थी। आप इस बिंदु पर सूची संदर्भ सेट कर सकते हैं nullकि विधि को पूरा करने से पहले कचरा कलेक्टर को संभावित रूप से इस वस्तु को पुनः प्राप्त करने की अनुमति दें (और संदर्भ वैसे भी दायरे से बाहर हो जाता है)।

ध्यान दें कि मैं शायद ही कभी इस तकनीक का वास्तविकता में उपयोग करता हूं लेकिन यह बहुत बड़े डेटा संरचनाओं से निपटने पर विचार करने योग्य है।

— अदाम्सकी
स्रोत

8

यदि आप वास्तव में किसी ऐसी वस्तु पर काम कर रहे हैं जो केवल एक विधि के हिस्से के लिए उपयोग की जाती है जो मैं या तो सुझाव देता हूं; आपकी विधि बहुत अधिक संकलित है, पहले और बाद के हिस्सों में विधि को तोड़ें, या कोड के पहले आधे भाग के लिए एक ब्लॉक का उपयोग करें (बाद में परीक्षण स्क्रिप्ट के लिए अधिक उपयोगी है)

— पीटर लॉरी

5

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

— हॉट लिप्स

22

System.gc();

कूड़ा बीनने वाला चलाता है।

जीसी विधि को कॉल करने से पता चलता है कि जावा वर्चुअल मशीन व्यय की गई पुन: उपयोग के लिए उपलब्ध वस्तुओं को पुन: उपयोग करने के लिए अप्रयुक्त वस्तुओं को पुन: उपयोग करने की दिशा में प्रयास करती है। जब विधि कॉल से नियंत्रण लौटाता है, तो जावा वर्चुअल मशीन ने सभी छोड़ी गई वस्तुओं से अंतरिक्ष को पुनः प्राप्त करने का एक अच्छा प्रयास किया है।

सिफारिश नहीं की गई।

संपादित करें: मैंने 2009 में मूल प्रतिक्रिया लिखी थी। अब यह 2015 है।

कचरा संग्रहकर्ताओं ने जावा के आसपास के ~ 20 वर्षों में लगातार बेहतर प्रदर्शन किया है। इस बिंदु पर, यदि आप मैन्युअल रूप से कचरा संग्रहकर्ता को बुला रहे हैं, तो आप अन्य दृष्टिकोणों पर विचार करना चाह सकते हैं:

यदि आप सीमित संख्या में मशीनों पर GC को मजबूर कर रहे हैं, तो यह मौजूदा मशीन से एक लोड बैलेंसर पॉइंट से दूर होने के लायक हो सकता है, इसके लिए प्रतीक्षा की जा रही है कि वह कनेक्टेड क्लाइंट्स की सेवा समाप्त कर ले, कनेक्शनों को लटकाने के लिए कुछ समय के बाद, और उसके बाद बस कड़ी मेहनत करें। जेवीएम प्रदान करें। यह एक भयानक समाधान है, लेकिन यदि आप System.gc () को देख रहे हैं, तो मजबूर-पुनरारंभ एक संभव स्टॉपगैप हो सकता है।
एक अलग कचरा कलेक्टर का उपयोग करने पर विचार करें। उदाहरण के लिए, (पिछले छह वर्षों में नया) जी 1 कलेक्टर कम ठहराव वाला मॉडल है; यह समग्र रूप से अधिक CPU का उपयोग करता है, लेकिन निष्पादन पर हार्ड-स्टॉप को कभी भी मजबूर नहीं करना सबसे अच्छा है। चूंकि सर्वर सीपीयू में अब लगभग सभी कोर हैं, यह उपलब्ध होने के लिए वास्तव में अच्छा ट्रेडऑफ है।
अपने झंडे ट्यूनिंग स्मृति उपयोग को देखो। विशेष रूप से जावा के नए संस्करणों में, यदि आपके पास लंबे समय तक चलने वाली कोई वस्तु नहीं है, तो ढेर में न्यूजेन के आकार को उछाल दें। newgen (युवा) वह जगह है जहाँ नई वस्तुओं को आवंटित किया जाता है। एक वेबसर्वर के लिए, एक अनुरोध के लिए बनाई गई सभी चीज़ों को यहां रखा गया है, और यदि यह स्थान बहुत छोटा है, तो जावा अतिरिक्त समय को वस्तुओं को लंबे समय तक याद रखने के लिए अपग्रेड करने में खर्च करेगा, जहां वे मारने के लिए अधिक महंगे हैं। (यदि न्यूजन थोड़ा बहुत छोटा है, तो आप इसके लिए भुगतान करने वाले हैं। उदाहरण के लिए, G1 में:
- XX: G1NewSizePercent (5 में चूक; शायद कोई फर्क नहीं पड़ता।)
- XX: G1MaxNewSizePercent (60 तक चूक; शायद इसे बढ़ाएं।)
कचरा कलेक्टर को यह बताने पर विचार करें कि आप लंबे समय तक रुकने के साथ ठीक नहीं हैं। यह अधिक-लगातार जीसी रन का कारण होगा, जिससे सिस्टम को बाकी बाधाओं को रखने की अनुमति मिल सके। G1 में:
- XX: MaxGCPauseMillis (200 में चूक)

— डीन जे
स्रोत

1

अपने स्वयं के पोस्ट पर टिप्पणी करते हुए, यह अक्सर कुछ भी नहीं करता है, और इसे बार-बार कॉल करने से जेवीएम अस्थिर हो सकता है और व्हाट्सएप नहीं हो सकता है। यह आपके कुत्ते के ऊपर भी चल सकता है; सावधानी के साथ संपर्क करें।

— डीन जे

1

मैं "जीसी कॉलिंग विधि" के "सुझाव" वाले हिस्से पर बहुत जोर देता हूं कि जेवीएम विस्तार का प्रयास करता है "

— मैट बी

2

@ जैस्पर, डीन का उत्तर "सुझाव" देता है। वास्तव में वह विधि के javadocs से सटीक दस्तावेज पोस्ट किया ...

— मैट बी

2

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

— डैनियल प्राइडेन

1

यह भी हम कहने लायक है कि यह क्यों अनुशंसित नहीं है। यदि JVM GC चलाने के लिए "सुझाव" पर ध्यान देता है, तो यह निश्चित रूप से आपके ऐप को धीमी गति से चलाएगा, संभवतः परिमाण के कई आदेशों द्वारा!

— स्टीफन सी

11

* "मैं व्यक्तिगत रूप से भविष्य के उचित विलोपन के लिए प्लेसहोल्डर के रूप में चर को हटाने पर भरोसा करता हूं। उदाहरण के लिए, मैं सरणी के सभी तत्वों को वास्तव में हटाने से पहले एक सरणी के सभी तत्वों को अशक्त करने के लिए समय लेता हूं।"

यह अनावश्यक है। जिस तरह से जावा जीसी काम करता है वह ऐसी वस्तुओं को ढूंढता है जिनका कोई संदर्भ नहीं है, इसलिए यदि मेरे पास ऑब्जेक्ट x (संदर्भ = चर) है जो इसे इंगित करता है, तो जीसी इसे हटा नहीं देगा, क्योंकि एक संदर्भ है उस वस्तु के लिए:

a -> x

यदि आप ऐसा होने की तुलना में शून्य करते हैं:

a -> null
     x

तो अब x के पास इसे इंगित करने वाला संदर्भ नहीं है और इसे हटा दिया जाएगा। जब आप x से भिन्न ऑब्जेक्ट के संदर्भ में सेट करते हैं तो वही बात होती है।

इसलिए यदि आपके पास एक एरे गिरफ्तार है जो ऑब्जेक्ट x, y और z के संदर्भ में है और एक चर है जो एरे के संदर्भ में है जो ऐसा दिखता है:

a -> arr -> x
         -> y
         -> z

यदि आप ऐसा होने की तुलना में शून्य करते हैं:

a -> null
     arr -> x
         -> y
         -> z

इसलिए जीसी को गिरफ्तार किया जाता है क्योंकि इसका कोई संदर्भ नहीं है और इसे हटा दिया जाता है, जो आपको यह संरचना प्रदान करता है:

a -> null
     x
     y
     z

अब GC x, y और z को ढूँढता है और उन्हें हटा देता है। सरणी में प्रत्येक संदर्भ को खींचने से कुछ भी बेहतर नहीं होगा, यह कोड में सीपीयू समय और स्थान का उपयोग करेगा (यह कहा, यह उससे आगे चोट नहीं करेगा। जीसी अभी भी उस तरह से प्रदर्शन करने में सक्षम होगा। )।

— Dakkaron
स्रोत

5

किसी भी प्रोग्राम (जावा या नहीं) से मुक्त मेमोरी चाहने का एक वैध कारण ऑपरेटिंग सिस्टम स्तर पर अन्य प्रोग्रामों को अधिक मेमोरी उपलब्ध कराना है। अगर मेरा जावा एप्लिकेशन 250MB का उपयोग कर रहा है, तो मैं इसे 1MB तक नीचे करना और 249MB अन्य ऐप्स के लिए उपलब्ध कराना चाह सकता हूं।

— Yios
स्रोत

अगर आपको जावा प्रोग्राम में स्पष्ट रूप से 249MB का एक हिस्सा खाली करना है, तो स्मृति प्रबंधन वह पहली चीज नहीं होगी जिस पर मैं काम करना चाहता हूं।

— मार्क डिमिलो

3

लेकिन आपके जावा हीप के अंदर फ्रीजिंग स्टोरेज (सामान्य स्थिति में) स्टोरेज को अन्य एप्स के लिए उपलब्ध नहीं कराता है।

— हॉट लक्स

5

Yiannis Xanthopoulos और Hot Licks द्वारा जवाब और टिप्पणी का विस्तार करने के लिए (क्षमा करें, मैं अभी तक टिप्पणी नहीं कर सकता!), आप इस उदाहरण की तरह वीएम विकल्प सेट कर सकते हैं:

-XX:+UseG1GC -XX:MinHeapFreeRatio=15 -XX:MaxHeapFreeRatio=30

मेरी jdk 7 में यह तब अप्रयुक्त वीएम मेमोरी जारी करेगा यदि 30% से अधिक ढेर जीसी के बाद मुक्त हो जाता है जब वीएम निष्क्रिय होता है। आपको शायद इन मापदंडों को ट्यून करने की आवश्यकता होगी।

जब मैंने इसे नीचे दिए गए लिंक में जोर नहीं दिया, तो ध्यान दें कि कुछ कचरा संग्रहकर्ता इन मापदंडों का पालन नहीं कर सकते हैं और डिफ़ॉल्ट रूप से जावा आपके लिए इनमें से एक चुन सकता है, तो क्या आपके पास एक से अधिक कोर होना चाहिए (इसलिए UseG1GC तर्क ऊपर है )।

वीएम दलीलें

अपडेट: जावा 1.8.0_73 के लिए मैंने जेवीएम को कभी-कभी डिफ़ॉल्ट सेटिंग्स के साथ छोटी मात्रा में जारी किया है। केवल यह करने के लिए प्रकट होता है अगर ~ 70% हीप अप्रयुक्त है, लेकिन यह नहीं पता है कि यदि ओएस भौतिक मेमोरी पर कम था, तो यह अधिक आक्रामक रिलीज़ होगा।

— nsandersen
स्रोत

4

मैंने इस पर प्रयोग किया है।

यह सच है कि System.gc();केवल कचरा कलेक्टर को चलाने का सुझाव है।

लेकिन System.gc();सभी संदर्भों को निर्धारित करने के बाद कॉल करने से nullप्रदर्शन और मेमोरी व्यवसाय में सुधार होगा।

— हेमंत यादव
स्रोत

मुझे लगता है कि आप यह सुनिश्चित करने के लिए नहीं कह सकते हैं कि "कॉलिंग System.gc (), सभी संदर्भों को अशक्त करने के बाद, प्रदर्शन और मेमोरी अधिभोग में सुधार करेगा।" क्योंकि System.gc () की विशाल कम्प्यूटेशनल जटिलता है। और System.gc () और वास्तव में कचरा एकत्र करने के बाद भी, jvm OS या सिस्टम को स्मृति वापस नहीं दे सकता है। JVM भविष्य के संदर्भ के लिए मेमोरी को बरकरार रख सकता है। इस जवाब को देखें ।

— मो। अबू नफ़ी इब्ना ज़ाहिद

3

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

हालाँकि, जैसा कि सुझाव दिया गया है, सिर्फ इसलिए कि आपको सी में मेमोरी को खाली करना है, इसका मतलब यह नहीं है कि ऐसा करना एक अच्छा विचार है।

यदि आपको लगता है कि आपके पास वास्तव में मुफ्त के लिए एक अच्छा उपयोग मामला है (), तो कृपया इसे प्रश्न में शामिल करें ताकि हम देख सकें कि आप क्या करने जा रहे हैं, यह एक बेहतर तरीका है।

— पीटर लॉरी
स्रोत

3

Javacfishbreak.com/faq/faq0012.html से पूरी तरह से

एक कम प्राथमिकता वाला धागा उपयोगकर्ता के लिए स्वचालित रूप से कचरा संग्रहण का ख्याल रखता है। निष्क्रिय समय के दौरान, थ्रेड को बुलाया जा सकता है, और यह जावा में किसी ऑब्जेक्ट को पहले से आवंटित मेमोरी को मुफ्त करना शुरू कर सकता है। लेकिन चिंता मत करो - यह आप पर अपनी वस्तुओं को नष्ट नहीं करेगा!

जब किसी वस्तु का कोई संदर्भ नहीं होता है, तो यह कचरा संग्राहक के लिए उचित खेल बन जाता है। कुछ रूटीन (जैसे सी ++ में मुफ्त) कॉल करने के बजाय, आप बस ऑब्जेक्ट के सभी संदर्भों को शून्य करने के लिए असाइन करते हैं, या संदर्भ के लिए एक नया वर्ग असाइन करते हैं।

उदाहरण :
public static void main(String args[])
{
  // Instantiate a large memory using class
  MyLargeMemoryUsingClass myClass = new MyLargeMemoryUsingClass(8192);

  // Do some work
  for ( .............. )
  {
      // Do some processing on myClass
  }

  // Clear reference to myClass
  myClass = null;

  // Continue processing, safe in the knowledge
  // that the garbage collector will reclaim myClass
}
यदि आपका कोड बड़ी मात्रा में मेमोरी का अनुरोध करने वाला है, तो आप चाहते हैं कि कचरा संग्रहकर्ता पुनः प्राप्त करना शुरू कर सके, बजाय इसके कि इसे कम प्राथमिकता वाले धागे के रूप में करने की अनुमति दी जाए। ऐसा करने के लिए, अपने कोड में निम्नलिखित जोड़ें
System.gc();
कचरा संग्राहक मुक्त स्थान को पुनः प्राप्त करने का प्रयास करेगा, और आपका आवेदन निष्पादित करना जारी रख सकता है, जितना संभव हो उतना मेमोरी पुनः प्राप्त किया जा सकता है (कुछ प्लेटफॉर्म पर स्मृति विखंडन के मुद्दे लागू हो सकते हैं)।

— प्रदर्शित होने वाला नाम
स्रोत

1

मेरे मामले में, चूंकि मेरा जावा कोड निकट भविष्य में अन्य भाषाओं (मुख्य रूप से C ++) में पोर्ट किया जाना है, इसलिए मैं कम से कम स्मृति को ठीक करने के लिए होंठ सेवा का भुगतान करना चाहता हूं ताकि यह बाद में पोर्टिंग प्रक्रिया में मदद करे।

मैं व्यक्तिगत रूप से भविष्य के उचित विलोपन के लिए एक प्लेसहोल्डर के रूप में चर को हटाने पर भरोसा करता हूं। उदाहरण के लिए, मैं किसी सरणी के सभी तत्वों को वास्तव में हटाने से पहले सरणी को हटाने (शून्य करने) के लिए समय लेता हूं।

लेकिन मेरा मामला बहुत खास है, और मुझे पता है कि मैं ऐसा करते समय प्रदर्शन हिट ले रहा हूं।

— Oskuro
स्रोत

1

* "उदाहरण के लिए, मान लें कि आपने एक विधि की शुरुआत में एक सूची घोषित की है जो आकार में बहुत बड़ी हो गई है, लेकिन केवल विधि के माध्यम से आधे रास्ते तक आवश्यक थी। आप इस बिंदु पर सूची के संदर्भ को अशक्त करने के लिए निर्धारित कर सकते हैं। विधि के पूरा होने से पहले कचरा कलेक्टर को संभावित रूप से पुनः प्राप्त करने की अनुमति देने के लिए (और संदर्भ वैसे भी गुंजाइश से बाहर हो जाता है)। " *

यह सही है, लेकिन यह समाधान सामान्य नहीं हो सकता है। Null -will के लिए सूची ऑब्जेक्ट संदर्भ सेट करते समय- कचरा संग्रहण के लिए स्मृति उपलब्ध कराएं, यह केवल प्राथमिक प्रकारों की सूची ऑब्जेक्ट के लिए सही है। यदि सूची ऑब्जेक्ट के बजाय संदर्भ प्रकार समाहित करते हैं, तो सूची ऑब्जेक्ट सेट करना = null संदर्भ-प्रकार के निहित -any- को नहीं करेगा-सूची। इस स्थिति में, सूची ऑब्जेक्ट सेट करना = निहित संदर्भ प्रकारों को अनाथ कर देगा, जिनकी वस्तुएं कचरा संग्रहण के लिए उपलब्ध नहीं होंगी, जब तक कि कचरा संग्रह एल्गोरिदम यह निर्धारित करने के लिए पर्याप्त स्मार्ट नहीं है कि ऑब्जेक्ट अनाथ हो गए हैं।

— Gothri
स्रोत

1

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

— डकारन

1

अल्रिथ जावा स्वचालित कचरा संग्रह प्रदान करता है कभी-कभी आप जानना चाहेंगे कि वस्तु कितनी बड़ी है और यह कितनी शेष है। मुफ्त मेमोरी का उपयोग करके import java.lang;और Runtime r=Runtime.getRuntime(); स्मृति के मूल्यों को प्राप्त करने के mem1=r.freeMemory();लिए मुफ्त मेमोरी कॉल r.gc();विधि और कॉल का उपयोग करें।freeMemory()

— बेंजामिन
स्रोत

1

JAVA से सिफारिश करना है कि वह अशक्त हो जाए

से https://docs.oracle.com/cd/E19159-01/819-3681/abebi/index.html

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

ऑब्जेक्ट संदर्भों को जारी न करके एक एप्लिकेशन मेमोरी लीक को प्रेरित कर सकता है। ऐसा करने से जावा कचरा संग्रहकर्ता को उन वस्तुओं को पुनः प्राप्त करने से रोकता है, और इसके परिणामस्वरूप स्मृति की बढ़ती मात्रा का उपयोग किया जाता है। स्पष्ट रूप से उनके उपयोग के बाद चर के संदर्भों को अशक्त करना कचरा कलेक्टर को स्मृति को पुनः प्राप्त करने की अनुमति देता है।

मेमोरी लीक का पता लगाने का एक तरीका है कि प्रोफाइलिंग टूल को नियोजित किया जाए और प्रत्येक लेनदेन के बाद मेमोरी स्नैपशॉट लें। स्थिर अवस्था में एक रिसाव-मुक्त अनुप्रयोग कचरा संग्रहण के बाद एक स्थिर सक्रिय ढेर मेमोरी दिखाएगा।

— user3869837
स्रोत