Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
[JavaScript] Ассоциативные МАССИВЫ
|
|||
|---|---|---|---|
|
#18+
В общем вопрос в след. Node.js Создаю 2 массива содержащий 2 объекта, причем нумерация индексов в массиве идет через random Код: javascript 1. 2. 3. Как правильно удалить элемент массива чтобы не было утечек памяти. Если удалять через delete, то элемент массива остается, только не равным объекту. Не создаст ли это утечек памяти? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2016, 10:52 |
|
||
|
[JavaScript] Ассоциативные МАССИВЫ
|
|||
|---|---|---|---|
|
#18+
В JavaScript любой объект будет жить, пока на него существует хоть одна ссылка... Если ссылок не остаётся, то сборщик мусора может его удалить, а может и подержать какое-то время в кеше (на усмотрение среды исполнения, так как много чего может повторно использоваться). В случае простых типов (Number, String, Boolean) значение копируется непосредственно, в случае объектов всегда копируется ссылка на объект, по-сути все объекты внутри представляют из себя цепочки ссылок... так что утечки памяти очень вероятны, если при "удалении" объектов какие-то переменные или поля других объектов продолжают на них ссылаться. Код: javascript 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2016, 17:24 |
|
||
|
[JavaScript] Ассоциативные МАССИВЫ
|
|||
|---|---|---|---|
|
#18+
бухалтер фантоцциВ JavaScript любой объект будет жить, пока на него существует хоть одна ссылка... Если ссылок не остаётся, то сборщик мусора может его удалить, а может и подержать какое-то время в кеше (на усмотрение среды исполнения, так как много чего может повторно использоваться). В случае простых типов (Number, String, Boolean) значение копируется непосредственно, в случае объектов всегда копируется ссылка на объект, по-сути все объекты внутри представляют из себя цепочки ссылок... так что утечки памяти очень вероятны, если при "удалении" объектов какие-то переменные или поля других объектов продолжают на них ссылаться. Код: javascript 1. 2. 3. 4. 5. Это все я прочитал в мануале, но есть одно но. Когда я создал 100000 таких элементов, а затем удалил их, а далее сравнил память до выполнении операции и после, то оказалось что потребление ее возросло в разы.(использовал стандартную функцию process.memoryUsage() ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2016, 17:33 |
|
||
|
[JavaScript] Ассоциативные МАССИВЫ
|
|||
|---|---|---|---|
|
#18+
ну так сборщик мусора не сразу очищает память, любые браузеры аналогично работают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2016, 17:40 |
|
||
|
[JavaScript] Ассоциативные МАССИВЫ
|
|||
|---|---|---|---|
|
#18+
я бы разделил проблему (вопрос) на 3 части, а то сейчас путаница какая-то: 1. Вызывает ли утечки памяти создание 1000 элементов массива и потом их удаление посредством delete? 2. Если в массиве записан только первый и 158785-ый элемент, то будет ли выделена какая любо память под элементы между ними? 3. В какой момент можно быть уверенным, что используемый объект удалён? ответы: 1. Нет не вызывает, потому как delete говорит интерпретатору, что о существовании указанной переменной следует забыть. Следующая попытка обращения к ней вернёт undefined, что говорит об "незнании" интерпретатора о ней. 2. Не будет. В javascript все массивы ассоциативны. То есть реализация массива такова, что он не обязан быть непрерывным (как например в паскале). Это вызывает небольшие накладные расходы на запоминание прошлого/следующего элемента и т.д., но не более. 3. Наверное зависит от сборщика мусора. Однако, если бы я такой писал, то удалял бы я объекты в момент удаления последней ссылки на него. После этого хранить его в памяти не имеет ни малейшего смысла, так как к нему обращения невозможны. Однако, учитывая что удаление ссылки на один объект может сделать недоступным сразу 2 десятка сущностей, сборщик вероятно не спешит чистить память при каждом вызове delete, а просто по таймеру проверяет выделенные ему участки памяти и освобождает те, на которые в скрипте больше нету ссылок. Не думаю что сборщик мусора проводит зачистку раз в 20 минут )) скорее он делает это по несколько раз в секунду. Потому, тестовый скрипт давал утечку памяти, вероятнее всего, по иной причине (или же написан был не так). P.S. Если вышеописанное при выполнении вызывает утечку, то, при соблюдении всех изложенных правил, можно смело утверждать, что интерпретатор написан с ошибкой и потому допускает утечки памяти. )) В таком случае это проблема не скрипта, а разработчиков среды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.02.2016, 12:24 |
|
||
|
|

start [/forum/topic.php?fid=22&fpage=59&tid=1445445]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
58ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 181ms |

| 0 / 0 |
