Сборщик мусора против бассейна - PullRequest
1 голос
/ 10 февраля 2012

Я запускаю симуляции, которые включают создание дерева. Мое дерево имеет коэффициент ветвления от 2/3 до 7/8.

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

Мне интересно, лучше ли сборщику мусора выполнять свою работу (я «предлагаю» ему начать сбор с помощью System.gc (), когда я изменяю корень дерева) или реализую свой собственный пул для TreeNodes, и когда я меняю корень, перезаписываю все ненужные узлы.

Ответ можно прочитать так: является ли сборщик мусора для Android очень оптимизированным или предпочтительнее ограничения создания / уничтожения объекта, даже если это довольно затратно? (Мне нужно пройти по всему дереву и добавить каждое из них. бесполезный узел в стек для моего пула)

Я читал, что android GC не настолько "развит" (он в основном работает, когда у вас мало памяти.) Кроме того, я не знаю, позволит ли удаление каждой ссылки на корень дерева, чтобы сборщик мусора gc собирал все дерево за один проход, иначе он получит только узел, потом потомки этого узла на следующем проходе и т. д.

1 Ответ

1 голос
/ 10 февраля 2012

Для начала вам нужно понять, беспокоит ли вас даже ГК. Запустите ваше приложение с -verbosegc. Если ваш GC сообщает о проблемах производительности или накоплении памяти, вы можете беспокоиться об этом. В противном случае исключите это из вашего уравнения действий.

ГК работает на поколения. В основном ваши ассигнования делятся на поколения. По мере загрузки вашего приложения все выделения подпадают под поколение 0. И по мере того, как приложение прогрессирует, ваши выделения помещаются в поколение 1 и 2. GC при запуске не очень часто работает на поколении 0, как на 1. Аналогично, он не будет работать чаще в поколении 1, чем в 2. Это делается с предположением, что объекты, которые вы выделяете во время загрузки, не нужно освобождать так же часто, как объекты, созданные позже.

Интересная цитата из http://chaoticjava.com/posts/how-does-garbage-collection-work/

  • В любом приложении объекты могут быть классифицированы в соответствии с их жизнь он-лайн.
  • Некоторые объекты недолговечны, например, большинство местных переменные, а некоторые являются долгоживущими, такими как основа приложение.
  • Мысль о поколении мусора была стало возможным с пониманием того, что в приложении время жизни, большинство созданных объектов недолговечны, и что мало связей между долгоживущими объектами с недолговечными объекты.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...