स्मृति रिसाव के रूप में कुछ और जारी करना बंद करें

आज तक, बहुत सारे लेख लिखे गए हैं कि आपको अवलोकन योग्य आरएक्सजेएस सदस्यता से सदस्यता समाप्त करने की आवश्यकता है , अन्यथा स्मृति रिसाव हो जाएगा। ऐसे लेखों के अधिकांश पाठकों के लिए, फर्म नियम "हस्ताक्षरित? - साइन ऑफ!" मेरे सिर में रखा गया था। लेकिन, दुर्भाग्य से, अक्सर ऐसे लेखों में जानकारी विकृत होती है या कुछ पर बातचीत नहीं की जाती है, और यहां तक ​​कि तब भी जब अवधारणाएं बदल जाती हैं। हम इस बारे में बात करेंगे

उदाहरण के लिए इस लेख को लें: https://medium.com/ngx/why-do-you-need-unsubscribe-ee0c62b5d21f

जब वे मुझसे "प्रदर्शन में प्रतिगमन प्राप्त करने के संभावित अवसर" के बारे में कहते हैं, तो मैं तुरंत समयपूर्व अनुकूलन के बारे में सोचता हूं।

हम प्रतिक्रियाशील फॉक्स के तहत आदमी द्वारा लेख पढ़ना जारी रखते हैं:

इसके अलावा उपयोगी जानकारी और सुझाव है। मैं इस बात से सहमत हूं कि आपको हमेशा RxJS में अंतहीन धाराओं से हटना चाहिए । लेकिन मैं केवल हानिकारक जानकारी (मेरी राय में) पर ध्यान केंद्रित करता हूं।

वाह ... खौफ के साथ पकड़ा। वर्तमान समय में इस तरह के असंबद्ध (कोई मैट्रिक्स, संख्या ...) को डराना इस तथ्य को जन्म नहीं देता है कि बहुत बड़ी संख्या में फ्रंट-एंडर्स के लिए, सदस्यता का अभाव एक बैल के लिए लाल चीर की तरह है। जब वे इस पर ठोकर खाते हैं, तो उन्हें इस चीर के अलावा आसपास कुछ भी दिखाई नहीं देता है।

लेख के लेखक ने एक डेमो एप्लिकेशन भी बनाया, जहां उन्होंने अपने विचारों को साबित करने की कोशिश की:
https://stackblitz.com/edit/why-you-have-to-unsubscribe-from-observable-material

दरअसल, उसके स्टैंड पर आप देख सकते हैं कि प्रोसेसर कैसे अनावश्यक काम करता है (जब मैं कुछ भी नहीं क्लिक करता हूं) और मेमोरी की खपत कैसे बढ़ जाती है (एक छोटा परिवर्तन):

इस तथ्य की पुष्टि के रूप में कि आपको हमेशा अवलोकन योग्य HttpClient अनुरोधों की सदस्यता से सदस्यता समाप्त करने की आवश्यकता है , उन्होंने एक अनुरोध अवरोधक जोड़ा जो "अभी भी जीवित है ... अभी भी जीवित है ... अभी भी जीवित है ..." सांत्वना में:

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

StackBlitz आवेदन के प्रदर्शन को मापने के लिए बहुत उपयुक्त नहीं है, जैसा कि उन्नयन के दौरान स्वत: सिंक्रनाइज़ेशन होता है और इसमें संसाधन होते हैं। इसलिए मैंने अपना परीक्षण आवेदन किया: https://github.com/andchir/test-angular-app

वहां दो खिड़कियां हैं। जब आप प्रत्येक को खोलते हैं , तो कार्रवाई के लिए एक अनुरोध भेजा जाता है। एफपी , जिसमें एक बहुत ही संसाधन-गहन ऑपरेशन की नकल के रूप में 3 सेकंड की देरी होती है। इसके अलावा action.php log.txt फ़ाइल में सभी अनुरोधों को लॉग करता है।

<?php header('Content-Type: application/json'); function logging($str, $fileName = 'log.txt') { if (is_array($str)) { $str = json_encode($str); } $rootPath = __DIR__; $logFilePath = $rootPath . DIRECTORY_SEPARATOR . $fileName; $options = [ 'max_log_size' => 200 * 1024 ]; if (!is_dir(dirname($logFilePath))) { mkdir(dirname($logFilePath)); } if (file_exists($logFilePath) && filesize($logFilePath) >= $options['max_log_size']) { unlink($logFilePath); } $fp = fopen( $logFilePath, 'a' ); $dateFormat = 'd/m/YH:i:s'; $str = PHP_EOL . PHP_EOL . date($dateFormat) . PHP_EOL . $str; fwrite( $fp, $str ); fclose( $fp ); return true; } $actionName = isset($_GET['a']) && !is_array($_GET['a']) ? $_GET['a'] : '1'; logging("STARTED-{$actionName}"); sleep(3);// Very resource-intensive operation that takes 3 seconds logging("COMPLETED-{$actionName}"); echo json_encode([ 'success' => true, 'data' => ['name' => 'test', 'title' => 'This is a test'] ]); 

लेकिन पहले, एक छोटा विषयांतर। नीचे दी गई छवि में (क्लिक करने योग्य), आप एक सरल उदाहरण देख सकते हैं कि क्रोम ब्राउज़र क्रोम ब्राउज़र में कैसे काम करता है। PUSH हुआ, लेकिन setTimeout ने कचरा संग्रहकर्ता को मेमोरी साफ़ करने से नहीं रोका।

प्रयोग करते समय एक बटन के स्पर्श में कचरा कलेक्टर को कॉल करना याद रखें।

चलो मेरे परीक्षण आवेदन पर वापस आते हैं। यहाँ दोनों विंडो के लिए कोड है:

 @Component({ selector: 'app-bad-modal', templateUrl: './bad-modal.component.html', styleUrls: ['./bad-modal.component.css'], providers: [HttpClient] }) export class BadModalComponent implements OnInit, OnDestroy { loading = false; largeData: number[] = (new Array(1000000)).fill(1); destroyed$ = new Subject<void>(); data: DataInterface; constructor( private http: HttpClient, private bsModalRef: BsModalRef ) { } ngOnInit() { this.loadData(); } loadData(): void { // For example only, not for production. this.loading = true; const subscription = this.http.get<DataInterface>('/action.php?a=2').pipe( takeUntil(this.destroyed$), catchError((err) => throwError(err.message)), finalize(() => console.log('FINALIZE')) ) .subscribe({ next: (res) => { setTimeout(() => { console.log(subscription.closed ? 'SUBSCRIPTION IS CLOSED' : 'SUBSCRIPTION IS NOT CLOSED!'); }, 0); console.log('LOADED'); this.data = res; this.loading = false; }, error: (error) => { setTimeout(() => { console.log(subscription.closed ? 'ERROR - SUBSCRIPTION IS CLOSED' : 'ERROR - SUBSCRIPTION IS NOT CLOSED!'); }, 0); console.log('ERROR', error); }, complete: () => { setTimeout(() => { console.log(subscription.closed ? 'COMPLETED - SUBSCRIPTION IS CLOSED' : 'COMPLETED - SUBSCRIPTION IS NOT CLOSED!'); }, 0); console.log('COMPLETED'); } }); } close(event?: MouseEvent): void { if (event) { event.preventDefault(); } this.bsModalRef.hide(); } ngOnDestroy() { console.log('DESTROY'); this.destroyed$.next(); this.destroyed$.complete(); } } 

जैसा कि आप देख सकते हैं, एक सदस्यता समाप्त (टेक यूटिल) है। "शिक्षक" के रूप में सब कुछ हमें सलाह देता है। एक बड़ी सरणी भी है।

 @Component({ selector: 'app-good-modal', templateUrl: './good-modal.component.html', styleUrls: ['./good-modal.component.css'] }) export class GoodModalComponent implements OnInit, OnDestroy { loading = false; largeData: number[] = (new Array(1000000)).fill(1); data: DataInterface; constructor( private http: HttpClient, private bsModalRef: BsModalRef ) { } ngOnInit() { this.loadData(); } loadData(): void { // For example only, not for production. this.loading = true; const subscription = this.http.get<DataInterface>('/action.php?a=1').pipe( catchError((err) => throwError(err.message)), finalize(() => console.log('FINALIZE')) ) .subscribe({ next: (res) => { setTimeout(() => { console.log(subscription.closed ? 'SUBSCRIPTION IS CLOSED' : 'SUBSCRIPTION IS NOT CLOSED!'); }, 0); console.log('LOADED'); this.data = res; this.loading = false; }, error: (error) => { setTimeout(() => { console.log(subscription.closed ? 'ERROR - SUBSCRIPTION IS CLOSED' : 'ERROR - SUBSCRIPTION IS NOT CLOSED!'); }, 0); console.log('ERROR', error); }, complete: () => { setTimeout(() => { console.log(subscription.closed ? 'COMPLETED - SUBSCRIPTION IS CLOSED' : 'COMPLETED - SUBSCRIPTION IS NOT CLOSED!'); }, 0); console.log('COMPLETED'); } }); } close(event?: MouseEvent): void { if (event) { event.preventDefault(); } this.bsModalRef.hide(); } ngOnDestroy() { console.log('DESTROY'); } } 

एक बड़े सरणी के साथ एक ही संपत्ति है, लेकिन कोई सदस्यता नहीं है। और यह मुझे इस विंडो को एक अच्छा कॉल करने से नहीं रोकता है। क्यों - बाद में।

वीडियो देखें:

जैसा कि आप देख सकते हैं, दोनों मामलों में, दूसरे घटक पर स्विच करने के बाद, कचरा कलेक्टर ने मेमोरी को सामान्य मानों में सफलतापूर्वक वापस कर दिया। हां, विंडो बंद करने के बाद भी मेमोरी को खाली करना संभव हो सकता है, लेकिन हमारे प्रयोग में यह महत्वपूर्ण नहीं है। यह पता चला है कि "शिक्षक" गलत था जब उसने कहा:

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

हाँ, वह एक "संभावित" रिसाव के बारे में बात कर रहा है। लेकिन, यदि धारा परिमित है, तो मेमोरी रिसाव नहीं होगा।

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

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

निम्नलिखित वीडियो देखें:

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

परिणाम:

• मैं यह नहीं कह रहा हूँ कि आपको HttpClient अनुरोधों के RxJS सदस्यता से सदस्यता समाप्त करने की आवश्यकता नहीं है। मैं सिर्फ यह कहता हूं कि ऐसे समय होते हैं जब यह आवश्यक नहीं होता है। अवधारणाओं को प्रतिस्थापित करने की आवश्यकता नहीं है। यदि आप मेमोरी लीक के बारे में बात कर रहे हैं, तो इस लीक को दिखाएं। न कि आपका अंतहीन कंसोल.लॉग , जिसका नाम लीक है। स्मृति को किसमें मापा जाता है? ऑपरेशन समय को किसमें मापा जाता है? इसे दिखाने की जरूरत है।
• मैं अपने समाधान को नहीं कहता, जिसे मैंने परीक्षण अनुप्रयोग में लागू किया था, एक "चांदी की गोली"। इसके विपरीत, मैं सामने वाले को और अधिक स्वतंत्रता देने का आग्रह करता हूं। उसे अपने कोड को लिखने का तरीका तय करने दें। उसे डराने और विकास की अपनी शैली थोपने की जरूरत नहीं है।
• मैं कट्टरता और समय से पहले अनुकूलन के खिलाफ हूं। मैंने हाल ही में बहुत ज्यादा देखा है।
• ब्राउज़र में मेरे द्वारा दिखाए गए मेमोरी मेमोरी को खोजने के लिए अधिक उन्नत तरीके हैं। मुझे लगता है कि मेरे मामले में इस सरल विधि का आवेदन पर्याप्त है। लेकिन मेरा सुझाव है कि आप इस विषय में अपने आप को और अधिक विस्तार से परिचित कराएँ, उदाहरण के लिए, इस लेख में: https://habr.com/en/post/309318/ ।

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

UPD # 2
टिप्पणियों में, जेट फॉक्स दिखाई दिया (लेख का विश्लेषण किया जा रहा है)। सबसे पहले उन्होंने मुझे धन्यवाद दिया, वह बहुत विनम्र थे। लेकिन, दर्शकों की निष्क्रियता को देखकर वह दबाव बनाने लगा। यह इस बात के लिए मिला कि उन्होंने लिखा कि मुझे माफी मांगनी चाहिए। यानी उसने झूठ बोला (ऊपर एक पीले फ्रेम के साथ उल्लिखित), और मुझे माफी मांगनी चाहिए।
पहले मैंने सोचा कि अंतहीन दोहराव (अच्छी तरह से, 2-3 दोहराता है) के साथ धाराओं की इंटरसेप्टर, जो उन्होंने अपने डेमो आवेदन में लिखा था, केवल परीक्षणों और सूचनाओं के लिए है। लेकिन यह पता चला कि उन्होंने उसे जीवन से एक उदाहरण माना । यानी एक खिड़की के बटन को ब्लॉक करने के लिए - यह असंभव है । और इस तरह के इंटरसेप्टर बनाने के लिए, एसओएलआईडी के सिद्धांतों का उल्लंघन करते हुए, आवेदन की प्रतिरूपकता (मॉड्यूल और घटक एक दूसरे से स्वतंत्र होना चाहिए) का उल्लंघन करते हुए, जंगल के माध्यम से अपनी इकाइयों (घटकों, सेवाओं) के यूनिट परीक्षणों को दे सकते हैं - आप कर सकते हैं। स्थिति की कल्पना करें: आपने इसके लिए एक घटक, लिखित इकाई परीक्षण लिखा था। और फिर ऐसा फॉक्स दिखाई देता है, आपके आवेदन में एक समान इंटरसेप्टर जोड़ता है, और आपके परीक्षण बेकार हो जाते हैं। फिर भी वह आपसे कहता है: "आपने यह अनुमान क्यों नहीं लगाया कि मैं इस तरह का इंटरसेप्टर जोड़ना चाहता हूँ। ठीक है, अपना कोड सही करें।" शायद उनकी टीम में यह एक वास्तविकता हो सकती है, लेकिन मुझे नहीं लगता कि इसे प्रोत्साहित किया जाना चाहिए या इस पर आंखें मूंद लेनी चाहिए।

UPD # 3
टिप्पणियाँ ज्यादातर सदस्यता और सदस्यता समाप्त पर चर्चा करती हैं। क्या एक पोस्ट को "अनसब्सक्राइबिंग इविल" कहा जाता है? नहीं। मैं आपसे आग्रह नहीं करता कि आप सदस्यता समाप्त न करें। जैसा आपने पहले किया था वैसा ही करें। लेकिन आपको यह समझना चाहिए कि आप ऐसा क्यों कर रहे हैं। सदस्यता समाप्त करना समय से पहले का अनुकूलन नहीं है। लेकिन, संभावित खतरों के खिलाफ सुरक्षा के मार्ग पर कदम रखते हुए (विश्लेषण के तहत लेख के लेखक हमें कहते हैं), आप रेखा को पार कर सकते हैं। तब आपका कोड अतिभारित हो सकता है और बनाए रखना मुश्किल हो सकता है।
यह लेख कट्टरता के बारे में है, जो असत्यापित जानकारी के वितरण की ओर ले जाता है। कुछ मामलों में, एक अनसब्सक्राइब की अनुपस्थिति से अधिक शांति से संबंधित होना आवश्यक है (आपको स्पष्ट रूप से समझने की आवश्यकता है कि क्या किसी विशेष मामले में समस्या मौजूद है)।

UPD # 4

इसके विपरीत, मैं सामने वाले को और अधिक स्वतंत्रता देने का आग्रह करता हूं। उसे अपने कोड को लिखने का तरीका तय करने दें।

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

UPD # 5
सम्मानित लोगों के जवाब के साथ महत्वपूर्ण टिप्पणी:
https://habr.com/ru/post/479732/#comment_21012620
RxJS डेवलपर से "हस्ताक्षरित-सदस्यता समाप्त" अनुबंध को पूरा करने की सिफारिश मौजूद है , लेकिन अनौपचारिक रूप से।