J'ai lu pour essayer de donner un sens aux fuites de mémoire dans les navigateurs, en particulier. C'EST À DIRE. Je comprends que les fuites sont causées par une inadéquation dans les algorithmes de collecte des ordures entre le moteur JavaScript et l'arborescence de l'objet DOM, et perseront le passé. Ce que je ne comprends pas, c'est pourquoi (selon certaines déclarations dans les articles que je lis), la mémoire n'est pas récupérée une fois que la page est déchargée par le navigateur. Naviguer à l'écart d'une page Web doit mettre tous les objets Dom et JavaScript hors de portée à ce moment-là, n'est-ce pas?
3 Réponses :
La meilleure chose que je connaisse sur Les fuites de mémoire JavaScript ont été écrites par Doulgas Crockford .
Pour répondre à votre question, oui, le navigateur absolument doit décharger tous les objets (et surtout, les gestionnaires d'événements) au moment opportun. Si c'est le cas, cela n'aurait pas de fuites :)
Vous n'êtes pas obligé de leur donner un sens - ce sont des bugs dans les navigateurs et sont fixés à partir de versions vers des versions.
Juste parce qu'une version est corrigée n'exclut pas le bogue; Les anciennes versions du navigateur resteront en usage à moins que vous puissiez mettre à niveau tous vos clients. Lors du développement Web de comprendre comment fonctionne le navigateur est incroyablement important.
Voici le problème. Ie a un collecteur de déchets séparé pour le DOM et pour JavaScript. Ils ne peuvent pas détecter les références circulaires entre les deux.
Ce que nous avions l'habitude de nettoyer tous les gestionnaires d'événements de tous les nœuds du déchargement de la page. Cela pourrait toutefois arrêter le navigateur tout en déchargement. Cela n'a abordé que le cas où la référence circulaire a été causée par des gestionnaires d'événements. Il pourrait également être causé par l'ajout de références directes à partir de nœuds DOM sur des objets JS qui avaient une référence au nœud DOM lui-même.
Une autre bonne chose à retenir est que si vous supprimez des nœuds, c'est une bonne idée de Supprimez les gestionnaires en premier. EXT-JS a une méthode ext.destroy qui ne fait que (si vous avez défini les gestionnaires en utilisant ext).
exemple puis Microsoft piraté, c'est-à-dire qu'il a donc supprimé tous les gestionnaires d'événements et les propriétés d'expansion lors du déchargement en interne, c'est donc beaucoup plus rapide que de le faire avec JS. Ce correctif semblait résoudre nos problèmes de mémoire, mais pas tous les problèmes car il y a des gens qui ont toujours le problème. MS Livises Patch qui" corrige "des fuites de mémoire: Blog sur les fuites de mémoire fixe chez notre société, nous utilisons Ext-JS. En définissant toujours des gestionnaires d'événements utilisant EXT-JS, qui a une routine de nettoyage interne, nous n'avons pas expérimenté des fuites de mémoire. En réalité, l'utilisation de la mémoire se développe mais s'arrête à environ 250 Mo pour une machine avec 4 Go de RAM. Nous ne pensons pas que cela est dommage que nous chargons d'environ 2 Mo (non compressé) de fichiers JS et que tous les éléments de la page sont dynamiques. Il y a beaucoup à dire à ce sujet et nous avons étudié cela largement où je travaille. N'hésitez pas à poser une question plus précise. Je pourrais peut-être vous aider.
Merci pour votre recherche, IE9 s'est-il amélioré du tout? Nous vivons des fuites simplement en définissant la propriété InnerHTML, les clients sont en cours d'exécution sur VMware et la mémoire qui fuit rapidement. Demander aux utilisateurs intranet de rouvrir l'application n'est pas la solution, mais nous n'avons pas de choix.
@Alexandern Si vous rencontrez une croissance de la mémoire lors de la définition innerhtml , il est très probable que vous créez des fuites en supprimant les nœuds de la DOM sans avoir détaché des gestionnaires qui leur sont attachés. Vous ne devez jamais écraser innerhtml sans avoir enlevé d'abord aucun gestionnaire. Cela va pour n'importe quel navigateur.
exactement pourquoi ils sont des fuites :) La mémoire ne peut pas être récupérée.