Avoiding Memory Leaks

Kebocoran memori jarang terlihat di menit pertama. Halaman toko Budi dibuka lancar, tetapi setelah setengah jam memakainya — membuka panel, menutupnya, membuka lagi — tab browser makan ratusan MB dan semuanya melambat. Pola ini hampir selalu berarti satu hal: data yang sudah tidak dibutuhkan ternyata masih terjangkau bagi garbage collector, karena ada jalur referensi yang tersisa tanpa disadari.

Tiga sumber kebocoran paling umum di kode JavaScript adalah event listener yang tidak dilepas, interval yang tidak dihentikan, dan closure yang menahan data besar. Chapter ini membedah ketiganya lengkap dengan pola aman yang teruji.

Listener yang Tidak Pernah Dilepas #

Mekanismenya: setiap addEventListener menyimpan referensi function ke dalam registry milik elemen. Elemen halaman utama hidup selama halaman hidup, dan function di registry-nya ikut terjangkau — termasuk seluruh variabel yang dirujuk function itu. Menambah listener berulang kali tanpa melepasnya berarti menumpuk entri yang tidak pernah dibersihkan.

Pola amannya: simpan referensi function, lalu lepas dengan removeEventListener yang memakai referensi yang sama persis. Kita buktikan dengan penghitung klik:

// pasang-lepas-listener.js — listener yang dilepas tidak lagi berbunyi
const tombol = document.querySelector("#simpan");
let jumlahKlik = 0;

function catatKlik() {
  jumlahKlik++;
}

tombol.addEventListener("click", catatKlik);
tombol.click();
tombol.click();
console.log("dua klik :", jumlahKlik);

tombol.removeEventListener("click", catatKlik);
tombol.click();
console.log("klik lagi:", jumlahKlik);

Output yang Dihasilkan (pada tab Console browser):

dua klik : 2
klik lagi: 2

Mari kita telaah baris-baris pentingnya:

1. Baris 5–7 (function catatKlik): function dideklarasikan sebagai nama tersendiri, bukan function anonim di dalam addEventListener. Penamaan ini syarat teknis pola aman — removeEventListener butuh referensi yang sama, dan function anonim baru berarti function berbeda meski isinya serupa.
2. Baris 9–12 (pasang lalu dua klik): dua pemanggilan tombol.click() menghasilkan 2 — listener terpasang dan bekerja seperti biasa.
3. Baris 14 (removeEventListener("click", catatKlik)): entri di registry elemen dilepas. Mulai titik ini, object tombol tidak lagi menahan catatKlik — dan jumlahKlik bersama scope-nya ikut kehilangan jalur dari elemen.
4. Baris 15–16 (klik setelah dilepas): klik ketiga berjalan tanpa efek pada penghitung — tetap 2. Perilaku ini bukti bahwa pelepasan listener benar-benar berhenti di tengah, bukan sekadar “dibiarkan”.

Pada aplikasi nyata, pola ini menempel pada siklus hidup komponen: panel yang ditutup melepas listener-nya sendiri sebelum node-nya dihapus. Alternatif modern yang mengurangi pekerjaan manual: opsi { once: true } untuk listener sekali pakai, dan AbortController untuk melepas sekelompok listener sekaligus — keduanya dibahas di section Browser APIs dan Network dan API.

Jebakan yang paling sering terjadi justru di sini: listener dipasang dengan function anonim sehingga pelepasannya mustahil:

tombol.addEventListener("click", () => {
  jumlahKlik++; // function anonim: registry memegang identitas sendiri
});
tombol.removeEventListener("click", () => {
  jumlahKlik++;
}); // tidak berpengaruh — ini function lain, bukan yang terpasang

Kedua function di atas terlihat sama, tetapi setiap penulisan literal function membuat identitas baru — dan removeEventListener mencocokkan identitas, bukan isi. Pola catatKlik bernama pada berkas utama ada justru untuk menghindari jebakan ini.

Interval yang Tidak Pernah Dihentikan #

setInterval menugaskan runtime memanggil callback berulang-ulang sampai clearInterval dipanggil dengan id timernya. Karena itulah interval yang dilupakan adalah kebocoran ganda: callback-nya terus dieksekusi memakan waktu proses, dan seluruh data yang dirujuk callback tetap terjangkau. Berkas berikut membuktikan bahwa clearInterval menghentikan detak untuk selamanya:

// timer-terkontrol.mjs — clearInterval menghentikan detak untuk selamanya
let detak = 0;

const jam = setInterval(() => {
  detak++;
}, 5);

await new Promise((selesai) => setTimeout(selesai, 40));
clearInterval(jam);
const detakSaatBerhenti = detak;

await new Promise((selesai) => setTimeout(selesai, 40));
console.log("bertambah setelah clearInterval:", detak !== detakSaatBerhenti);

Menjalankan node timer-terkontrol.mjs menghasilkan:

Output yang Dihasilkan:

bertambah setelah clearInterval: false

Mari kita telaah baris-baris pentingnya:

1. Baris 4–6 (setInterval(..., 5)): callback menaikkan detak setiap 5 milidetik, dan id-nya disimpan di jam. Menyimpan id inilah langkah yang paling sering dilewatkan pemula.
2. Baris 8–10 (menunggu lalu berhenti): setelah 40 milidetik, clearInterval(jam) menghentikan timer dan detakSaatBerhenti mencatat posisi penghitung saat itu. Jumlah detaknya sendiri berbeda-beda antar mesin — yang penting bukan angkanya, tetapi keberadaan titik berhenti.
3. Baris 12–13 (menunggu lagi, lalu membandingkan): 40 milidetik kedua memberi waktu bagi timer yang “belum padam” untuk menaikkan detak — bila itu terjadi, perbandingan menghasilkan true. Keluaran false adalah bukti deterministik bahwa setelah clearInterval tidak ada satu pun detak baru, di mesin apa pun.

Gejala dua sumber pertama di atas bisa dikonfirmasi di sisi browser: tab Memory pada DevTools menyediakan heap snapshot — potret isi memori pada satu momen. Ambil satu potret, lakukan aksi yang dicurigai (buka-tutup panel, tekan tombol) beberapa kali, ambil potret kedua, lalu bandingkan: benda yang jumlahnya terus bertambah meski aksinya selesai adalah kandidat kebocoran. Alat itu melapor di sisi browser; kebiasaan menulis yang bersih tetap dibangun dari sisi kode — dan sumber ketiga berada tepat di bawah.

Closure yang Menahan Data Besar #

Sumber ketiga paling sulit dilihat: closure mempertahankan seluruh binding yang dirujuknya. Function kecil yang mengakses satu elemen array besar membuat array besar itu tetap terjangkau selama function-nya hidup. Perbandingan berikut memperlihatkan versi penahan dan versi ramping:

// tutup-rangkuman.js — closure menahan segala yang dirujuknya
function buatLaporanBesar() {
  const baris = new Array(100000).fill("transaksi");
  return {
    jumlahBaris: baris.length,        // nilainya disalin keluar
    barisPertama: () => baris[0],     // closure menahan seluruh array
  };
}

const laporan = buatLaporanBesar();
console.log(laporan.jumlahBaris);
console.log(laporan.barisPertama());

function buatLaporanRamping() {
  const baris = new Array(100000).fill("transaksi");
  const ringkasan = { jumlah: baris.length, awal: baris[0] };
  return {
    ringkasan: () => ringkasan,       // hanya ringkasan yang ditahan
  };
}

const laporanRamping = buatLaporanRamping();
console.log(laporanRamping.ringkasan().jumlah);
console.log(laporanRamping.ringkasan().awal);

Menjalankan node tutup-rangkuman.js menghasilkan:

Output yang Dihasilkan:

100000
transaksi
100000
transaksi

Mari kita telaah baris-baris pentingnya:

1. Baris 5 (jumlahBaris: baris.length): length adalah number — nilainya disalin keluar, tidak menahan array. Properti semacam ini aman meski laporannya dipakai selamanya.
2. Baris 6 (barisPertama: () => baris[0]): arrow function merujuk baris, sehingga selama object laporan terjangkau, array 100.000 elemen ikut terjangkau — meski yang dipakai hanya satu elemen. Keluaran transaksi membuktikan array itu memang masih utuh di tangan closure.
3. Baris 16 (const ringkasan = { ... }): versi ramping mengambil keputusan di titik lain — nilai yang benar-benar dibutuhkan disalin ke object kecil ringkasan, lalu array besar dibiarkan tanpa jalur.
4. Baris 18 (ringkasan: () => ringkasan): closure sekarang hanya menahan object dua field. Setelah buatLaporanRamping selesai, tidak ada jalur menuju array 100.000 elemen — GC berhak mengangkatnya kapan pun ia berjalan.

Bedah keduanya menghasilkan satu kaidah: yang ditahan closure sebaiknya sekecil kebutuhan. Bila pemakai hanya butuh ringkasan, salin ringkasannya — jangan berikan tombol kecil yang menggenggam gudang data.

Sebagai rangkuman, empat kebiasaan aman dari chapter ini:

• Simpan referensi function listener, lepas dengan removeEventListener saat komponen selesai.
• Simpan id setiap setInterval/setTimeout yang berulang, dan clearInterval saat layarnya ditutup.
• Di closure yang hidup lama, rujuk nilai hasil salinan — bukan array besar mentah.
• Anggap setiap pemakaian memori panjang harus punya titik akhir yang tertulis di kode.

Cara memeriksa kebenaran pola-pola ini di kode nyata adalah mengukurnya — dan pengukuran itulah topik chapter berikutnya.

// pasang-lepas-listener.js — listener yang dilepas tidak lagi berbunyi
const tombol = document.querySelector("#simpan");
let jumlahKlik = 0;

function catatKlik() {
  jumlahKlik++;
}

tombol.addEventListener("click", catatKlik);
tombol.click();
tombol.click();
console.log("dua klik :", jumlahKlik);

tombol.removeEventListener("click", catatKlik);
tombol.click();
console.log("klik lagi:", jumlahKlik);

// tutup-rangkuman.js — closure menahan segala yang dirujuknya
function buatLaporanBesar() {
  const baris = new Array(100000).fill("transaksi");
  return {
    jumlahBaris: baris.length,        // nilainya disalin keluar
    barisPertama: () => baris[0],     // closure menahan seluruh array
  };
}

const laporan = buatLaporanBesar();
console.log(laporan.jumlahBaris);
console.log(laporan.barisPertama());

function buatLaporanRamping() {
  const baris = new Array(100000).fill("transaksi");
  const ringkasan = { jumlah: baris.length, awal: baris[0] };
  return {
    ringkasan: () => ringkasan,       // hanya ringkasan yang ditahan
  };
}

const laporanRamping = buatLaporanRamping();
console.log(laporanRamping.ringkasan().jumlah);
console.log(laporanRamping.ringkasan().awal);