Bagi developer Node.js, artikel ini penting untuk diketahui. Masalah yang dibahas di sini dapat menimbulkan banyak kesulitan. Ini terkait dengan cara Node.js menangani timeout. Singkatnya, Anda bisa dengan mudah membuat kebocoran memori [1] menggunakan fungsi setTimeout di Node.js.
setTimeout: Fungsi Jadul dengan Masalah Baru
Anda mungkin sudah familiar dengan fungsi setTimeout. Fungsi ini telah disediakan oleh browser selama bertahun-tahun. Fungsinya cukup mudah: Anda menjadwalkan fungsi untuk dipanggil nanti, dan Anda mendapatkan token yang dapat digunakan untuk menghapus timeout tersebut nantinya. Contoh singkatnya:
const token = setTimeout(() => {}, 100);
clearTimeout(token);Di browser, token yang dikembalikan hanyalah sebuah angka. Namun, jika Anda melakukan hal yang sama di Node.js, token tersebut ternyata menjadi objek Timeout yang sebenarnya:
> setTimeout(() => {})
Timeout {
_idleTimeout: 1,
_idlePrev: [TimersList],
_idleNext: [TimersList],
_idleStart: 4312,
_onTimeout: [Function (anonymous)],
_timerArgs: undefined,
_repeat: null,
_destroyed: false,
[Symbol(refed)]: true,
[Symbol(kHasPrimitive)]: false,
[Symbol(asyncId)]: 78,
[Symbol(triggerId)]: 6
}Hal ini “membocorkan” sebagian internal dari bagaimana timeout diimplementasikan secara internal. Selama beberapa tahun terakhir, hal ini mungkin tidak menjadi masalah. Biasanya Anda menggunakan objek ini terutama sebagai token, mirip dengan yang Anda lakukan dengan angka. Mungkin terlihat seperti ini:
class MyThing {
constructor() {
this.timeout = setTimeout(() => { ... }, INTERVAL);
}
clearTimeout() {
clearTimeout(this.timeout);
}
}Awas, Objek Timeout Bisa Bocor!
Sepanjang masa pakai MyThing, bahkan setelah clearTimeout dipanggil atau timeout selesai berjalan, objek tersebut tetap memegang timeout ini. Saat selesai atau dibatalkan, timeout ditandai sebagai “destroyed” dalam Node.js dan dihapus dari pelacakan internalnya. Namun, yang terjadi adalah objek Timeout ini sebenarnya bertahan sampai seseorang menimpa atau menghapus referensi this.timeout. Hal ini terjadi karena objek Timeout yang sebenarnya yang ditahan, bukan hanya sebuah token.
Lebih lanjut, ini berarti garbage collector (pengumpul sampah) tidak akan benar-benar mengumpulkan objek ini dan semua yang direferensikannya. Ini tampaknya tidak terlalu buruk karena objek Timeout terlihat agak besar, tetapi tidak terlalu besar. Bagian yang paling bermasalah kemungkinan besar adalah member _onTimeout di dalamnya yang mungkin menarik closure (penutupan fungsi), tetapi pada praktiknya mungkin sebagian besar baik-baik saja.
Namun, objek timeout dapat bertindak sebagai wadah untuk lebih banyak state (keadaan) yang tidak begitu jelas. API baru yang telah ditambahkan selama beberapa tahun terakhir disebut AsyncLocalStorage yang mendapatkan daya tarik, sedang melampirkan state tambahan ke semua timeout yang aktif. Penyimpanan lokal asinkron diimplementasikan dengan cara di mana timeout (dan promise serta konstruksi serupa) meneruskan state tersembunyi hingga dijalankan:
const { AsyncLocalStorage } = require('node:async_hooks');
const als = new AsyncLocalStorage();
let t;
als.run([...Array(10000)], () => {
t = setTimeout(() => {
//
const theArray = als.getStore();
assert(theArray.length === 10000);
}, 10);
});
console.log(t);Ketika Anda menjalankan kode ini, Anda akan melihat bahwa Timeout menyimpan referensi ke array besar ini:
Timeout {
_idleTimeout: 100,
_idlePrev: [TimersList],
_idleNext: [TimersList],
_idleStart: 10,
_onTimeout: [Function (anonymous)],
_timerArgs: undefined,
_repeat: null,
_destroyed: false,
[Symbol(refed)]: true,
[Symbol(kHasPrimitive)]: false,
[Symbol(asyncId)]: 2,
[Symbol(triggerId)]: 1,
[Symbol(kResourceStore)]: [Array] // referensi ke array besar disimpan di sini
}Ini karena setiap penyimpanan lokal asinkron yang dibuat mendaftarkan dirinya sendiri dengan timeout dengan Symbol(kResourceStore) khusus yang bahkan tetap ada di sana setelah timeout dihapus atau timeout selesai berjalan. Ini