💳 🌓 😈 ओवरहेड कचरा संग्रह को कम करने के लिए 5 "हैक" 🌒 👨‍⚖️ 👩🏾‍🚀

इस पोस्ट में, हम कोड दक्षता में सुधार करने के पांच तरीकों पर ध्यान देंगे, जो कचरा संग्रहकर्ता को कम समय आवंटित करने और मेमोरी को खाली करने में मदद करते हैं। एक लंबी कचरा संग्रहण प्रक्रिया से "दुनिया को रोकें" नामक घटना हो सकती है।

सामान्य जानकारी

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

जीसी इस मामले में तथाकथित "युवा पीढ़ी" का उपयोग करता है - ढेर का एक खंड जहां नई वस्तुओं को रखा जाता है। प्रत्येक ऑब्जेक्ट में "आयु" ("आयु" का एक क्षेत्र होता है, जो ऑब्जेक्ट के हेडर में स्थित होता है), जो निर्धारित करता है कि वह कितने कचरा संग्रह से बच गया। जैसे ही एक निश्चित आयु पूरी हो जाती है, वस्तु को "पुराने" पीढ़ी नामक ढेर के दूसरे क्षेत्र में कॉपी किया जाता है।

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

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

1. अंतर्निहित स्ट्रिंग्स का उपयोग करने से बचें

पंक्तियाँ लगभग किसी भी डेटा संरचना का एक अभिन्न अंग हैं। अन्य आदिम प्रकारों की तुलना में अधिक संसाधन गहन होने के कारण, उनका मेमोरी खपत पर अधिक प्रभाव पड़ता है।

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

यहाँ एक उदाहरण है:

a = a + b; // a  b -

और यहाँ संकलक बैकस्टेज द्वारा उत्पन्न वास्तविक कोड है:

 StringBuilder temp = new StringBuilder(a). temp.append(b); a = temp.toString(); //    . //  “a”   .

वास्तविकता इससे भी बदतर है ।
निम्नलिखित उदाहरण पर विचार करें:

 String result = foo() + arg; result += boo(); System.out.println(“result = “ + result);

यहां हमारे पास 3 स्ट्रिंगरबिल्डर्स हैं, जो कि प्रत्येक "+" ऑपरेशन के लिए एक का चयन करते हैं और दो अतिरिक्त लाइनें - एक, दूसरे असाइनमेंट के परिणामस्वरूप, दूसरे को प्रिंटलाइन विधि से पारित किया जाता है। परिणामस्वरूप, हमें तुच्छ कोड में 5 अतिरिक्त ऑब्जेक्ट प्राप्त हुए।

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

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

 StringBuilder value = new StringBuilder(“result = “); value.append(foo()).append(arg).append(boo()); System.out.println(value);

यह ध्यान में रखते हुए कि ऐसे मामलों में, स्ट्रिंग्स और स्ट्रिंगबुइल्डर्स को अंतर्निहित रूप से आवंटित किया जाता है, आप अक्सर निष्पादित कोड में छोटे मेमोरी आवंटन की संख्या को काफी कम कर सकते हैं।

2. सूचियों की प्रारंभिक क्षमता निर्धारित करें

डायनेमिक रूप से विस्तार योग्य संग्रह, जैसे कि ArrayList, चर-लंबाई डेटा रखने के लिए कुछ बुनियादी संरचनाएं हैं। ArrayList और अन्य संग्रह, उदाहरण के लिए, HashMap, TreeMap अंतर्निहित सरणी ऑब्जेक्ट [] का उपयोग करके कार्यान्वित किए जाते हैं। तार की तरह (जो वर्ण सरणियों के लिए ऐड-ऑन हैं), सरणी का आकार अपरिवर्तित है। स्पष्ट सवाल यह है कि, संग्रह के आइटम को कैसे जोड़ते हैं जब अंतर्निहित सरणी का आकार अपरिवर्तनीय होता है? उत्तर कोई कम स्पष्ट नहीं है - बड़े सरणियों को आवंटित करके।

निम्नलिखित उदाहरण पर विचार करें:

 List<Item> items = new ArrayList<Item>(); for (int i = 0; i < len; i++) { Item item = readNextItem(); items.add(item); }

लेन चर का मान लूप के अंत से पहले संसाधित किए गए तत्वों की अधिकतम संख्या निर्धारित करता है। फिर भी, यह मान ArrayList निर्माता के लिए अज्ञात है, जो एक डिफ़ॉल्ट आकार के साथ एक सरणी आवंटित करने के लिए मजबूर है। जब भी आंतरिक सरणी की क्षमता पार हो जाती है, तो इसे पर्याप्त लंबाई के एक नए के साथ बदल दिया जाता है, जिसके परिणामस्वरूप पिछले एक कचरा में बदल जाता है।

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

समाधान: जहां भी संभव हो प्रारंभिक क्षमता का संकेत दें:

 List<MyObject> items = new ArrayList<MyObject>(len);

यह सुनिश्चित करता है कि निष्पादन के दौरान होने वाली आंतरिक सरणियों का कोई अनावश्यक स्मृति आवंटन नहीं है। यदि सटीक आकार ज्ञात नहीं है, तो यह अप्रत्याशित अतिप्रवाह के मामले में ऊपर से कुछ प्रतिशत जोड़कर, लगभग या अनुमानित औसत मूल्य को निर्दिष्ट करने के लायक है।

3. आदिम प्रकार के कुशल संग्रह का उपयोग करें

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

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

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

मानक Integer.valueOf () विधि -128 और 127 के बीच कैश का मान रखती है, लेकिन इस सीमा के बाहर की कोई भी संख्या प्रत्येक कुंजी-मान जोड़ी के लिए एक अलग ऑब्जेक्ट आवंटित करेगी। यह प्रत्येक सहयोगी सरणी में एक ट्रिपल जीसी ओवरहेड के परिणामस्वरूप होता है। सी ++ से आने वालों के लिए, यह समाचार हो सकता है - एसटीएल में टेम्पलेट्स के लिए धन्यवाद, यह समस्या काफी प्रभावी रूप से हल हो गई है।

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

4. मेमोरी में बफ़र्स के बजाय धाराओं का उपयोग करें

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

आमतौर पर, डेटा को ByteArrayInputStream, ByteBuffe का उपयोग करके मेमोरी में पढ़ा जाता है, फिर परिणाम डीरिएरलाइज़ेशन को पारित किया जाता है।

यह एक बुरा दृष्टिकोण हो सकता है, जैसा कि आपको पहले डेटा को आवंटित करना होगा, और फिर डेटा के लिए स्थान खाली करना होगा, लेकिन केवल उनसे वस्तुओं के निर्माण के अंत में। लेकिन एक नियम के रूप में, डेटा का आकार ज्ञात नहीं है, जो नेतृत्व करेगा, जैसा कि आपने अनुमान लगाया होगा, बाइट के लिए एक निरंतर मेमोरी आवंटन [] सरणियों के लिए, जो बफर क्षमता से अधिक होने पर बढ़ेगा।

समाधान अत्यंत सरल है। कई पुस्तकालयों, जैसे कि देशी जावा सीरियलाइज़र, प्रोटोकॉल बफर, आदि। नेटवर्क स्ट्रीम से डेटा का उपयोग करके deserialized ऑब्जेक्ट्स बनाने में सक्षम, अर्थात। मेमोरी और आंतरिक सरणियों में डेटा भंडारण की आवश्यकता नहीं है। जब भी संभव हो इस दृष्टिकोण का उपयोग करें - जीसी धन्यवाद कहेंगे।

5. इम्यूनिटी हमेशा अच्छी नहीं होती है

प्रतिरक्षा एक उत्कृष्ट चीज है, लेकिन उच्च प्रदर्शन के मामले में कंप्यूटिंग एक गंभीर खामी हो सकती है। पेरोल ऑब्जेक्ट के तरीकों के बीच स्थानांतरण परिदृश्य पर विचार करें।

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

इस मामले में समाधान विधियों से नए संग्रह को वापस करने से बचने के लिए है, इसके बजाय परिणामी संग्रह के ऑब्जेक्ट को विधि के पैरामीटर के रूप में पास करें।

उदाहरण 1. (अप्रभावी)

 List<Item> items = new ArrayList<Item>(); for (FileData fileData : fileDatas) { //       // , , -   items.addAll(readFileItem(fileData)); }

उदाहरण 2

 List<Item> items = new ArrayList<Item>( fileDatas.size() * avgFileDataSize * 1.5); for (FileData fileData : fileDatas) { readFileItem(fileData, items); //    }

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

और क्या पढ़ना है?

1) स्ट्रिंग इंटर्निंग के बारे में

2) प्रभावी रैपर के बारे में

3) ट्रोव के बारे में

4) हैबे पर ट्रोव के बारे में

ओवरहेड कचरा संग्रह को कम करने के लिए 5 "हैक"