#java #list #collections #&arba&e-collection
#java #Список #Коллекции #сборка мусора
Вопрос:
Я считываю из базы данных большие коллекции этого типа List<Rows<Lon&,Strin&,ByteBuffer&&t;&&t;
Затем я считываю данные из этого списка строк одну за другой и помещаю данные из них в объекты контейнера. Должен ли я отменять ссылки на отдельные строки в списке на null по мере продвижения к чтению каждой из них или я должен, наконец, отменить ссылки на них окончательно, чтобы их можно было собирать с помощью мусора?
Поскольку каждая строка довольно большая, состоящая из больших строк / больших двоичных объектов / текстового содержимого и т.д., я пытаюсь оптимизировать сборку мусора. Надеюсь, это не называется преждевременной оптимизацией!?
Комментарии:
1. Я боюсь сказать, что это называется
premature optimization. Вы проверили статистику использования JVM о том, сколько времени в среднем занимает &c?2. нет, я не использую JDBC. Я не проверял никакой статистики, но есть ли какие-либо недостатки указания на JVM переменных, которые больше не требуются? Каким может быть наказание здесь?
Ответ №1:
Если вы не измерили производительность своей программы, то это преждевременная оптимизация.
(Не каждая оптимизация, выполняемая перед измерением, преждевременна, но такого рода микрооптимизации являются таковыми.)
Комментарии:
1. есть ли какие-либо недостатки в указании на JVM переменных, которые больше не требуются? Каким может быть наказание здесь?
2. @Marcos: наказание заключается в том, что ваша программа становится более сложной, поэтому вы потратите больше времени на ее написание, поддержку и компиляцию, чем сэкономите при ее запуске. (На самом деле это может замедлиться и во время выполнения из-за плохой локализации ссылок и других факторов, но это трудно предсказать.)
Ответ №2:
я бы предложил разыменовать их. это не преждевременная оптимизация, потому что, в отличие от времени, объем памяти, доступный вашей программе для выполнения its, не в такой степени находится под вашим контролем.
Комментарии:
1. очевидно, что некоторые из других ответивших не понимают оптимизацию или преждевременную оптимизацию. аналогия между временем / процессором и памятью вряд ли переносится идеально. даже если бы это произошло, запрашивающий четко указывает, что строки представляют собой большие двоичные объекты, и вы резервируете N из них в памяти. далее, риски асимметричны, стоимость сборки мусора пропорциональна живым объектам (пропорциональна размеру N больших двоичных объектов), поэтому, если ваша платформа ограничена виртуальной памятью, ваш &c может собирать копии N больших двоичных объектов очень часто, что приводит к существенному зависанию вашей программы. просто не то же самое, что CPU
2. Память, используемая строкой, в основном представляет собой массив символов; с помощью ByteBuffer, в основном, какой-то массив байтов. Ни одна из них не содержит указателей, и поэтому ни одна из них не будет проверена сборщиком. Более того, даже если бы они были, если они долговечны, они были бы перемещены в старые пространства, которые сканируются нечасто и в которых объекты не перемещаются (пока они не будут сохранены). Нагрузка на процессор из-за существования этих объектов, скорее всего, будет очень небольшой.
3. Суть в том, что вы без необходимости сохраняете БОЛЬШИЕ куски памяти, а ограничения памяти непредсказуемы и могут серьезно повредить вашу программу. Если кто-то идет на такой риск только для того, чтобы избежать затрат на обнуление ссылки, его понимание оптимизации поверхностно. (отредактировано для объективности)
4. Ваша точка зрения кажется мне очень обоснованной, и это было причиной, по которой я спросил здесь. Мои большие двоичные объекты могут быть серьезно такими же большими, как все это обсуждение здесь. Теперь моя цель состояла в том, чтобы освободить память, поскольку я закончил копировать вопрос или каждый из ответов сверху вниз, 1-й вопрос, затем 1 ответ и так далее.
Ответ №3:
Как сказал ларсманс, это само определение преждевременной оптимизации. Однако часто возникают подобные вопросы, и вместо того, чтобы забывать о них, я предпочитаю сразу добавлять точки профилирования (включаемые переключателем, подобным Lo&&er.IsEnabled()), а затем двигаться дальше. Посмотрите на http://netbeans.or&/features/java/profiler.html для простого инструмента профилирования / настройки
Ответ №4:
Как упоминал Ларсманс, недостатком является сложность.
Но также может быть недостаток производительности — обнуление ссылки предполагает запись в память, а в современной среде сборки мусора запись в память не обязательно является просто хранилищем. Также может быть некоторый учет в интересах сборщика — посмотрите «барьер записи» и «маркировка карты» в контексте сборки мусора. Запись также влияет на кэши процессора; в многопроцессорной системе это приведет к нарушению согласованности кэша между процессорами, что потребляет пропускную способность.
Теперь я не думаю, что какой-либо из этих эффектов огромен. Но вы должны знать, что операции записи в память не всегда так дешевы, как вы могли бы подумать. Вот почему вы должны профилировать перед оптимизацией, а затем профилировать снова после этого!