Комментарии 10
Штука, безусловно, интересная
А есть реальные кейсы использования?
имхо, я пока вижу применение WeakRef лишь в сценарии, когда, например, у нас есть сокет-соединение, по которому на фронт часто сыпятся большие объёмы данных
Ещё когда вышли WeakSet и WeakMap, я не смог придумать им реального применения, хоть и пытался. Теоретически идея понятна, но какую из неё можно извлечь пользу в реальности, мягко говоря, неочевидно. С WeakRef та же история. В чем смысл? Ссылку на исходный объект автор все равно зануляет вручную. После неё осталась слабая ссылка, которая может быть ещё существует, а может уже и нет. Зачем нужен этот объект шрёдингера? Тут нет какого-то чудесного механизма, который работает сам собой и при этом всегда корректно. Всё равно вокруг этой лабуды будет ворох ручных обработок и проверок. В общем, не осилил я.
GC срабатывает не сразу. По этой причине можно вернуть ссылку на объект с WeakRef до срабатывания GC, конечно оно натянуто, в основном WeakRef и FinalizationRegister юзается совместно.
Более верный пример:
const ptr = wasmRuntime.allocateWasmObject();
const jsWrapper = new JSWrapper( ptr);
const registry = new FinalizationRegistry(( ptr) => {
wasmRuntime.free(ptr); // free wasm memory
});
registry.register( jsWrapper, ptr );
return jsWrapper;Я понимаю, что GC работает не сразу, и какое-то время ссылка еще поживёт. Я ж говорю - теоретически механизм понятен. Непонятно, какое в этом практическое удобство? Если я могу лишь рассчитывать, что ссылка вероятно жива, но гарантий нет - поэтому постоянно нужно это проверять и, при необходимости, загружать данные снова. Мне кажется, проще управлять кэшем самостоятельно - когда надо загрузил, когда надо очистил. Не полагаясь на какие-то малопредсказуемые явления природы.
Нуу тут момент в том, что ты не всегда можешь из кеша удалять объект, пока он где-то ещё используется в другом месте.
Он может быть структурно сложный, например imagwBitmap или BLOB требуют явного вызова close, чтобы удалить из памяти, и если это сделать когда кто-то его будет использоваться - ссылка останется, а данные будут битые.
Нет механизма отслеживания ссылок явно. Допустим у тебя был фетч каких-либо данных для 303737 табличек. Как узнать что все таблички закрыты? Каждая табличка тогда должна об этом сообщить. А вдруг какой-то Вася забудет сделать анмаунт колбек, в котором будет нотификация что пора удалить кеш в эффекте в каком-то фреймворке React подобном - вот и повисла память ( что всегда и случается на самом деле ).
Самостоятельно кешем как раз очень геморойно управлять, почти все реализации кешей в JS текут.
Пример с Map невалиден, нельзя хранить объект в Map или WeakMap, так как это явная ссылка.
WeakMap хранит «мягко» только ключи, это значит что если GC доберется до ключа, то запись будет удалена ( по этому нельзя там иметь примитивы )
Не рассказано что это было придумано для биндингов в wasm/webgpu, так как там неуправляемая память, и нужно знать когда JS объект был удален из памяти чтобы сделать очистку объекта на стороне wasm, webgpu или webgl, так как потерять реф на текстуру в webgl можно наизи и никто ее не улалит ( она может использоваться в рендер процессе )
Есть несколько вопросов по форме.
Итак, начнем с WeakRef. Это довольно свежая фича JavaScript (ES2021), которая позволяет создать "слабую" ссылку на объект, что означает: если этот объект больше нигде не используется, GC его может удалить, не дожидаясь, пока все ссылки будут явно сброшены.
Что значит нигде не используется? О каких ссылках в конце предложения идет речь? Вообще ничего непонятно. Почему просто не воспользоваться терминологией официальной документации? Т.е. есть объект, на него есть жесткие ссылки, жесткие ссылки удалены и объект поступает в GC
Но на этом все не заканчивается, потому что WeakRef открывает важный нюанс: слабая ссылка не защищает объект от удаления сборщиком мусора. Т.е ты можешь создать ссылку, но GC не пощадит твой объект, если тот больше не нужен.
Опять, небольшое замечание по форме. Вы только что дали целый абзац определения weakRef. А вот этот вот абзац не должен следовать из определения? И для чего вы одну и туже мысль повторяете раз за разом? Сначала "не защищает от удаления сборщиком" и тут же в следующем предложении "GC не пощадит твой объект". И опять же, может стоило ввести понятие жесткой ссылки и слабой ссылки, а не просто "ты можешь создать ссылку"
По идее, все это должно было быть часть определения weakRef
Поэтому WeakRef идеален для кейсов вроде кэширования, когда ты хочешь держать объект, пока он используется, но если он не нужен — его стоит обсвободить.
И опять вопрос по форме. Причем тут кэширование? Кэш - это доступ к данным, которые Могут потребоваться. Т.е. говоря вашими словами, кэш - это не то, что используется, а то, что может использоваться в будущем. И зачем же его тогда освобождать вот так вот непредсказуемо?
Очень не хочу никого обидеть, но я ничего не понял и полез в mdn и потом понял XD
Управление памятью в JavaScript с помощью WeakRef и FinalizationRegistry