Не в случае SPA. Там браузер не знает про закрытие страниц, несмотря на то, что адрес в строке навигации меняется. С точки зрения браузера, страница одна. Я, в общем, про SPA пишу.
А, речь идет про переход между страницами в SPA? Тогда странно это называть утечкой памяти. Обычно люди называют то, что вы описали, кэшем.
Приложение загрузилось, и пока не выгрузится, держит users в памяти. Надо, чтобы их не было - выгрузи эксплицитно. Я не очень понимаю, почему от GC нужно ожидать чуткого отношения к переходам между псевдо-страницами. Так можно и при переходе по нормальному HTML3.2 анкору все перезагружать, но это как-то противоречит той логике, которая как раз породила SPA. Я не защищаю эту логику, я просто пытаюсь понять, почему вас удивляет, что утка и ходит, как утка, и квакает, как утка.
В С++ этому в принципе соответствует включение поля по значению. Оно ведет себя как композиция. В результате, деструктор по умолчанию работает правильно и автоматически. Это, собственно, ровно то, что и сделано у нас.
Не вижу, как включение поля по значению в плюсах могло бы решить проблему утечки для listeners. Если мы где-то сохранили ссылку на такое поле - она станет некорректной, когда объект умрёт. И, соответственно, если нам нужно гарантировать, что сохранённая ссылка корректна - придётся удерживать в памяти весь объект (привет, COM с его GetOuterUnknown). Т.е. опять нужна или явная отписка, или weak references.
> Не вижу, как включение поля по значению в плюсах могло бы решить проблему утечки для listeners.
Это позволяет автоматически сгенерировать корректный деструктор. Который пройдется по составному состоянию всех виджетов на странице, и рекурсивно отпишет агрегированные объекты от событий. Для этого системе надо отличать композицию от ассоциаций, чтобы не прибить то, что лежит в синглтоне.
Деструктор состояния в свою очередь вызывается автоматически при вынимании виджета из DOM. То есть, все надежно, и явной отписки нет.
Comments 15
Reply
Reply
Приложение загрузилось, и пока не выгрузится, держит users в памяти. Надо, чтобы их не было - выгрузи эксплицитно. Я не очень понимаю, почему от GC нужно ожидать чуткого отношения к переходам между псевдо-страницами. Так можно и при переходе по нормальному HTML3.2 анкору все перезагружать, но это как-то противоречит той логике, которая как раз породила SPA. Я не защищаю эту логику, я просто пытаюсь понять, почему вас удивляет, что утка и ходит, как утка, и квакает, как утка.
Reply
Утекающую вторую коллекцию люди обычно называют утечкой памяти. "Кэшем" это никто не называет.
> Приложение загрузилось, и пока не выгрузится, держит users в памяти.
Речь не о синглтоне users, а о второй коллекции. Утекает она. Перечитайте пост внимательно.
> я просто пытаюсь понять, почему вас удивляет
Меня ничего не удивляет. Я довольно хорошо понимаю, что в данном примере происходит и почему оно себя ведет так.
Reply
И правильно ли я понимаю, что для composited-полей и будут доступны только слабые ссылки? (ну то есть если выбо
Reply
Reply
Если мы где-то сохранили ссылку на такое поле - она станет некорректной, когда объект умрёт. И, соответственно, если нам нужно гарантировать, что сохранённая ссылка корректна - придётся удерживать в памяти весь объект (привет, COM с его GetOuterUnknown).
Т.е. опять нужна или явная отписка, или weak references.
Reply
Это позволяет автоматически сгенерировать корректный деструктор. Который пройдется по составному состоянию всех виджетов на странице, и рекурсивно отпишет агрегированные объекты от событий. Для этого системе надо отличать композицию от ассоциаций, чтобы не прибить то, что лежит в синглтоне.
Деструктор состояния в свою очередь вызывается автоматически при вынимании виджета из DOM. То есть, все надежно, и явной отписки нет.
Reply
Leave a comment