जब हम वेबसाइटों के विकास से आगे बढ़े, तो सर्वर पर बनने वाले सिंगल-पेज वेब एप्लिकेशन के निर्माण के लिए सर्वर पर जो पेज बनते हैं, हमने गेम के कुछ नियमों को अपनाया। उनमें से एक उपयोगकर्ता के डिवाइस पर संसाधनों का सटीक हैंडलिंग है। इसका मतलब है - मुख्य धारा को अवरुद्ध न करें, लैपटॉप के पंखे को "स्पिन" न करें, फोन की बैटरी को न डालें। हमने वेब परियोजनाओं की अन्तरक्रियाशीलता में सुधार का आदान-प्रदान किया, और यह तथ्य कि उनका व्यवहार सामान्य अनुप्रयोगों के व्यवहार की तरह हो गया, समस्याओं का एक नया वर्ग जो सर्वर रेंडरिंग की दुनिया में मौजूद नहीं था।
ऐसी ही एक समस्या है मेमोरी लीक्स। एक खराब डिज़ाइन किया गया एक-पृष्ठ एप्लिकेशन आसानी से मेगाबाइट्स या यहां तक कि गीगाबाइट्स मेमोरी को बढ़ा सकता है। यह पृष्ठभूमि टैब पर चुपचाप बैठने पर भी अधिक से अधिक संसाधन लेने में सक्षम है। इस तरह के एक आवेदन का पृष्ठ, संसाधनों की अत्यधिक मात्रा पर कब्जा करने के बाद, "बहुत धीमा" करना शुरू कर सकता है। इसके अलावा, ब्राउज़र केवल टैब को बंद कर सकता है और उपयोगकर्ता को बता सकता है: "कुछ गलत हुआ।"कुछ गलत हो गयाबेशक, सर्वर पर प्रदान की जाने वाली साइटें मेमोरी रिसाव की समस्या से पीड़ित हो सकती हैं। लेकिन यहां हम सर्वर मेमोरी के बारे में बात कर रहे हैं। उसी समय, यह अत्यधिक संभावना नहीं है कि ऐसे एप्लिकेशन क्लाइंट पर मेमोरी रिसाव का कारण बनेंगे, क्योंकि ब्राउज़र पृष्ठों के बीच प्रत्येक उपयोगकर्ता संक्रमण के बाद मेमोरी को साफ करता है।स्मृति लीक का विषय वेब विकास प्रकाशनों में अच्छी तरह से शामिल नहीं है। और इसके बावजूद, मुझे लगभग यकीन है कि अधिकांश गैर-तुच्छ सिंगल-पेज एप्लिकेशन मेमोरी लीक से पीड़ित हैं - जब तक कि उनके साथ सौदा करने वाली टीमों के पास इस समस्या का पता लगाने और ठीक करने के लिए विश्वसनीय उपकरण नहीं हैं। यहाँ मुद्दा यह है कि जावास्क्रिप्ट में एक निश्चित मात्रा में स्मृति को बेतरतीब ढंग से आवंटित करना बेहद आसान है, और फिर इस स्मृति को मुक्त करना भूल जाते हैं।लेख का लेखक, जिसका अनुवाद आज हम प्रकाशित कर रहे हैं, पाठकों के साथ वेब एप्लिकेशन में मेमोरी लीक से निपटने के अपने अनुभव को साझा करने जा रहा है, और उनके प्रभावी खोज का उदाहरण भी देना चाहता है।इस बारे में इतना कम क्यों लिखा गया है?
सबसे पहले, मैं इस बारे में बात करना चाहता हूं कि मेमोरी लीक के बारे में इतना कम क्यों लिखा गया है। मुझे लगता है कि यहाँ आप कई कारण पा सकते हैं:- उपयोगकर्ता की शिकायतों का अभाव: अधिकांश उपयोगकर्ता वेब ब्राउज़ करते समय कार्य प्रबंधक की बारीकी से निगरानी करने में व्यस्त नहीं हैं। आमतौर पर, डेवलपर उपयोगकर्ता की शिकायतों का सामना नहीं करता है जब तक कि मेमोरी लीक इतनी गंभीर नहीं होती है कि यह काम करने में अक्षमता या एप्लिकेशन को धीमा कर देती है।
- : Chrome - , . .
- : .
- : «» . , , , , -.
वेब एप्लिकेशन, जैसे रिएक्ट, व्यू और स्वेल्टे विकसित करने के लिए आधुनिक लाइब्रेरी और फ्रेमवर्क, एप्लिकेशन के घटक मॉडल का उपयोग करते हैं। इस मॉडल के भीतर, मेमोरी लीक होने का सबसे आम तरीका कुछ इस तरह है:window.addEventListener('message', this.onMessage.bind(this));
बस इतना ही। यह एक स्मृति रिसाव के साथ एक परियोजना "लैस" करने के लिए आवश्यक है। ऐसा करने के लिए, बस कुछ वैश्विक ऑब्जेक्ट (जैसे , या , या कुछ इसी तरह) की addEventListener विधि को कॉल करें , और फिर, घटक को अनमाउंट करते समय, इवेंट सुनने वाले को हटाने के लिए RemoveEventListener विधि का उपयोग करके भूल जाएं । लेकिन इसके परिणाम और भी बुरे हैं, क्योंकि पूरे घटक का रिसाव होता है। यह इस तथ्य के कारण है कि विधि संलग्न है । इस घटक के साथ, इसके बाल घटकों का रिसाव होता है। यह बहुत संभावना है कि इस घटक से जुड़े सभी डोम नोड लीक हो जाएंगे। परिणामस्वरूप, स्थिति बहुत जल्दी नियंत्रण से बाहर हो सकती है, जिससे बहुत बुरे परिणाम हो सकते हैं।window<body>this.onMessagethisइस समस्या को हल करने का तरीका यहां दिया गया है:
this.onMessage = this.onMessage.bind(this);
window.addEventListener('message', this.onMessage);
window.removeEventListener('message', this.onMessage);
ऐसी स्थिति जिसमें स्मृति लीक सबसे अधिक बार होती है
अनुभव मुझे बताता है कि मेमोरी लीक निम्नलिखित एपीआई का उपयोग करते समय सबसे अधिक बार होता है:- विधि
addEventListener। यह वह जगह है जहाँ मेमोरी लीक्स सबसे अधिक बार होते हैं। समस्या को हल करने के लिए, यह सही समय पर कॉल करने के लिए पर्याप्त है removeEventListener। - setTimeout setInterval. , (, 30 ), , , , , clearTimeout clearInterval. ,
setTimeout, «» , , setInterval-. , setTimeout . - API IntersectionObserver, ResizeObserver, MutationObserver . , , . . - , , , , ,
disconnect . , DOM , , -. -, . — <body>, document, header footer, . - Promise-, , . , , — , . , , «» , . «»
.then()-. - वैश्विक वस्तुओं द्वारा प्रतिनिधित्व भंडार। जब आप किसी एप्लिकेशन की स्थिति को नियंत्रित करने के लिए Redux जैसी किसी चीज़ का उपयोग करते हैं , तो स्टेट स्टोर को एक वैश्विक ऑब्जेक्ट द्वारा दर्शाया जाता है। नतीजतन, यदि आप इस तरह के भंडारण से लापरवाही से निपटते हैं, तो अनावश्यक डेटा को इससे हटाया नहीं जाएगा, जिसके परिणामस्वरूप इसका आकार लगातार बढ़ेगा।
- अनंत डोम विकास। यदि पृष्ठ वर्चुअलाइजेशन के उपयोग के बिना अंतहीन स्क्रॉलिंग को लागू करता है , तो इसका मतलब है कि इस पृष्ठ पर DOM नोड की संख्या असीमित रूप से बढ़ सकती है।
ऊपर, हमने उन स्थितियों की जांच की जिसमें मेमोरी लीक सबसे अधिक बार होती है, लेकिन, निश्चित रूप से, कई अन्य मामले हैं जो हमारे लिए ब्याज की समस्या का कारण बनते हैं।स्मृति रिसाव की पहचान
अब हम मेमोरी लीक की पहचान करने की चुनौती पर आगे बढ़े हैं। इसके साथ शुरू करने के लिए, मुझे नहीं लगता कि कोई भी मौजूदा उपकरण इसके लिए बहुत उपयुक्त है। मैंने फ़ायरफ़ॉक्स मेमोरी एनालिसिस टूल्स की कोशिश की, एज और आईई से टूल्स की कोशिश की। यहां तक कि विंडोज प्रदर्शन विश्लेषक का परीक्षण किया गया। लेकिन इनमें से सबसे अच्छे उपकरण अभी भी क्रोम डेवलपर टूल हैं। सच है, इन उपकरणों में कई "तेज कोनों" हैं, जो जानने योग्य हैं।Chrome डेवलपर द्वारा दिए जाने वाले टूल में, हम Heap snapshotटैब से प्रोफाइलर में सबसे अधिक रुचि रखते हैं Memory, जो आपको ढेर स्नैपशॉट बनाने की अनुमति देता है। क्रोम में मेमोरी का विश्लेषण करने के लिए अन्य उपकरण हैं, लेकिन मैं मेमोरी लीक का पता लगाने में उनसे विशेष रूप से लाभ नहीं ले पाया हूं।हीप स्नैपशॉट टूल आपको मुख्य स्ट्रीम, वेब वर्कर या आइफ्रेम तत्वों की मेमोरी के स्नैपशॉट लेने की अनुमति देता है।यदि क्रोम टूल विंडो पिछले चित्र में दिखाए गए की तरह दिखता है, जब आप बटन पर क्लिक करते हैंTake snapshot, तो चयनित वर्चुअल मशीन की मेमोरी में सभी ऑब्जेक्ट्स के बारे में जानकारी कैप्चर की जाती है। जांच पृष्ठ का जावास्क्रिप्ट। इसमें संदर्भित ऑब्जेक्ट्स शामिल हैंwindow, कॉल में उपयोग की जाने वाली कॉलबैक द्वारा संदर्भित ऑब्जेक्ट्सsetInterval, और इसी तरह। स्मृति की एक स्नैपशॉट को जांच इकाई के काम के "जमे हुए क्षण" के रूप में माना जा सकता है, इस इकाई द्वारा उपयोग की जाने वाली सभी मेमोरी के बारे में जानकारी का प्रतिनिधित्व करता है।तस्वीर ली जाने के बाद, हम लीक को खोजने के अगले चरण पर आते हैं। इसमें एक परिदृश्य को पुन: प्रस्तुत करना शामिल है जिसमें, डेवलपर के अनुसार, एक मेमोरी लीक हो सकती है। उदाहरण के लिए, यह एक निश्चित मोडल विंडो को खोल और बंद कर रहा है। समान विंडो के बंद होने के बाद, यह उम्मीद की जाती है कि आवंटित मेमोरी की मात्रा उस स्तर पर वापस आ जाएगी जो खिड़की के खुलने से पहले मौजूद थी। इसलिए, वे एक और तस्वीर लेते हैं, और फिर इसकी तुलना पहले ली गई तस्वीर से करते हैं। तथ्य की बात के रूप में, छवियों की तुलना हमारे लिए सबसे महत्वपूर्ण विशेषता है Heap snapshot।हम पहले स्नैपशॉट लेते हैं, फिर हम ऐसी क्रियाएं करते हैं जो मेमोरी रिसाव का कारण बन सकती हैं, और फिर हम एक और स्नैपशॉट लेते हैं। यदि कोई रिसाव नहीं है, तो आवंटित मेमोरी का आकार बराबर होगा।सच है, यहHeap snapshotएक आदर्श उपकरण से बहुत दूर है। इसके बारे में जानने लायक कुछ सीमाएँ हैं:- यहां तक कि अगर आप
Memoryकचरा संग्रह शुरू करने वाले पैनल पर छोटे बटन पर क्लिक करते हैं ( Collect garbage), तो यह सुनिश्चित करने के लिए कि स्मृति वास्तव में साफ हो गई है, आपको लगातार कई तस्वीरें लेने की आवश्यकता हो सकती है। मेरे पास आमतौर पर तीन शॉट हैं। यहां यह प्रत्येक छवि के कुल आकार पर ध्यान देने योग्य है - यह, अंत में, स्थिर होना चाहिए। - -, -,
iframe, , , . , JavaScript. — , , . - «». .
इस बिंदु पर, यदि आपका आवेदन काफी जटिल है, तो आप स्नैपशॉट की तुलना करते समय बहुत सी "लीक" वस्तुओं को देख सकते हैं। यहां स्थिति कुछ जटिल है, क्योंकि स्मृति रिसाव के लिए जो गलत हो सकता है वह हमेशा ऐसा नहीं होता है। जो कुछ संदिग्ध है वह वस्तुओं के साथ काम करने की सामान्य प्रक्रिया है। कुछ ऑब्जेक्ट्स द्वारा कब्ज़ा की गई मेमोरी को इस मेमोरी में अन्य ऑब्जेक्ट्स को रखने के लिए साफ़ किया जाता है, कुछ को कैश में फ्लश किया जाता है, और इसी तरह की मेमोरी को तुरंत क्लियर नहीं किया जाता है, और इसी तरह।हम सूचना शोर के माध्यम से अपना रास्ता बनाते हैं
मैंने पाया कि सूचना के शोर के माध्यम से तोड़ने का सबसे अच्छा तरीका उन कार्यों को दोहराना है जो स्मृति रिसाव का कारण बनते हैं। उदाहरण के लिए, पहले शॉट को कैप्चर करने के बाद केवल एक बार मोडल विंडो को खोलने और बंद करने के बजाय, यह 7 बार किया जा सकता है। क्यों 7? हां, यदि केवल इसलिए कि 7 एक ध्यान देने योग्य प्रधान है। फिर आपको दूसरा शॉट लेने की जरूरत है और, पहले के साथ तुलना करते हुए, पता करें कि क्या एक निश्चित वस्तु "लीक" 7 बार (या 14 बार, या 21 बार) है।हीप स्नैपशॉट की तुलना करें। कृपया ध्यान दें कि हम छवि संख्या 3 की छवि संख्या 6 के साथ तुलना कर रहे हैं। तथ्य यह है कि मैंने तीन शॉट एक पंक्ति में लिए ताकि क्रोम में अधिक कचरा संग्रह सत्र हो। इसके अलावा, ध्यान दें कि कुछ वस्तुओं को "लीक" 7 बार किया गया है।एक और उपयोगी चाल यह है कि, अध्ययन की शुरुआत में, पहली तस्वीर बनाने से पहले, एक बार प्रक्रिया करें, जिसके दौरान अपेक्षा के अनुसार, स्मृति रिसाव। यह विशेष रूप से सिफारिश की जाती है यदि परियोजना में कोड विभाजन का उपयोग किया जाता है। ऐसे मामले में, यह बहुत संभावना है कि संदिग्ध कार्रवाई के पहले निष्पादन पर, आवश्यक जावास्क्रिप्ट मॉड्यूल लोड किए जाएंगे, जो आवंटित मेमोरी की मात्रा को प्रभावित करेगा।अब आपके मन में यह सवाल हो सकता है कि आपको वस्तुओं की संख्या पर विशेष ध्यान देना चाहिए, न कि स्मृति की कुल मात्रा पर। यहाँ हम कह सकते हैं कि हम सहज रूप से "लीक" मेमोरी की मात्रा को कम करने का प्रयास करते हैं। इस संबंध में, आप सोच सकते हैं कि आपको उपयोग की जाने वाली स्मृति की कुल मात्रा की निगरानी करनी चाहिए। लेकिन यह दृष्टिकोण, एक महत्वपूर्ण कारण के लिए, हमें विशेष रूप से अच्छी तरह से सूट नहीं करता है।अगर कुछ "लीक" होता है, तो ऐसा होता है क्योंकि ( जो आर्मस्ट्रांग को रिटेल करना ) आपको केले की आवश्यकता है, लेकिन आप एक केला, गोरिल्ला जो इसे धारण करते हैं, और इसके अलावा, सभी जंगल। यदि हम स्मृति की कुल मात्रा पर ध्यान केंद्रित करते हैं, तो यह जंगल को "मापने" के समान होगा, न कि वह केला जो हमारे हित में है।गोरिल्ला एक केला खा रहा है।अब वापस ऊपर के उदाहरण के साथaddEventListener। एक रिसाव स्रोत एक घटना श्रोता है जो एक फ़ंक्शन का संदर्भ देता है। और यह फ़ंक्शन, बदले में, एक घटक को संदर्भित करता है, जो संभवतः, एरे, स्ट्रिंग्स और ऑब्जेक्ट्स जैसे अच्छे सामान के एक गुच्छा से लिंक करता है।यदि आप छवियों के बीच अंतर का विश्लेषण करते हैं, तो उन मेमोरी की मात्रा के आधार पर संस्थाओं को छाँटते हैं, तो यह आपको कई सरणियों, रेखाओं, वस्तुओं को देखने की अनुमति देगा, जिनमें से अधिकांश लीक से संबंधित नहीं हैं। और आखिरकार, हमें उसी घटना श्रोता को खोजने की जरूरत है, जहां से यह सब शुरू हुआ। वह, जो वह संदर्भित करता है, उसकी तुलना में, बहुत कम मेमोरी लेता है। रिसाव को ठीक करने के लिए, आपको एक केला खोजने की जरूरत है, न कि जंगल की।परिणामस्वरूप, यदि आप "लीक" वस्तुओं की संख्या से रिकॉर्ड को सॉर्ट करते हैं, तो आप 7 इवेंट श्रोताओं को नोटिस करेंगे। और शायद maybe घटक, और १४ उपप्रधान, और शायद ऐसा ही कुछ और। यह संख्या 7 बड़ी तस्वीर से अलग होनी चाहिए, क्योंकि यह है, फिर भी, एक ध्यान देने योग्य और असामान्य संख्या है। इस मामले में, इससे कोई फर्क नहीं पड़ता कि संदिग्ध कार्रवाई कितनी बार दोहराई जाती है। छवियों की जांच करते समय, यदि संदेह उचित है, तो इसे कई "लीक" वस्तुओं के रूप में दर्ज किया जाएगा। यह है कि आप मेमोरी रिसाव के स्रोत को कैसे पहचान सकते हैं।लिंक ट्री विश्लेषण
स्नैपशॉट बनाने के लिए उपकरण "लिंक चेन" को देखने की क्षमता प्रदान करता है जो आपको यह पता लगाने में मदद करता है कि किन वस्तुओं को अन्य वस्तुओं द्वारा संदर्भित किया जाता है। यह वह है जो एप्लिकेशन को कार्य करने की अनुमति देता है। लिंक के ऐसे "चेन" या "ट्री" का विश्लेषण करके, आप यह पता लगा सकते हैं कि "लीक" ऑब्जेक्ट के लिए मेमोरी कहाँ आवंटित की गई थी।लिंक की श्रृंखला आपको यह पता लगाने की अनुमति देती है कि कौन सी वस्तु "टपकी" ऑब्जेक्ट को संदर्भित करती है। इन जंजीरों को पढ़ते समय, यह ध्यान रखना आवश्यक है कि नीचे स्थित वस्तुएं ऊपर स्थित वस्तुओं को संदर्भित करती हैं।उपरोक्त उदाहरण में, एक चर है जिसेsomeObjectक्लोजर में संदर्भित कियाजाता है(context) घटना श्रोता द्वारा संदर्भित। यदि आप स्रोत कोड तक जाने वाले लिंक पर क्लिक करते हैं, तो कार्यक्रम का एक काफी समझदार पाठ प्रदर्शित किया जाएगा:class SomeObject () { }
const someObject = new SomeObject();
const onMessage = () => { };
window.addEventListener('message', onMessage);
यदि हम इस कोड की तुलना पिछले आंकड़े से करते हैं, तो यह पता चलता है कि contextयह आंकड़ा एक क्लोजर है onMessageजो इसे संदर्भित करता है someObject। यह एक कृत्रिम उदाहरण है । वास्तविक मेमोरी लीक बहुत कम स्पष्ट हो सकते हैं।यह ध्यान देने योग्य है कि ढेर स्नैपशॉट टूल की कुछ सीमाएं हैं:- यदि आप एक स्नैपशॉट फ़ाइल सहेजते हैं और फिर इसे फिर से अपलोड करते हैं, तो कोड वाली फ़ाइलों के लिंक खो जाते हैं। अर्थात्, उदाहरण के लिए, एक स्नैपशॉट डाउनलोड करने के बाद, यह पता लगाना संभव नहीं होगा कि इवेंट श्रोता क्लोजर कोड फ़ाइल की लाइन 22 पर है
foo.js। चूंकि यह जानकारी बेहद महत्वपूर्ण है, हीप स्नैपशॉट फ़ाइलों को सहेजना, या, उदाहरण के लिए, उन्हें किसी को स्थानांतरित करना, लगभग बेकार है। WeakMap, Chrome , . , , , , . WeakMap — .- Chrome , . , , , , . ,
object, EventListener. object — , , , «» 7 .
यह मेमोरी लीक की पहचान करने के लिए मेरी मूल रणनीति का विवरण है। मैंने दर्जनों लीक का पता लगाने के लिए इस तकनीक का सफलतापूर्वक उपयोग किया है।सच है, मुझे यह कहना चाहिए कि मेमोरी लीक खोजने की यह मार्गदर्शिका वास्तविकता में जो कुछ हो रहा है उसका केवल एक छोटा सा हिस्सा कवर करती है। यह सिर्फ काम की शुरुआत है। इसके अलावा, आपको समस्या को हल करने के लिए ब्रेकप्वाइंट की स्थापना, लॉगिंग, परीक्षण सुधार को संभालने में सक्षम होना चाहिए। और, दुर्भाग्य से, यह सब, संक्षेप में, समय के एक गंभीर निवेश में अनुवाद करता है।स्वचालित स्मृति रिसाव विश्लेषण
मैं इस खंड को इस तथ्य से शुरू करना चाहता हूं कि मुझे मेमोरी लीक का पता लगाने के लिए एक अच्छा तरीका नहीं मिला। Chrome का अपना प्रदर्शन .emory API है , लेकिन गोपनीयता कारणों से, यह आपको पर्याप्त विस्तृत डेटा एकत्र करने की अनुमति नहीं देता है । परिणामस्वरूप, लीक का पता लगाने के लिए इस एपीआई का उपयोग उत्पादन में नहीं किया जा सकता है। W3C वेब परफॉर्मेंस वर्किंग ग्रुप ने पहले मेमोरी टूल्स पर चर्चा की थी , लेकिन इसके सदस्यों को इस एपीआई को बदलने के लिए डिज़ाइन किए गए एक नए मानक पर सहमत होना बाकी है।परीक्षण वातावरण में, आप performance.memoryChrome फ़्लैग का उपयोग करके डेटा आउटपुट की ग्रेन्युलैरिटी को बढ़ा सकते हैं - बेहतर-सटीक-मेमोरी-जानकारी। हीप स्नैपशॉट्स अभी भी Chromedriver की अपनी टीम का उपयोग करके बनाया जा सकता है : takeHeapSnapshot । इस टीम की वही सीमाएँ हैं जिनकी हम पहले ही चर्चा कर चुके हैं। यह संभावना है कि यदि आप इस कमांड का उपयोग करते हैं, तो, ऊपर वर्णित कारणों के लिए, इसे तीन बार कॉल करने के लिए समझ में आता है, और फिर केवल वही प्राप्त करें जो इसके अंतिम कॉल के परिणामस्वरूप प्राप्त हुआ था।चूंकि ईवेंट श्रोता मेमोरी लीक का सबसे आम स्रोत हैं, इसलिए मैं एक और लीक डिटेक्शन तकनीक के बारे में बात करता हूं जिसका मैं उपयोग करता हूं। यह एपीआई के लिए बंदर पैच बनाने addEventListenerऔर removeEventListenerलिंक को गिनने के लिए जांचता है कि उनकी संख्या शून्य पर लौट रही है। यह कैसे किया जाता है इसका एक उदाहरण यहां दिया गया है ।Chrome डेवलपर टूल में, आप यह जानने के लिए कि कौन से श्रोता किसी विशेष तत्व से जुड़े हैं , यह जानने के लिए getEventListeners देशी एपीआई का उपयोग कर सकते हैं । हालाँकि, यह कमांड केवल डेवलपर टूलबार से उपलब्ध है।मैं जोड़ना चाहता हूं कि माथियास बिनेंस ने मुझे एक और उपयोगी क्रोम टूल एपीआई के बारे में बताया। ये क्वेरीऑब्जेक्ट हैं । इसके साथ, आप एक निश्चित कंस्ट्रक्टर का उपयोग करके बनाई गई सभी वस्तुओं के बारे में जानकारी प्राप्त कर सकते हैं। यहाँ इस विषय पर कुछ अच्छी सामग्री पुतले में मेमोरी लीक डिटेक्शन को स्वचालित करने के बारे में है।सारांश
वेब एप्लिकेशन में मेमोरी लीक को खोजना और ठीक करना अभी भी अपनी प्रारंभिक अवस्था में है। यहाँ मैंने कुछ तकनीकों के बारे में बात की है, जो मेरे मामले में अच्छा प्रदर्शन करती हैं। लेकिन यह माना जाना चाहिए कि इन तकनीकों का अनुप्रयोग अभी भी कुछ कठिनाइयों और समय लेने वाली है।किसी भी प्रदर्शन के मुद्दों के साथ, जैसा कि वे कहते हैं, समय से पहले एक चुटकी एक पाउंड के लायक है। शायद किसी को पहले से होने वाले रिसाव के विश्लेषण के बजाय उपयुक्त सिंथेटिक परीक्षण तैयार करने के लिए यह उपयोगी लगेगा। और अगर यह एक रिसाव नहीं है, लेकिन कई हैं, तो समस्या का विश्लेषण प्याज को छीलने जैसी चीज में बदल सकता है: एक समस्या तय होने के बाद, दूसरी खोज की जाती है, और फिर यह प्रक्रिया (और यह सब समय, प्याज की तरह दोहराता है) , आँखों पर आँसू)। कोड समीक्षा आम लीक पैटर्न को पहचानने में भी मदद कर सकती है। लेकिन यह - यदि आप जानते हैं - कहाँ देखना है।जावास्क्रिप्ट एक ऐसी भाषा है जो स्मृति के साथ सुरक्षित काम करती है। इसलिए, वेब अनुप्रयोगों में मेमोरी लीक में आसानी से कुछ विडंबना है। सच है, यह आंशिक रूप से डिवाइस उपयोगकर्ता इंटरफेस की सुविधाओं के कारण है। आपको बहुत सी घटनाओं को सुनने की जरूरत है: माउस इवेंट, स्क्रॉल इवेंट, कीबोर्ड इवेंट। इन सभी पैटर्न को लागू करने से आसानी से मेमोरी लीक हो सकती है। लेकिन, यह सुनिश्चित करने का प्रयास करते हुए कि हमारे वेब एप्लिकेशन मेमोरी का संयम से उपयोग करते हैं, हम उनके प्रदर्शन को बढ़ा सकते हैं और उन्हें "क्रैश" से बचा सकते हैं। इसके अलावा, हम उपयोगकर्ता उपकरणों की संसाधन सीमाओं के लिए सम्मान प्रदर्शित करते हैं।प्रिय पाठकों! क्या आपको अपने वेब प्रोजेक्ट्स में मेमोरी लीक का सामना करना पड़ा है?