3 回答

TA貢獻1775條經驗 獲得超11個贊
好吧,我假設您沒有對其進行明確引用,因為這將迫使它保持分配狀態。
我能想到的最簡單的測試實際上是分配許多諾言而不是解決它們:
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個Promise,然后整個JSFIddle頁面的 “停留時間”不到15兆字節。
另一方面,如果我們看一下$q源代碼
我們可以看到,沒有從全局角度引用任何特定的Promise,而僅是從Promise到其回調。該代碼非常易讀和清晰。讓我們看看如果您確實從回調中引用了Promise。
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模式。我們可以看到它需要一些時間-但它能夠清除回調。
簡而言之-至少在現代瀏覽器中-您不必擔心未解決的承諾,只要您沒有對它們的外部引用

TA貢獻1784條經驗 獲得超8個贊
這就是我的想法。因此,問題是“永不解決的諾言會導致內存泄漏嗎?” 對于將回調傳遞給Promise的常見用例,答案是肯定的。您的答案中的這一行似乎與以下事實矛盾:“如果讓他的上一個示例再運行幾分鐘,我們還可以看到一些有趣的GC模式。我們可以看到它花了一段時間-但它能夠清理回調。 ” 抱歉,如果我要學步又挑剔,我只是想確保自己理解這一點。
添加回答
舉報