Можно ли создать «слабую ссылку» в JavaScript?

Question

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Answer 4

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

Answer 5

Использование механизма кэширования для эмуляции слабой ссылки, как 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

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

Answer 6

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

Answer 7

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

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

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

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