बिना जीसी टच के जावा एप्लिकेशन को कैसे रोका जाए

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

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

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

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

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

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

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

इस विषय पर एक सर्वेक्षण में भी भाग लें।