Comment garbage collection adresse-t-il des actions asynchrones dans mobx-utils?

Question

Je veux une méthode claire pour la création de magasins que je peux rafraîchir quand je sais de nouvelles données de service est disponible (comme lazyObservable de mobx-utils), mais facilement attacher des valeurs plus calculées et les fonctions d'action. À partir de create-react-app, utilisez index.js à partir de create-react-app.

import React from 'react'; 
import ReactDOM from 'react-dom'; 
import {observable} from 'mobx'; 
import {observer} from 'mobx-react'; 
import {asyncAction} from 'mobx-utils'; 

const flipACoin =() => Math.random() > 0.5; 

function determineGodliness() { 
    const screwYourRAM = new Array(1000000).fill(Math.random()); 

    return new Promise((resolve) => { 
    setTimeout(() => { 
     resolve([flipACoin(), flipACoin()]); 
    }, 1500); 
    }); 
} 

function godStore() { 
    const store = observable({ 
    alpha: false, 
    omega: false, 
    waiting: false, 
    refresh: asyncAction(function *() { 
     this.waiting = true; 
     [this.alpha, this.omega] = yield determineGodliness(); 
     this.waiting = false; 
    }), 
    get isGod() { 
     return this.alpha && this.omega; 
    } 
    }); 

    store.refresh(); 

    return store; 
} 

window.store = godStore(); 

const App = observer(({store}) => <p>{ 
    (store.waiting) 
    ? 'The suspense is killing me!' 
    : (store.isGod) 
     ? 'I am the Alpha and the Omega' 
     : 'I just work here.' 
}</p>); 

ReactDOM.render(<App store={window.store} />, document.getElementById('root')); 

Gestionnaire de tâches montre une augmentation de l'utilisation de la mémoire à chaque fois que vous exécutez window.store.refresh() dans la console. Il est intéressant de noter que l'utilisation de setInterval(window.store.refresh, 3000) provoque une oscillation de l'utilisation de la mémoire au lieu d'une montée linéaire. Entre ces deux cas conflictuels, je suis confus quant à la façon dont le garbage collector voit cette configuration.

Que puis-je faire pour être absolument certain que screwYourRAM finira par recevoir des ordures? Tout ce qui me tient à cœur c'est ce qui est retourné par le générateur, pas ce qui a été alloué entre temps.

Answer 1

Les fuites de mémoire sont difficiles à déterminer en regardant uniquement les graphiques. Afaik V8 ne sera pas toujours libérer toute la mémoire, à moins d'une véritable pénurie (GC-ing est une optimisation après tout, trop la collecte agressive permettra d'économiser la mémoire, mais brûler trop de cycles CPU. Vous ne pouvez pas assumer autant que je sache qu'une machine virtuelle nonchalante libère automatiquement toute la mémoire). Donc, je le teste habituellement avec un script de nœud qui continue de fonctionner et de répéter un processus pendant une longue période, et avec une quantité limitée de mémoire pour voir si quelque chose fuit réellement. Dans votre exemple, pour autant que je sache/sache, il n'y a pas de raison qu'il y ait fuite de mémoire. À un moment donné, la promesse est faite, ce qui permet d'obtenir les fermetures qui vont avec. La console de chrome gardera une référence à $_ de sorte que cela pourrait expliquer aussi l'augmentation de mémoire)

Pour voir correctement s'il y a des fuites de mémoire, utilisez les profileurs dans chrome/firefox, et assurez-vous de forcer un GC (devtools chrome a un bouton pour que, FF probablement aussi)