🍔 🌲 🖐🏽 पर्मेन मेमोरी लीक विश्लेषण जावा में 💮 ✏️ 🖕

आप किस बारे में बात कर रहे हैं?

जो लोग जावा में वेब विकास में शामिल थे, शायद उन्हें java.lang.OutOfMemoryError: PermGen space

जैसी समस्या का सामना करना पड़ा। यह होता है, एक नियम के रूप में, सर्वर के भीतर वेब एप्लिकेशन को सर्वर को पुनरारंभ किए बिना पुनरारंभ करने के बाद। सर्वर को फिर से शुरू किए बिना वेब एप्लिकेशन को पुनरारंभ करना विकास प्रक्रिया के दौरान आवश्यक हो सकता है ताकि सर्वर को स्वयं शुरू करने के लिए अतिरिक्त समय तक इंतजार न करना पड़े। यदि आपके पास कई वेब एप्लिकेशन तैनात हैं, तो पूरे सर्वर को फिर से शुरू करना एक वेब एप्लिकेशन को पुनरारंभ करने की तुलना में अधिक लंबा हो सकता है। या पूरे सर्वर को बस फिर से शुरू नहीं किया जा सकता है, क्योंकि अन्य वेब एप्लिकेशन का उपयोग किया जाता है। दिमाग में आने वाला पहला समाधान जेवीएम को उपलब्ध परम मेमोरी की अधिकतम मात्रा में वृद्धि करना है (आप इसे -XX:MaxPermSize

साथ कर सकते हैं), लेकिन यह केवल दुर्घटना में देरी करेगा, कुछ पुनरारंभ होने के बाद आपको फिर से OutOfMemoryError

मिलेगा। अच्छा होगा कि आप एक चालू सर्वर पर वेब एप्लिकेशन को पुनः आरंभ और फिर से कर सकें, जितनी बार चाहें। PermGen पर काबू पाने के बारे में, और आगे की चर्चा होगी।

पर्मगेन क्या है?

पर्मगेन - स्थायी पीढ़ी जेवीएम में एक मेमोरी क्षेत्र है जिसे जावा वर्ग विवरण और कुछ अतिरिक्त डेटा स्टोर करने के लिए डिज़ाइन किया गया है। इस प्रकार, जब आप वेब एप्लिकेशन को पुनरारंभ करते हैं, तो सभी कक्षाएं एक नए पर लोड होती हैं और पर्मगेन मेमोरी को भरती हैं। एक वेब एप्लिकेशन में पुस्तकालयों का एक समूह हो सकता है, और वर्ग विवरण दसियों मेगाबाइट ले सकते हैं। जावा में नवाचारों का पालन करने वालों ने सुना हो सकता है कि जावा 8 में PermGen को छोड़ दिया गया था। यहां आप सोच सकते हैं कि अनन्त समस्या को आखिरकार ठीक कर दिया गया था, और अब पर्मगेन मेमोरी की कमी से दुर्घटना नहीं होगी। दुर्भाग्य से यह मामला नहीं है, मोटे तौर पर, PermGen को अब केवल Metaspace कहा जाता है, और आपको अभी भी एक OutOfMemoryError

मिलता है।

बंद करो। लेकिन कूड़ा उठाने वाले का क्या?

हम सभी जानते हैं कि जावा में एक कचरा कलेक्टर है जो सभी अप्रयुक्त वस्तुओं को इकट्ठा करता है। यह PermGen में अप्रयुक्त वर्गों को भी इकट्ठा करना चाहिए, लेकिन केवल अगर यह सही ढंग से कॉन्फ़िगर किया गया है और मेमोरी लीक नहीं हैं।

सेटअप के लिए, कुछ आधिकारिक दस्तावेज हैं, इंटरनेट पर विभिन्न विकल्पों का उपयोग करने के लिए कई युक्तियां हैं, उदाहरण के लिए -XX:+CMSClassUnloadingEnabled

, -XX:+CMSPermGenSweepingEnabled

, -XX:+UseConcMarkSweepGC

। मैंने गहरी खुदाई नहीं की और आधिकारिक दस्तावेज की तलाश की, और परीक्षण और त्रुटि से निर्धारित किया कि जावा 7 और टॉमकैट 7 के लिए जेवीएम विकल्प -XX:+UseConcMarkSweepGC

जोड़ने के लिए यह आवश्यक और पर्याप्त था -XX:+UseConcMarkSweepGC

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

एक पर्मेन मेमोरी लीक क्यों है?

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

ताकि कचरा संग्रहकर्ता वेब एप्लिकेशन के सभी वर्गों को इकट्ठा कर सके, उन्हें इस वेब एप्लिकेशन के बाहर संदर्भित नहीं किया जाना चाहिए। अब याद रखें कि जावा में प्रत्येक ऑब्जेक्ट अपनी कक्षा के लिए एक संदर्भ संग्रहीत करता है, अर्थात। वर्ग ऑब्जेक्ट java.lang.Class

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

रिसाव का एक और कारण एक धागा हो सकता है जिसे वेब एप्लिकेशन से लॉन्च किया गया था और जब वेब एप्लिकेशन बंद हो जाता है तो इसे रोका नहीं जा सकता है। यह एक क्लास लोडर वेब एप्लिकेशन का लिंक भी संग्रहीत करता है।

इसके अलावा एक लोकप्रिय लीक विकल्प ThreadLocal

वैरिएबल है, जिसे एक वेब एप्लिकेशन से एक ऑब्जेक्ट को एक साझा पूल से थ्रेड के लिए सौंपा गया है। इस स्थिति में, स्ट्रीम ऑब्जेक्ट के लिए एक संदर्भ संग्रहीत करता है। साझा पूल से एक धागा नष्ट नहीं किया जा सकता है, इसका मतलब है कि ऑब्जेक्ट को नष्ट नहीं किया जा सकता है, इसलिए सभी वर्गों के साथ पूरे क्लास लोडर को नष्ट नहीं किया जा सकता है।

मानक टॉमकैट उपकरण

सौभाग्य से, पर्मगेन मेमोरी लीक का विश्लेषण करने और उसे रोकने के लिए टॉमकैट में कई उपकरण हैं।

सबसे पहले , मानक टॉमकैट मैनेजर एप्लिकेशन में एक "लीक खोजें" बटन ( विवरण ) है, जो विश्लेषण करेगा कि कौन से वेब एप्लिकेशन पुनरारंभ होने के बाद कचरा छोड़ गए।

लेकिन यह केवल यह दिखाएगा कि किन वेब अनुप्रयोगों में रिसाव हो सकता है, इसके लिए बहुत कम उपयोग है।

दूसरे , JreMemoryLeakPreventionListener

में JreMemoryLeakPreventionListener

- मेमोरी लीक के लिए प्रसिद्ध संभावित विकल्पों के लिए एक समाधान है, यह server.xml

( विवरण ) में कॉन्फ़िगर किया गया है। शायद इस श्रोता के लिए कोई भी विकल्प स्मृति लीक से छुटकारा पाने में मदद करेगा।

और तीसरा, सबसे महत्वपूर्ण बात - जब वेब एप्लिकेशन को रोका जाता है, तो टॉमकैट लॉग को लिखता है कि वास्तव में मेमोरी लीक हो सकती है। उदाहरण के लिए, इस तरह:

SEVERE: The web application [/drp] appears to have started a thread named [AWT-Windows] but has failed to stop it. This is very likely to create a memory leak.

SEVERE: The web application [/drp] created a ThreadLocal with key of type [org.apache.log4j.helpers.ThreadLocalMap] (value [org.apache.log4j.helpers.ThreadLocalMap@7dc1e95f]) and a value of type [java.util.Hashtable] (value [{session=*2CBFB7}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

यह वही है जो हमें लीक विश्लेषण जारी रखने की आवश्यकता है।

और जब से हम गंभीरता से व्यवसाय के लिए नीचे उतरे हैं, हमें यह जानना होगा कि पर्मेन को हमारे साथ साफ किया जा रहा है या नहीं। टॉमकैट मैनेजर एप्लिकेशन, जो मेमोरी उपयोग दिखा सकता है, जिसमें PermGen भी शामिल है, फिर से हमारी मदद करेगा।

एक अन्य विशेषता - अधिकतम PermGen मेमोरी के पूरा होने के बाद ही सफाई होती है, इसलिए आपको अधिकतम उपलब्ध PermGen मेमोरी का एक छोटा सा मान सेट करने की आवश्यकता है (उदाहरण के लिए, जैसे: -XX:MaxPermSize=100M

) ताकि वेब एप्लिकेशन के दो या तीन पुनरारंभ होने के बाद कब्जा की गई मेमोरी 100 तक पहुंच जाए %, और या तो एक सफाई हुई, या एक OutOfMemoryError

गिर गई अगर वहाँ अभी भी लीक थे।

अब आइए देखें कि उदाहरणों का उपयोग करके लीक से कैसे छुटकारा पाया जाए।

निम्न संदेश लें:

SEVERE: The web application [/drp] appears to have started a thread named [AWT-Windows] but has failed to stop it. This is very likely to create a memory leak.

यह हमें बताता है कि वेब एप्लिकेशन शुरू हो गया और AWT-Windows

थ्रेड को बंद नहीं किया, इसलिए, इसका contextClassLoader

वेब एप्लिकेशन का क्लास लोडर निकला, और कचरा संग्रहकर्ता इसे एकत्र नहीं कर सकता। यहां हम थ्रेड के नाम से एक शर्त के साथ ब्रेकपॉइंट का उपयोग करके ट्रैक कर सकते हैं जिन्होंने इस धागे को बनाया है और, स्रोत के माध्यम से खुदाई करते हुए, यह पता करें कि इसे किस संभावनाओं से रोका जा सकता है, उदाहरण के लिए, कुछ ध्वज डालें या कुछ विधि कहें, उदाहरण के लिए Thread#interrupt()

। वेब एप्लिकेशन बंद होने पर इन चरणों को निष्पादित करना होगा।

लेकिन आप यह भी देख सकते हैं कि स्ट्रीम का नाम कुछ व्यवस्थित लगता है ... शायद JreMemoryLeakPreventionListener

, जिसके बारे में हमने ऊपर सीखा, इस स्ट्रीम के साथ कुछ कर सकते हैं? हम दस्तावेज़ीकरण पर जाते हैं और देखते हैं कि वास्तव में श्रोता के पास AWTThreadProtection

पैरामीटर है, जो किसी कारण से डिफ़ॉल्ट रूप से गलत है। हम इसे server.xml में सही तरीके से डालते हैं और सुनिश्चित करते हैं कि टॉमकैट इस तरह के संदेश को वापस नहीं करता है।

इस मामले में, JDK से छवि हेरफेर वर्गों का उपयोग कर सर्वर पर कैप्चा की पीढ़ी के कारण AWT-Windows

स्ट्रीम बनाया गया था।

ठीक है, यहाँ हम टॉमकैट में एक सरल विकल्प के साथ उतर गए, चलो कुछ और जटिल प्रयास करें:

SEVERE: The web application [/drp] created a ThreadLocal with key of type [org.apache.log4j.helpers.ThreadLocalMap] (value [org.apache.log4j.helpers.ThreadLocalMap@7dc1e95f]) and a value of type [java.util.Hashtable] (value [{session=*2CBFB7}]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

यहाँ हम देखते हैं कि किसी ने ThreadLocal

कक्षा में ThreadLocalMap

में एक मान रखा और इसे हटाया नहीं। हम यह देख रहे हैं कि ThreadLocalMap

वर्ग का उपयोग कहां किया जाता है, हम org.apache.log4j.MDC

, और अतिरिक्त जानकारी लॉग करने के लिए यह वर्ग हमारे वेब एप्लिकेशन में पहले से ही सीधे उपयोग किया जाता है। हम देखते हैं कि MDC

वर्ग की put

विधि को कहा जाता है, और remove

विधि को नहीं कहा जाता है। ऐसा लगता है कि सही जगह पर प्रत्येक put

लिए कॉल remove

में मदद करनी चाहिए। हम ठीक करते हैं, जांचते हैं - यह काम करता है!

इस तरह की सभी त्रुटियों को ठीक करने के बाद, यह संभावना है कि आप OutOfMemoryError: PermGen space

से छुटकारा पा लेंगे OutOfMemoryError: PermGen space

, कम से कम मेरे व्यवहार में ऐसा था।

VisualVM विश्लेषण

यदि आप टॉमकैट का उपयोग नहीं कर रहे हैं, या यदि लॉग में टॉमकैट द्वारा इंगित त्रुटियों को ठीक करने में मदद नहीं मिली है, तो आप प्रोफाइलर का उपयोग करके विश्लेषण जारी रख सकते हैं। मैंने JDK के साथ शामिल मुक्त VisualVM प्रोफाइलर को लिया।

सबसे पहले, एक तैनात वेब एप्लिकेशन के साथ सर्वर शुरू करें और इसे फिर से शुरू करें ताकि रिसाव दिखाई दे। VisualVM खोलें, वांछित प्रक्रिया का चयन करें और ड्रॉप-डाउन मेनू में उपयुक्त आइटम का चयन करके एक ढेर डंप करें।

"OQL कंसोल" टैब का चयन करें और निम्नलिखित क्वेरी निष्पादित करें:

select x from org.apache.catalina.loader.WebappClassLoader x

(अन्य सर्वलेट कार्यान्वयन के लिए, वर्ग अलग होगा)।

पहले बंद किए गए वेब एप्लिकेशन से दो उदाहरणों में से एक छोड़ दिया गया था, कचरा कलेक्टर इसे इकट्ठा नहीं कर सका। यह निर्धारित करने के लिए कि कौन सा पुराना है, उनमें से एक पर क्लिक करें और started

फ़ील्ड की तलाश करें। started

की गई पुरानी false

होगी।

"संदर्भ" विंडो में, इस वर्ग लोडर के सभी लिंक दिखाए गए हैं, हमें उसे खोजने की आवश्यकता है जिसके कारण कचरा कलेक्टर इसे इकट्ठा नहीं कर सकता है। ऐसा करने के लिए, इस पर राइट-क्लिक this

और "Show Nearest GC Root" चुनें।

खैर, हमें कुछ ऐसा धागा मिला जहां हमारा पुराना क्लास लोडर है। हम सही माउस बटन के साथ उस पर क्लिक करते हैं और "शो इंस्टेंस" चुनें।

हम वस्तु के क्षेत्रों को देखते हैं और सोचते हैं कि हम क्या पकड़ सकते हैं यह समझने के लिए कि यह किस प्रकार की वस्तु है, किसी भी तरह से इसे बनाने वाला कोड ढूंढें, इसे डिबगर में पकड़ें, आदि। इस स्थिति में, यह स्ट्रीम नाम परिचित AWT-Windows

। हमें वही समस्या मिली जिसके बारे में टॉमकैट ने हमारे बारे में लिखा, केवल विजुअलवीएम के साथ। आप पहले से ही जानते हैं कि इसे कैसे हल करना है।

परिणाम

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

पर्मेन मेमोरी लीक विश्लेषण जावा में