Есть ли способ в javascript создать «слабую ссылку» на другой объект? Вот вики-страница, описывающая, что такое слабая ссылка. Вот еще одна статья, описывающая их на Java. Может ли кто-нибудь придумать способ реализовать такое поведение в javascript?

В JavaScript нет языковой поддержки для weakrefs. Вы можете свернуть свой собственный, используя ручной подсчет ссылок, но не особенно плавно. Вы не можете создать объект-оболочку прокси, потому что в JavaScript объекты никогда не знают, когда они собираются собирать мусор.

Таким образом, ваша `` слабая ссылка '' становится ключом (например, целым числом) в простом поиске с помощью методов добавления ссылки и удаления ссылки, а когда больше нет отслеживаемых вручную ссылок, запись может быть удалена, оставив будущие поиски на этот ключ для возврата null.

На самом деле это не слабая ссылка, но она может решить некоторые из тех же проблем. Обычно это делается в сложных веб-приложениях, чтобы предотвратить утечку памяти из браузеров (обычно IE, особенно старые версии), когда существует цикл ссылок между узлом DOM или обработчиком событий и связанным с ним объектом, например закрытием. В этих случаях полная схема подсчета ссылок может даже не потребоваться.

При запуске JS на NodeJS вы можете рассмотреть https://github.com/TooTallNate/node-weak .

Обновление: сентябрь 2019 г.

Пока что невозможно использовать слабые ссылки, но, скорее всего, скоро это станет возможным, поскольку WeakRefs в JavaScript находятся в стадии разработки . Подробности ниже.

Предложение

Предложение находится в стадии 3, что означает, что оно имеет полную спецификацию и что дальнейшее уточнение потребует обратной связи от реализаций и пользователей.

Предложение WeakRef включает в себя две основные новые функциональные возможности:

• Создание слабых ссылок на объекты с помощью класса WeakRef
• Запуск определяемых пользователем финализаторов после сборки объектов с помощью класса FinalizationGroup

Сценарии использования

Первичное использование слабых ссылок является реализация кэшей или отображений , занимающих крупные объекты, где это желательно, чтобы крупный объект не оставлял в живых только потому , что появляется в кэше или отображения.

Завершение - это выполнение кода для очистки после того, как объект стал недоступен для выполнения программы. Определяемые пользователем финализаторы позволяют использовать несколько новых вариантов использования и могут помочь предотвратить утечки памяти при управлении ресурсами, о которых сборщик мусора не знает.

Источник и дальнейшее чтение

https://github.com/tc39/proposal-weakrefs
https://v8.dev/features/weak-references

Настоящих слабых ссылок нет, пока нет (но производители браузеров смотрят на эту тему). Но вот идея, как имитировать слабые ссылки.

Вы можете создать кеш, через который вы прогоните свои объекты. Когда объект сохраняется, кеш сохраняет прогноз того, сколько памяти займет объект. Для некоторых элементов, таких как хранение изображений, это легко решить. Для других это было бы труднее.

Когда вам нужен объект, вы запрашиваете его у кеша. Если в кеше есть объект, он возвращается. Если его нет, то элемент создается, сохраняется, а затем возвращается.

Слабые ссылки моделируются путем удаления элементов кэша, когда общий объем прогнозируемой памяти достигает определенного уровня. Он предскажет, какие элементы используются меньше всего, на основе того, как часто они извлекаются, с учетом того, как давно они были извлечены. «Расчетная» стоимость также может быть добавлена, если код, создающий элемент, передается в кеш в качестве закрытия. Это позволит хранить в кеше элементы, создание и создание которых очень дорогое.

Алгоритм удаления является ключевым, потому что, если вы ошибетесь, вы можете удалить самые популярные элементы. Это привело бы к ужасной производительности.

Пока кеш - единственный объект с постоянным ссылками на сохраненные объекты, указанная выше система должна работать довольно хорошо как альтернатива истинным слабым ссылкам.

Просто для справки; В JavaScript этого нет, но в ActionScript 3 (который также является ECMAScript) есть. Ознакомьтесь с параметром конструктора для словаря .

Использование механизма кэширования для имитации слабой ссылки, как было предложено выше в JL235 , является разумным. Если бы слабые ссылки существовали изначально, вы бы наблюдали подобное поведение:

this.val = {};
this.ref = new WeakReference(this.val);
...
this.ref.get(); // always returns val
...
this.val = null; // no more references
...
this.ref.get(); // may still return val, depending on already gc'd or not

В то время как с кешем вы бы наблюдали:

this.val = {};
this.key = cache.put(this.val);
...
cache.get(this.key); // returns val, until evicted by other cache puts
...
this.val = null; // no more references
...
cache.get(this.key); // returns val, until evicted by other cache puts

Как владелец ссылки, вы не должны делать никаких предположений о том, когда она ссылается на значение, это не отличается от использования кеша.

Наконец-то они здесь. Еще не реализовано в браузерах, но скоро будет.

https://v8.dev/features/weak-references

EcmaScript 6 (ES Harmony) имеет объект WeakMap . Браузерная поддержка среди современных браузеров довольно хороша (последние 3 версии Firefox, Chrome и даже будущая версия IE поддерживают ее).

http://www.jibbering.com/faq/faq_notes/closures.html

ECMAScript использует автоматическую сборку мусора. Спецификация не определяет подробностей, оставляя это на усмотрение разработчиков, а некоторые реализации, как известно, дают очень низкий приоритет своим операциям по сборке мусора. Но общая идея заключается в том, что если объект становится непригодным для обращения (из-за того, что на него не остается ссылок, оставшихся доступными для выполнения кода), он становится доступным для сборки мусора и в какой-то момент в будущем будет уничтожен, а любые ресурсы, которые он потребляет, будут освобождены и возвращены. в систему для повторного использования.

Обычно это происходит при выходе из контекста выполнения. Структура цепочки областей видимости, объект Activation / Variable и любые объекты, созданные в контексте выполнения, включая объекты функций, больше не будут доступны и, следовательно, станут доступны для сборки мусора.

То есть слабых нет, есть только те, которые больше не доступны.