メモリリークを撲滅せよ：WeakMap/WeakSetの「型判定」という聖域
フロントエンドのアーキテクチャを設計する際、メモリ管理はしばしば「フレームワークが勝手にやってくれるもの」として軽視されがちだ。しかし、巨大なSPAや、長期間セッションを維持するダッシュボード、あるいは複雑なDOM操作を伴うエディタを開発していると、「いつの間にか肥大化するヒープメモリ」という悪夢に直面する。
その防波堤となるのが `WeakMap` と `WeakSet` だ。これらはガベージコレクション（GC）の挙動に直接介入する強力な武器だが、その「不可視性」ゆえに、型判定においては通常のオブジェクトとは一線を画す難しさがある。
今日は、この「幽霊のようなオブジェクト」を正しく識別し、堅牢なアーキテクチャを構築するための秘伝の知見を共有しよう。
—
1. なぜ WeakMap/WeakSet の判定は「泥臭い」のか
まず大前提として、`typeof` は何の役にも立たない。`typeof weakMap` は単に `’object’` を返すだけだ。これは `Map` や `Set`、あるいは単なる `{}` と区別がつかない。
さらに、これらのオブジェクトは「列挙不可能（non-enumerable）」だ。つまり、`for…in` や `Object.keys()` で中身を覗くことはできない。GCのトリガーを引くために、エンジン内部で非常に特殊な管理手法が取られているからだ。
ここで「じゃあ `instanceof` でいいじゃないか」と思うかもしれない。確かにそれも一つの手だが、iframeを跨ぐようなマルチコンテキスト環境や、ライブラリのバージョン競合によってプロトタイプチェーンが分断された瞬間、`instanceof` は無慈悲に `false` を吐き出す。
2. 現場で使える「最強の型判定」プロトコル
プロトタイプチェーンに依存せず、エンジン内部の仕様（`[[Brand]]`）を突く唯一無二の方法は、`Object.prototype.toString` を利用した `Symbol.toStringTag` の確認だ。
/
- 高精度な WeakMap/WeakSet 判定関数
- 外部コンテキストやプロトタイプ汚染の影響を受けない堅牢な設計
/
const isWeakMap = (value) => {
// toString.call を使うことで、[[Class]] 内部プロパティを直接参照する
return Object.prototype.toString.call(value) === ‘[object WeakMap]’;
};
const isWeakSet = (value) => {
return Object.prototype.toString.call(value) === ‘[object WeakSet]’;
};
// 検証用コード
const wm = new WeakMap();
console.log(isWeakMap(wm)); // true
console.log(isWeakMap({})); // false
このアプローチは、たとえ `WeakMap.prototype` を改ざんされたとしても（まずあり得ないが）、エンジンの内部状態を直接叩くため、極めて高い信頼性を誇る。
—
3. アーキテクトが知るべき「メモリ効率」の真実
なぜ我々は型判定にこだわるのか？ それは、「誤った型を WeakMap に突っ込むと、メモリリークの温床になる」からだ。
`WeakMap` のキーにはオブジェクトしか使えない。プリミティブ（文字列や数値）を渡そうとすれば、エンジンは即座に `TypeError` を投げる。もし、何らかのライブラリやユーティリティ関数で「オブジェクトが来ると想定して WeakMap に格納している処理」がある場合、型判定が甘いと `null` や `undefined` が紛れ込み、予期せぬクラッシュやGCの阻害を引き起こす。
実践：メモリ安全なキャッシュ管理
例えば、DOM要素に紐づくメタデータを保持する場合のパターンだ。
const metadataCache = new WeakMap();
function attachData(element, data) {
// 型判定を挟むことで、不正なデータによるメモリ汚染を未然に防ぐ
if (!(element instanceof Element)) {
throw new Error(‘WeakMapのキーにはDOM要素が必要です’);
}
metadataCache.set(element, data);
}
// この設計により、elementがDOMから削除（デタッチ）された瞬間、
// WeakMap内のデータも自動的にGCの対象となる。
// 開発者が手動で「クリーンアップ処理」を書く必要はもうない。
—
4. 非同期処理とGCの競合：上級者の罠
最後に、非同期処理と組み合わせる際の注意点を一つ。
`WeakMap` のキーに設定したオブジェクトが、非同期処理（`Promise` や `setTimeout`）の内部で参照され続けている場合、そのオブジェクトは決してGCされない。
「WeakMapを使っているから大丈夫」という過信は禁物だ。「どのスコープまで参照が生存しているか」を意識する視点は、依然としてアーキテクトの必須スキルである。
結論：型判定は単なるチェックではない
JavaScriptの型判定は、単に「バグを防ぐ」ための作業ではない。それは、「ブラウザエンジンという巨大な機械に対して、我々がメモリの管理権を委譲する際の合意書」のようなものだ。
`WeakMap` や `WeakSet` を適切に識別し、それを正しく運用することは、単なるパフォーマンスチューニングを超え、アプリケーション全体の安定性を底上げする。小手先のテクニックに溺れることなく、エンジンの内部挙動まで解像度を上げて設計する。それこそが、伝説と呼ばれるスペシャリストの仕事だ。
さあ、コードを開こう。君のアプリケーションに眠るリークの種を、今日こそ摘み取るんだ。
コメント