Come vengono chiuse le chiusure JavaScript

Ho registrato il seguente bug di Chrome , che ha portato a molte perdite di memoria gravi e non ovvie nel mio codice:

(Questi risultati utilizzano il profiler di memoria di Chrome Dev Tools , che esegue il GC, e quindi acquisisce un'istantanea di heap di tutto ciò che non è stato raccolto e raccolto.)

Nel codice seguente, l' someClassistanza è garbage collection (buona):

var someClass = function() {};

function f() {
  var some = new someClass();
  return function() {};
}

window.f_ = f();

Ma non sarà spazzatura raccolta in questo caso (male):

var someClass = function() {};

function f() {
  var some = new someClass();
  function unreachable() { some; }
  return function() {};
}

window.f_ = f();

E lo screenshot corrispondente:

Sembra che una chiusura (in questo caso function() {}) mantenga "vivi" tutti gli oggetti se l'oggetto è referenziato da qualsiasi altra chiusura nello stesso contesto, indipendentemente dal fatto che tale chiusura stessa sia o meno raggiungibile.

La mia domanda riguarda la garbage collection della chiusura in altri browser (IE 9+ e Firefox). Conosco abbastanza bene gli strumenti di webkit, come il profiler di heap JavaScript, ma conosco poco degli strumenti di altri browser, quindi non sono stato in grado di testarlo.

In quale di questi tre casi IE9 + e Firefox garbage raccolgono l' someClass istanza?

Per quanto ne so, questo non è un bug ma il comportamento previsto.

Dalla pagina di gestione della memoria di Mozilla : "A partire dal 2012, tutti i browser moderni lanciano un garbage collector". "Limitazione: gli oggetti devono essere resi esplicitamente irraggiungibili " .

Nei tuoi esempi in cui fallisce someè ancora raggiungibile nella chiusura. Ho provato due modi per renderlo irraggiungibile ed entrambi funzionano. O imposti some=nullquando non ti serve più, oppure imposti window.f_ = null;e sparirà.

Aggiornare

L'ho provato in Chrome 30, FF25, Opera 12 e IE10 su Windows.

Lo standard non dice nulla sulla raccolta dei rifiuti, ma fornisce alcuni indizi su cosa dovrebbe accadere.

• Sezione 13 Definizione della funzione, passaggio 4: "Lascia che la chiusura sia il risultato della creazione di un nuovo oggetto Funzione come specificato in 13.2"
• Sezione 13.2 "un ambiente lessicale specificato da Scope" (scope = chiusura)
• Sezione 10.2 Ambienti lessicali:

"Il riferimento esterno di un ambiente lessicale (interno) è un riferimento all'ambiente lessicale che circonda logicamente l'ambiente lessicale interno.

Un ambiente lessicale esterno può ovviamente avere un proprio ambiente lessicale esterno. Un ambiente lessicale può fungere da ambiente esterno per più ambienti lessicali interni. Ad esempio, se una Dichiarazione di funzione contiene due Dichiarazioni di funzione nidificate, gli ambienti lessicali di ciascuna delle funzioni nidificate avranno come ambiente lessicale esterno l'ambiente lessicale dell'esecuzione corrente della funzione circostante. "

Quindi, una funzione avrà accesso all'ambiente del genitore.

Quindi, somedovrebbe essere disponibile nella chiusura della funzione di ritorno.

Allora perché non è sempre disponibile?

Sembra che Chrome e FF siano abbastanza intelligenti da eliminare la variabile in alcuni casi, ma sia in Opera che in IE la somevariabile è disponibile nella chiusura (NB: per visualizzare questo set attivo return nulle controllare il debugger).

Il GC potrebbe essere migliorato per rilevare se someviene utilizzato o meno nelle funzioni, ma sarà complicato.

Un cattivo esempio:

var someClass = function() {};

function f() {
  var some = new someClass();
  return function(code) {
    console.log(eval(code));
  };
}

window.f_ = f();
window.f_('some');

Nell'esempio sopra, il GC non ha modo di sapere se la variabile viene utilizzata o meno (codice testato e funziona in Chrome30, FF25, Opera 12 e IE10).

La memoria viene rilasciata se il riferimento all'oggetto viene interrotto assegnando un altro valore a window.f_.

Secondo me questo non è un bug.

Ho provato questo in IE9 + e Firefox.

function f() {
  var some = [];
  while(some.length < 1e6) {
    some.push(some.length);
  }
  function g() { some; } //removing this fixes a massive memory leak
  return function() {};   //or removing this
}

var a = [];
var interval = setInterval(function() {
  var len = a.push(f());
  if(len >= 500) {
    clearInterval(interval);
  }
}, 10);

Sito live qui .

Speravo di finire con un array di 500 function() {}, usando una memoria minima.

Sfortunatamente, non era così. Ogni funzione vuota mantiene una matrice (sempre irraggiungibile, ma non GC) di un milione di numeri.

Chrome alla fine si arresta e muore, Firefox termina il tutto dopo aver usato quasi 4 GB di RAM e IE diventa asintoticamente più lento fino a quando non mostra "Memoria insufficiente".

La rimozione di una delle righe commentate risolve tutto.

Sembra che tutti e tre questi browser (Chrome, Firefox e IE) mantengano un record ambientale per contesto, non per chiusura. Boris ipotizza che il motivo alla base di questa decisione sia la performance, e questo sembra probabile, anche se non sono sicuro di come si possa chiamare performante alla luce dell'esperimento di cui sopra.

Se è necessario un riferimento di chiusura some(scontato, non l'ho usato qui, ma immagina di averlo fatto), se invece di

function g() { some; }

Io uso

var g = (function(some) { return function() { some; }; )(some);

risolverà i problemi di memoria spostando la chiusura in un contesto diverso rispetto alla mia altra funzione.

Questo renderà la mia vita molto più noiosa.

PS Per curiosità, l'ho provato in Java (usando la sua capacità di definire le classi all'interno delle funzioni). GC funziona come avevo inizialmente sperato in Javascript.

L'euristica varia, ma un modo comune per implementare questo genere di cose è quello di creare un record di ambiente per ogni chiamata f()nel tuo caso e archiviare solo i locali fche sono effettivamente chiusi (da qualche chiusura) in quel record di ambiente. Quindi qualsiasi chiusura creata nella chiamata per fmantenere in vita il record dell'ambiente. Credo che questo sia il modo in cui Firefox implementa le chiusure, almeno.

Ciò ha i vantaggi di un rapido accesso alle variabili chiuse e della semplicità di implementazione. Ha lo svantaggio dell'effetto osservato, in cui una chiusura di breve durata che si chiude su alcune variabili fa sì che sia mantenuta in vita da chiusure di lunga durata.

Si potrebbe provare a creare più record di ambiente per diverse chiusure, a seconda di ciò che effettivamente chiudono, ma ciò può diventare molto complicato molto rapidamente e può causare problemi di prestazioni e memoria propri ...

1. Mantieni lo stato tra le chiamate di funzione Supponiamo che tu abbia la funzione add () e vorresti che aggiungesse tutti i valori passati in più chiamate e restituisse la somma.

come aggiungere (5); // restituisce 5

aggiungi (20); // restituisce 25 (5 + 20)

aggiungi (3); // restituisce 28 (25 + 3)

due modi per farlo prima è normale definire una variabile globale Naturalmente, è possibile utilizzare una variabile globale per contenere il totale. Ma tieni presente che questo tipo ti mangerà vivo se (ab) usi i globali.

ora il modo più recente di utilizzare la chiusura senza definire la variabile globale

(function(){

  var addFn = function addFn(){

    var total = 0;
    return function(val){
      total += val;
      return total;
    }

  };

  var add = addFn();

  console.log(add(5));
  console.log(add(20));
  console.log(add(3));
  
}());