जावा संग्रह का उपयोग करते समय मेमोरी ओवररन को कैसे रोकें

सभी को नमस्कार!

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

लेकिन यह मुझे हमारे बारे में है, ओटसोवस्की के बारे में, मुझे क्षमा करें। हमेशा की तरह, हम दिलचस्प विषयों का अध्ययन करना जारी रखते हैं, हालांकि वे हमारे कार्यक्रम में संबोधित नहीं किए जाते हैं, लेकिन जिन पर हमारे साथ चर्चा की जाती है, इसलिए हमने हमारे शिक्षकों द्वारा पूछे गए प्रश्नों में से एक पर सबसे दिलचस्प लेख का अनुवाद तैयार किया।

चलो चलते हैं!



जेडीके में संग्रह सूची और नक्शे के मानक पुस्तकालय कार्यान्वयन हैं। यदि आप एक विशिष्ट बड़े जावा एप्लिकेशन के स्नैपशॉट को देखते हैं, तो आपको java.util.ArrayList , java.util.HashMap , आदि के हजारों या लाखों उदाहरण दिखाई देंगे। संग्रह डेटा के भंडारण और हेरफेर के लिए अपरिहार्य हैं। लेकिन क्या आपने कभी इस बारे में सोचा है कि क्या आपके आवेदन के सभी संग्रह मेमोरी का इष्टतम उपयोग करते हैं? दूसरे शब्दों में, यदि आपका एप्लिकेशन शर्मनाक OutOfMemoryError साथ क्रैश हो जाता है या कचरा संग्रहकर्ता में लंबे समय तक रुक जाता है, तो क्या आपने कभी लीक के लिए उपयोग किए गए संग्रहों की जाँच की है।

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

उदाहरण के लिए, सबसे सरल और सबसे लोकप्रिय संग्रहों में से एक पर विचार करें - java.util.ArrayList वर्ग। आंतरिक रूप से, प्रत्येक ArrayList Object[] elementData की एक सरणी के साथ संचालित होता है। यह वह जगह है जहाँ सूची आइटम संग्रहीत किए जाते हैं। आइए देखें कि इस सरणी को कैसे संसाधित किया जाता है।

जब आप डिफॉल्ट कंस्ट्रक्टर के साथ एक ArrayList बनाते हैं, elementData , new ArrayList() कॉल करते हैं, elementData शून्य आकार के जेनेरिक सरणी को इंगित करता है ( elementData को null करने के लिए भी सेट किया जा सकता है, लेकिन एरे कुछ मामूली लाभ प्रदान करता है)। जब आप सूची में पहला तत्व जोड़ते हैं, तो elementData एक वास्तविक अनूठा सरणी elementData , और प्रदान की गई वस्तु को इसमें डाला जाता है। हर बार सरणी का आकार बदलने से बचने के लिए, जब एक नया तत्व जोड़ते हैं, तो इसे 10 ("डिफ़ॉल्ट क्षमता") के बराबर लंबाई के साथ बनाया जाता है। तो यह पता चला है: यदि आप अब इस ArrayList तत्वों को नहीं जोड़ते हैं, तो elementData सरणी में 10 में से 9 स्लॉट खाली रहेंगे। और भले ही आप सूची को साफ कर दें, लेकिन आंतरिक सरणी का आकार कम नहीं होगा। निम्नलिखित इस जीवन चक्र का एक चित्र है:



यहाँ कितनी स्मृति बर्बाद हुई है? पूर्ण शब्दों में, इसकी गणना (ऑब्जेक्ट पॉइंटर के आकार) के रूप में की जाती है। यदि आप JVM HotSpot (जो Oracle JDK के साथ आता है) का उपयोग करते हैं, तो पॉइंटर का आकार अधिकतम हीप आकार पर निर्भर करेगा (अधिक विवरण के लिए https://blog.codecentric.de/en/2014/02/35gb-heap-less- देखें 32 जीबी-जावा-जेवीएम-मेमोरी-विषमताएं / )। आमतौर पर, यदि आप -Xmx 32 गीगाबाइट से कम निर्दिष्ट करते हैं, तो पॉइंटर का आकार 4 बाइट्स होगा; बड़े ढेर के लिए - 8 बाइट्स। इस प्रकार, एक ArrayList , डिफ़ॉल्ट कंस्ट्रक्टर द्वारा आरंभिक, केवल एक तत्व के अतिरिक्त, या तो 36 या 72 बाइट्स से बर्बाद होता है।

वास्तव में, एक खाली ArrayList मेमोरी ArrayList भी बर्बाद कर रहा है क्योंकि यह किसी भी कार्यभार को वहन नहीं करता है, लेकिन ArrayList का आकार स्वयं शून्य नहीं है और जितना आप सोचते हैं, उससे बड़ा नहीं है। ऐसा इसलिए है, क्योंकि एक ओर, हॉटस्पॉट JVM द्वारा प्रबंधित प्रत्येक ऑब्जेक्ट में एक 12- या 16-बाइट हैडर होता है, जिसका उपयोग आंतरिक उद्देश्यों के लिए JVM द्वारा किया जाता है। इसके अलावा, संग्रह की अधिकांश वस्तुओं में एक size फ़ील्ड, एक आंतरिक सरणी या अन्य "वर्कलोड मीडिया" ऑब्जेक्ट के लिए एक modCount , सामग्री में परिवर्तन को ट्रैक करने के लिए एक modCount फ़ील्ड, आदि हैं। इस प्रकार, यहां तक ​​कि एक खाली संग्रह का प्रतिनिधित्व करने वाली सबसे छोटी संभव वस्तु को कम से कम की आवश्यकता होगी। स्मृति के 32 बाइट्स। कुछ, जैसे ConcurrentHashMap , कुछ अधिक।

एक अन्य सामान्य संग्रह पर विचार करें - java.util.HashMap वर्ग। इसका जीवन चक्र ArrayList जीवन चक्र के समान है:



जैसा कि आप देख सकते हैं, केवल एक ही-वैल्यू पेयर वाली एक HashMap सरणी की 15 आंतरिक कोशिकाओं को खर्च करती है, जो 60 या 120 बाइट्स से मेल खाती है। ये संख्या छोटी है, लेकिन आपके आवेदन में सभी संग्रह के लिए स्मृति हानि की सीमा महत्वपूर्ण है। और यह पता चला है कि कुछ एप्लिकेशन इस तरह से बहुत अधिक मेमोरी खर्च कर सकते हैं। उदाहरण के लिए, कुछ लोकप्रिय ओपन-सोर्स Hadoop के कुछ घटक, जिनका लेखक ने विश्लेषण किया है, कुछ मामलों में उनके ढेर का लगभग 20 प्रतिशत खो देते हैं! कम अनुभवी इंजीनियरों द्वारा विकसित उत्पादों के लिए जो नियमित प्रदर्शन की समीक्षा से नहीं गुजरते हैं, स्मृति हानि और भी अधिक हो सकती है। ऐसे पर्याप्त मामले हैं जहां, उदाहरण के लिए, एक विशाल पेड़ में 90% नोड्स में केवल एक या दो वंशज (या कुछ भी नहीं) होते हैं, और अन्य परिस्थितियां जहां ढेर 0-, 1- या 2-तत्व संग्रह के साथ भरा होता है।

यदि आपको अपने आवेदन में अप्रयुक्त या कम उपयोग किए गए संग्रह मिलते हैं, तो उन्हें कैसे ठीक करें? नीचे कुछ सामान्य व्यंजनों के बारे में बताया गया है। यहां, यह माना जाता है कि हमारा समस्याग्रस्त संग्रह एक ArrayList है जिसे डेटा फ़ील्ड Foo.list द्वारा संदर्भित किया गया है।

यदि सूची के अधिकांश उदाहरणों का उपयोग कभी नहीं किया जाता है, तो इसे आलस्यपूर्वक आरंभ करने का प्रयास करें। तो पहले जैसा कोड दिखता था ...

 void addToList(Object x) { list.add(x); } 

... जैसा कुछ बनना चाहिए

 void addToList(Object x) { getOrCreateList().add(x); } private list getOrCreateList() { //   ,         if (list == null) list = new ArrayList(); return list; } 

ध्यान रखें कि कभी-कभी आपको संभावित प्रतियोगिता को संबोधित करने के लिए अतिरिक्त उपाय करने की आवश्यकता होगी। उदाहरण के लिए, यदि आप ConcurrentHashMap समर्थन करते हैं, जिसे एक साथ कई थ्रेड द्वारा अद्यतन किया जा सकता है, तो इसे प्रारंभ करने वाला कोड दो थ्रेड को इस मानचित्र की दो प्रतियों को यादृच्छिक रूप से बनाने की अनुमति नहीं देता है:

 private Map getOrCreateMap() { if (map == null) { //,       synchronized (this) { if (map == null) map = new ConcurrentHashMap(); } } return map; } 

यदि आपकी सूची या मानचित्र के अधिकांश उदाहरणों में केवल कुछ आइटम हैं, तो उन्हें अधिक उपयुक्त प्रारंभिक क्षमता के साथ प्रारंभ करने का प्रयास करें, उदाहरण के लिए।

 list = new ArrayList(4); //       4 

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

 // ***   *** private List<Foo> list = new ArrayList<>(); void addToList(Foo foo) { list.add(foo); } // ***   *** //   ,    null.      , //      .       //   ArrayList. private Object listOrSingleEl; void addToList(Foo foo) { if (listOrSingleEl == null) { //   listOrSingleEl = foo; } else if (listOrSingleEl instanceof Foo) { //  Foo firstEl = (Foo) listOrSingleEl; ArrayList<Foo> list = new ArrayList<>(); listOrSingleEl = list; list.add(firstEl); list.add(foo); } else { //      ((ArrayList<Foo>) listOrSingleEl).add(foo); } } 

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

आप शायद पहले से ही आश्चर्यचकित थे: मुझे कैसे पता चलेगा कि मेरे आवेदन में कौन से संग्रह मेमोरी का उपयोग करते हैं और कितना?

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

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

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

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

JXRay बाइट्स में ओवरहेड की गणना करता है (यदि आप किसी विशेष समस्या से छुटकारा पा लेते हैं तो आप कितनी मेमोरी बचाएंगे) और उपयोग किए गए ढेर के प्रतिशत के रूप में। यह एक ही वर्ग के संग्रह को जोड़ती है जिसमें समान समस्या है ...



... और फिर समसामयिक संग्रहों को एक ही लिंक श्रृंखला के माध्यम से कचरा कलेक्टर के कुछ रूट से एक्सेस किया जा सकता है, जैसा कि नीचे दिए गए उदाहरण में है



यह जानते हुए कि कौन सी लिंक चेन और / या व्यक्तिगत डेटा फ़ील्ड (उदाहरण के लिए, INodeDirectory.children ऊपर) ऐसे संग्रह दर्शाते हैं, जो उनकी अधिकांश मेमोरी को खर्च करते हैं, आपको समस्या के लिए ज़िम्मेदार कोड की त्वरित और सटीक पहचान करने की अनुमति देता है, और फिर आवश्यक परिवर्तन करता है।

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

अंत

हम, हमेशा की तरह, आपकी राय और सवालों में रुचि रखते हैं, जिसे आप यहां छोड़ सकते हैं या एक खुले सबक से छोड़ सकते हैं और हमारे शिक्षकों से पूछ सकते हैं।