永远不会解决的承诺导致内存泄漏?

我有一个承诺。 我创build它来取消一个AJAX请求,如果我需要的话。 但是因为我不需要取消那个AJAX,所以我从来没有解决它,AJAX成功完成。

简化的sinippet:

var defer = $q.defer(); $http({url: 'example.com/some/api', timeout: defer.promise}).success(function(data) { // do something }); // Never defer.resolve() because I don't need to cancel that ajax. What happens to this promise after request? 

永远不会解决这样的承诺导致内存泄漏? 你有关于如何pipe理承诺生命周期的build议吗?

那么,我假设你没有明确提到它,因为这将迫使它保持分配。

我能想到的最简单的testing实际上是分配了许多承诺,而不是解决它们:

 var $q = angular.injector(["ng"]).get("$q"); setInterval(function () { for (var i = 0; i < 100; i++) { var $d = $q.defer(); $d.promise; } }, 10); 

然后看堆本身。 正如我们在Chrome分析工具中看到的那样,这会积累所需的内存以分配100个承诺,然后仅在整个JSFIddle页面的“兆字节数”不变的情况下“停留在那里”

在这里输入图像描述

另一方面,如果我们看$q源代码

我们可以看到,从全球angular度来看,没有任何特别的承诺,而只是从承诺callback。 代码是非常可读和清晰的。 让我们来看看,如果你确实有一个从callback到承诺的参考。

 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); 

在这里输入图像描述

所以在初始分配后 – 它似乎能够处理,以及:)

我们还可以看到一些有趣的GC模式,如果我们让他的最后一个例子运行几分钟。 我们可以看到,这需要一段时间 – 但它能够清理callback。

在这里输入图像描述

总之 – 至less在现代浏览器中 – 只要你没有外部引用,你就不必担心未解决的承诺