Действительно ли это стоит смягчить против эффектов сборки "мусора"?

Если бы они были, они семантически не дифференцировались бы от указателей и составили бы синтаксический сахар. Ссылка говорит, "Я обращаюсь к чему-то, что имеет этот тип". Разрешение пусто или нулевая ссылка ослабило бы то различие от указателей.

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

11
задан Glorfindel 4 April 2019 в 16:59
поделиться

8 ответов

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

Библиотека Apache Commons Pool хороша для этого, хотя, если это мобильное приложение, вы можете не нужны накладные расходы зависимости библиотеки.

2
ответ дан 3 December 2019 в 08:30
поделиться

Это похоже на схему налегка , подробно описанную в книге шаблонов GoF (см. Правку ниже). Пулы объектов потеряли популярность в «обычных» виртуальных машинах из-за достижений в снижении затрат на создание объектов, синхронизацию и сборщик мусора. Однако они, безусловно, существуют уже давно, и, безусловно, можно попробовать их, чтобы увидеть, помогают ли они!

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

Только тест покажет вам, работает ли подход пула для вас на ваших целевых платформах! - Я взял ОП »

6
ответ дан 3 December 2019 в 08:30
поделиться

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

Проблема с объединением объектов в том, что оно делает ваше приложение медленнее, сложнее и потенциально содержит больше ошибок. Более того, каждый запуск GC может занять больше времени. (Все "простаивающие" объекты в пуле не являются мусором и должны быть помечены и т. Д. С помощью GC.)

2
ответ дан 3 December 2019 в 08:30
поделиться

Есть ли в J2ME сборщик мусора поколений? Если это так, он делает много небольших быстрых коллекций и, таким образом, сокращает паузы. Вы можете попробовать уменьшить объем памяти eden (небольшой объем памяти), чтобы увеличить частоту и уменьшить задержку для коллекций и, таким образом, уменьшить паузы.

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

2
ответ дан 3 December 2019 в 08:30
поделиться

Вы можете проверить эту ссылку , описывающую усовершенствования сборщика Concurrent Mark Sweep, хотя я не уверен, что он доступен для J2ME. В частности, примечание:

«Сборщик параллельной очистки меток, также известный как параллельный сборщик или CMS, нацелен на приложения, которые чувствительны к паузам сборки мусора».

... «В JDK 6 сборщик CMS при желании можно выполнять эти коллекции одновременно, чтобы избежать длительной паузы в ответ на вызов System.gc () или Runtime.getRuntime (). gc (). Чтобы включить эту функцию, добавьте параметр "

-XX:+ExplicitGCInvokesConcurrent 
1
ответ дан 3 December 2019 в 08:30
поделиться

Вы говорите о пуле экземпляров многократно используемых объектов.

class MyObjectPool { 
    List<MyObject> free= new LinkedList<MyObject>();
    List<MyObject> inuse= new LinkedList<MyObject>();
    public MyObjectPool(int poolsize) {
        for( int i= 0; i != poolsize; ++i ) {
           MyObject obj= new MyObject();
           free.add( obj );
        }
    }
    pubic makeNewObject( ) {
        if( free.size() == 0 ) {
            MyObject obj= new MyObject();
            free.add( obj );
        }
        MyObject next= free.remove(0);
        inuse.add( next );
        return next;
   }
   public freeObject( MyObject obj ) {
       inuse.remove( obj );
       free.add( obj );
   }
}
        return in
0
ответ дан 3 December 2019 в 08:30
поделиться

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

Как говорит oxbow_lakes, вы предлагаете стандартный шаблон проектирования. Однако, как и при любой оптимизации, единственный способ действительно узнать, насколько она улучшит ваше конкретное приложение, - это реализация и профилирование.

0
ответ дан 3 December 2019 в 08:30
поделиться

Посмотрите по этой ссылке . В частности:

Просто перечислю несколько проблем. пулы объектов создают: во-первых, неиспользуемый объект занимает место в памяти причина; GC должен обрабатывать неиспользованные объекты, задерживая его на бесполезные предметы без причины; И в чтобы получить объект из пул объектов синхронизация обычно требуется, что намного медленнее чем асинхронное распределение доступно изначально.

1
ответ дан 3 December 2019 в 08:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: