Eh bien, je suppose que vous ne gardez pas une référence explicite à celui-ci car cela le forcerait à rester alloué.
Le test le plus simple auquel je puisse penser consiste en fait à allouer beaucoup de promesses et à ne pas les résoudre:
var $q = angular.injector(["ng"]).get("$q");
setInterval(function () {
for (var i = 0; i < 100; i++) {
var $d = $q.defer();
$d.promise;
}
}, 10);
Et puis regarder le tas lui-même. Comme nous pouvons le voir dans les outils de profilage de Chrome, cela accumule la mémoire nécessaire pour allouer 100 promesses, puis "y reste" à moins de 15 mégaoctets pour toute la page JSFIddle
De l'autre côté, si on regarde le $q
code source
Nous pouvons voir qu'il n'y a pas de référence d'un point global à une promesse particulière mais seulement d'une promesse à ses rappels. Le code est très lisible et clair. Voyons ce qui se passe si vous avez cependant une référence du rappel à la promesse.
var $q = angular.injector(["ng"]).get("$q");
console.log($q);
setInterval(function () {
for (var i = 0; i < 10; i++) {
var $d = $q.defer();
(function ($d) { // loop closure thing
$d.promise.then(function () {
console.log($d);
});
})($d);
}
}, 10);
Donc, après l'allocation initiale - il semble qu'il soit également capable de gérer cela :)
Nous pouvons également voir quelques modèles intéressants de GC si nous laissons son dernier exemple fonctionner pendant quelques minutes de plus. Nous pouvons voir que cela prend un certain temps - mais il est capable de nettoyer les rappels.
En bref - du moins dans les navigateurs modernes - vous n'avez pas à vous soucier des promesses non résolues tant que vous n'avez pas de références externes à celles-ci