Arrêtez d'émettre autre chose comme une fuite de mémoire

À ce jour, de nombreux articles ont été écrits sur la nécessité de se désabonner des abonnements Observable RxJS, sinon une fuite de mémoire se produira. Pour la plupart des lecteurs de tels articles, la règle ferme «signé? - signez!» Était établie dans ma tête. Mais, malheureusement, souvent dans ces articles, les informations sont déformées ou quelque chose n'est pas négocié, et pire encore lorsque les concepts sont remplacés. Nous en parlerons.

Prenons par exemple cet article: https://medium.com/ngx/why-do-you-need-unsubscribe-ee0c62b5d21f

Quand ils me parlent de « l' opportunité potentielle d'obtenir une régression des performances», je pense tout de suite à une optimisation prématurée .

Nous continuons à lire l'article de l'homme sous le surnom de Reactive Fox :

De plus, il contient des informations et des conseils utiles. Je suis d'accord que vous devez toujours vous désabonner des flux sans fin dans RxJS . Mais je me concentre uniquement sur les informations nuisibles (à mon avis).

Wow ... rattrapé l'horreur. Une telle intimidation sans fondement (pas de métriques, de chiffres ...) à l'heure actuelle a conduit au fait que pour un très grand nombre de front-end, l'absence de désinscription est comme un chiffon rouge pour un taureau. Quand ils tombent dessus, ils ne voient plus rien d'autre que ce chiffon.

L'auteur de l'article a même fait une demande de démonstration, où il a essayé de prouver ses pensées:
https://stackblitz.com/edit/why-you-have-to-unsubscribe-from-observable-material

En effet, sur son stand, vous pouvez voir comment le processeur fait un travail inutile (quand je ne clique sur rien) et comment la consommation de mémoire augmente (un petit changement):

Pour confirmer le fait que vous devez toujours vous désabonner des abonnements aux requêtes HttpClient observables, il a ajouté un intercepteur de requête qui affiche "toujours vivant ... toujours vivant ... toujours vivant ..." dans la console:

C'est-à-dire la personne a intercepté le flux final, l'a rendu infini (en cas d'erreur, la demande est répétée, mais l'erreur se produit toujours) et donne cela comme preuve que vous devez vous désinscrire des flux finaux.

StackBlitz n'est pas très approprié pour mesurer les performances d'une application, il y a une synchronisation automatique pendant la mise à niveau et elle prend des ressources. J'ai donc fait ma demande de test: https://github.com/andchir/test-angular-app

Il y a deux fenêtres là-bas. Lorsque vous ouvrez chacun, une demande est envoyée à action.php , dans laquelle il y a un délai de 3 secondes comme une imitation d'une opération très gourmande en ressources. Action.php enregistre également toutes les demandes dans le fichier 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'] ]); 

Mais d'abord, une petite digression. Dans l'image ci-dessous (cliquable), vous pouvez voir un exemple simple du fonctionnement du ramasse-miettes JavaScript dans le navigateur Chrome. PUSH s'est produit, mais setTimeout n'a pas empêché le garbage collector de vider la mémoire.

N'oubliez pas d'appeler le ramasse-miettes en appuyant sur un bouton lorsque vous expérimentez.

Revenons à mon application de test. Voici le code pour les deux fenêtres:

 @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(); } } 

Comme vous pouvez le voir, il y a un désabonnement (takeUntil). Tout comme le "professeur" nous l'a conseillé. Il existe également un large éventail.

 @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'); } } 

Il y a exactement la même propriété avec un grand tableau, mais il n'y a pas de désabonnement. Et cela ne m'empêche pas d'appeler cette fenêtre une bonne. Pourquoi - plus tard.

Regardez la vidéo:

Comme vous pouvez le voir, dans les deux cas, après être passé au deuxième composant, le garbage collector a réussi à ramener la mémoire à des valeurs normales. Oui, on pourrait permettre de vider la mémoire également après la fermeture des fenêtres, mais dans notre expérience ce n'est pas important. Il s'avère que le "professeur" avait tort quand il a dit:

Par exemple, vous avez fait une demande, mais lorsque la réponse n'est pas encore arrivée du backend, vous détruisez le composant comme inutile, votre abonnement conservera le lien vers le composant , créant ainsi une fuite de mémoire potentielle.

Oui, il parle d'une fuite «potentielle» . Mais, si le flux est fini, il n'y aura pas de fuite de mémoire.

Je prévois les exclamations indignées de ces «professeurs». Ils vont certainement nous dire quelque chose comme: "ok, il n'y a pas de fuite de mémoire, mais en vous désinscrivant, nous annulons également la demande , ce qui signifie que nous serons sûrs qu'aucun code ne sera plus exécuté après avoir reçu une réponse du serveur . " Premièrement, je ne dis pas que la désinscription est toujours mauvaise, je dis simplement que vous remplacez les concepts . Oui, le fait qu'une fois la réponse arrivée, une autre opération inutile sera effectuée est mauvais, mais vous ne pouvez vous protéger contre une véritable fuite de mémoire qu'en vous désinscrivant (dans ce cas), et vous pouvez vous protéger contre d' autres effets indésirables par d' autres moyens . Pas besoin d'intimider les lecteurs et de leur imposer leur propre style d'écriture de code.

Avons-nous toujours besoin d'annuler la demande si l'utilisateur change d'avis? Pas toujours! N'oubliez pas que vous annulez la demande, mais vous n'annulez pas l'opération sur le serveur . Imaginez qu'un utilisateur a ouvert un composant, que quelque chose se charge depuis longtemps et qu'il passe à un autre composant. Il est possible que le serveur soit chargé et ne gère pas toutes les demandes et opérations. Dans ce cas, l'utilisateur peut piquer frénétiquement tous les liens dans la navigation et créer une charge encore plus importante sur le serveur , car la requête ne s'arrête pas côté serveur (dans la plupart des cas).

Regardez la vidéo suivante:

J'ai fait attendre l'utilisateur une réponse. Dans la plupart des cas, la réponse viendra rapidement et l'utilisateur ne rencontrera aucun inconvénient. Mais de cette façon, nous éviterons au serveur d'effectuer des opérations lourdes répétées, le cas échéant.

Résumé:

• Je ne dis pas que vous n'avez pas besoin de vous désabonner des abonnements RxJS des requêtes HttpClient. Je dis simplement qu'il y a des moments où cela n'est pas nécessaire. Pas besoin de remplacer les concepts. Si vous parlez d'une fuite de mémoire, montrez cette fuite. Pas votre console.log sans fin, à savoir une fuite. Dans quoi la mémoire est-elle mesurée? Quel est le temps de fonctionnement mesuré? C'est ce qu'il faut montrer.
• Je n'appelle pas ma solution, que j'ai appliquée dans l'application de test, une «solution miracle». Au contraire, j'exhorte le soumissionnaire à donner plus de liberté. Laissez-le décider comment écrire son code. Pas besoin de l'intimider et d'imposer son propre style de développement.
• Je suis contre le fanatisme et l'optimisation prématurée. J'en ai trop vu récemment.
• Le navigateur dispose de méthodes plus avancées pour détecter les fuites de mémoire que celle que j'ai montrée. Je pense que dans mon cas, l'application de cette méthode simple est suffisante. Mais je vous recommande de vous familiariser avec le sujet plus en détail, par exemple, dans cet article: https://habr.com/en/post/309318/ .

UPD # 1
Pour le moment, le poste s'est affaissé pendant presque une journée. Au début, il s'est tourné vers le pour et le contre, puis l'évaluation s'est arrêtée à zéro. Cela signifie que le public était divisé exactement en deux camps. Je ne sais pas si c'est bon ou mauvais.

UPD # 2
Dans les commentaires, Jet Fox est apparu (l'auteur de l'article analysé). Au début, il m'a remercié, il était très poli. Mais, voyant la passivité du public, il a commencé à faire pression. Il est arrivé au point où il a écrit que je devais m'excuser. C'est-à-dire il a menti (mensonges encadrés d'un cadre jaune au-dessus), et je dois m'excuser.
Au début, je pensais que l'intercepteur de flux avec des répétitions sans fin (enfin, 2-3 répétitions), qu'il a écrit dans son application de démonstration, est uniquement destiné aux tests et à l'information. Mais il s'est avéré qu'il le considérait comme un exemple de la vie. C'est-à-dire bloquer le bouton d'une fenêtre - c'est impossible . Et pour créer de tels intercepteurs, violant les principes de SOLID, violant la modularité de l'application (les modules et les composants doivent être indépendants les uns des autres), laissant les tests unitaires de vos unités (composants, services) à travers la forêt - vous pouvez. Imaginez la situation: vous avez écrit un composant, écrit des tests unitaires pour celui-ci. Et puis un tel Fox apparaît, ajoute un intercepteur similaire à votre application, et vos tests deviennent inutiles. Puis il vous dit toujours: "Pourquoi n'avez-vous pas prévu que je pourrais vouloir ajouter un tel intercepteur. Eh bien, corrigez votre code." C'est peut-être une réalité dans son équipe, mais je ne pense pas que cela devrait être encouragé ou fermé les yeux.

UPD # 3
Les commentaires traitent principalement des abonnements et des désabonnements. Un article intitulé "Se désabonner du mal"? Non. Je ne vous exhorte pas à ne pas vous désinscrire. Faites comme avant. Mais vous devez comprendre pourquoi vous faites cela. La désinscription n'est pas une optimisation prématurée. Mais, en marchant sur le chemin de la protection contre les menaces potentielles (comme nous appelle l'auteur de l'article analysé), vous pouvez franchir la ligne. Ensuite, votre code peut devenir surchargé et difficile à maintenir.
Cet article porte sur le fanatisme, qui conduit à la diffusion d'informations non vérifiées. Dans certains cas, il est nécessaire de relier plus calmement l'absence de désinscription (il faut bien comprendre si un problème existe dans un cas particulier).

UPD # 4

Au contraire, j'exhorte le soumissionnaire à se voir accorder plus de liberté. Laissez-le décider comment écrire son code.

Ici, vous devez clarifier. Je suis pour les standards. Mais la norme peut être fixée par l'auteur de la bibliothèque ou son équipe, alors que ce n'est pas le cas (dans la documentation et officiellement). Par exemple, la documentation du framework Symfony a une section Meilleures pratiques . S'il en était de même dans la documentation de RxJS et qu'il disait "désinscription-signature", je n'aurais pas envie de discuter avec lui.

UPD # 5
Commentaire important avec des réponses de personnes réputées:
https://habr.com/en/post/479732/#comment_21012620
La recommandation de respecter le contrat de «désinscription signée» du développeur RxJS existe , mais officieusement.