Управление памятью в java [duplicate]

Никто, кажется, не упоминал о явной установке ссылок на объекты на null, что является законной методикой «освобождения» памяти, которую вы можете рассмотреть.

Например, скажем, вы объявили List<String> в начале метода, который рос в размере, чтобы быть очень большим, но требовался только на полпути через метод. В этот момент вы можете установить ссылку «Список» на null, чтобы позволить сборщику мусора потенциально вернуть этот объект до завершения метода (и ссылка все равно выпадает из области).

Обратите внимание, что я редко использую этот метод в реальности, но его стоит учитывать при работе с очень большими структурами данных.

Althrough java предоставляет автоматическую сборку мусора, иногда вам нужно знать, насколько велик объект и сколько его осталось. Свободная память с программным программированием import java.lang; и Runtime r=Runtime.getRuntime(); для получения значений памяти с помощью mem1=r.freeMemory(); для освобождения память вызовет метод r.gc(); и вызов freeMemory()

* «Я лично полагаюсь на обнуление переменных в качестве заполнителя для последующего правильного удаления. Например, я трачу время, чтобы свернуть все элементы массива до фактического удаления (создания нулевого) самого массива.»

Это не нужно. Как работает Java GC, он находит объекты, которые не имеют к ним ссылок, поэтому, если у меня есть Object x с ссылкой (= variable) a, которая указывает на него, GC не удалит его, потому что есть ссылка к этому объекту:

a -> x

Если вы допустили null, это произойдет:

a -> null
     x

Итак, теперь x не имеет ссылки, указывающей на него, и будет удален. То же самое происходит, когда вы устанавливаете ссылку на другой объект, кроме x.

Итак, если у вас есть массив arr, который ссылается на объекты x, y и z и переменную a, которая ссылается на массив, выглядит так:

a -> arr -> x
         -> y
         -> z

Если вы null, чем это происходит:

a -> null
     arr -> x
         -> y
         -> z

Таким образом, GC обнаруживает, что arr не имеет ссылки на него и удаляет его, что дает вам эта структура:

a -> null
     x
     y
     z

Теперь GC находит x, y и z и удаляет их также. Отброс каждой ссылки в массиве не будет делать ничего лучше, он просто будет использовать время и пространство процессора в коде (это говорит, что это не повредит дальше. GC все равно сможет выполнить так, как это должно быть ).

Если вы действительно хотите выделить и освободить блок памяти, вы можете сделать это с помощью прямых ByteBuffers. Существует даже не переносимый способ освобождения памяти.

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

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

System.gc(); 

Запускает сборщик мусора. Вызов метода gc предполагает, что виртуальная машина Java тратит усилия на повторное использование неиспользуемых объектов, чтобы сделать память, которую они в настоящее время занимают, для быстрого повторного использования. Когда управление возвращается из вызова метода, виртуальная машина Java приложила все усилия, чтобы освободить место от всех отброшенных объектов.

Не рекомендуется.

Изменить: Я написал исходный ответ в 2009 году. Сейчас 2015 год.

Мусор коллекционеры стали неуклонно улучшаться в течение 20 лет, когда Java была вокруг. На данный момент, если вы вручную вызываете сборщик мусора, вы можете рассмотреть другие подходы:

• Если вы вынуждаете GC на ограниченном количестве машин, возможно, стоит иметь точку балансировки нагрузки прочь с текущего компьютера, ожидая завершения работы для подключения к подключенным клиентам, таймаута после некоторого периода для подключения соединений, а затем просто перезагрузить JVM. Это ужасное решение, но если вы посмотрите на System.gc (), принудительные перезагрузки могут быть возможной остановкой.
• Рассмотрите возможность использования другого сборщика мусора. Например, (новый за последние шесть лет) сборщик G1 - модель с низкой паузой; он использует больше процессора в целом, но лучше никогда не заставлять жесткую остановку при выполнении. Поскольку серверные процессоры теперь почти все имеют несколько ядер, это A действительно хороший компромисс, доступный.
• Посмотрите на использование памяти флагов. Особенно в новых версиях Java, если у вас нет таких многолетних запущенных объектов, подумайте о том, чтобы набрать размер newgen в куче. newgen (молодой) - это место, где выделяются новые объекты. Для веб-сервера здесь создается все, созданное для запроса, и если это пространство слишком мало, Java потратит дополнительное время на модернизацию объектов на более долговечную память, где их более дорого убить. (Если newgen немного слишком мал, вы заплатите за него.) Например, в G1: XX: G1NewSizePercent (по умолчанию 5, вероятно, не имеет значения.) XX: G1MaxNewSizePercent (по умолчанию 60, возможно, это .)
• . Рассматривая сборщик мусора, вы не в порядке с более длительной паузой. Это приведет к более частым запускам GC, чтобы система оставила все остальные ограничения. В G1: XX: MaxGCPauseMillis (по умолчанию 200.)

* «Например, скажем, что вы объявили список в начале метода, который рос в размере, чтобы быть очень большим, но требовался только до половины пути через метод. В этот момент вы могли бы установить список ссылка на null, чтобы позволить сборщику мусора потенциально вернуть этот объект до завершения метода (и ссылка все равно выпадает из области) ». *

Это правильно, но это решение не может быть обобщаемо. При установке ссылки на объект List на null -will-make память, доступную для сбора мусора, это справедливо только для объекта списка примитивных типов. Если объект List вместо этого содержит ссылочные типы, установка объекта List = null не приведет к разыменованию всех типов ссылок, содержащихся в списке. В этом случае установка объекта List = null приведет к сиротному содержанию ссылочных типов, чьи объекты не будут доступны для сбора мусора, если алгоритм сбора мусора достаточно умен, чтобы определить, что объекты были потеряны.

Я сделал эксперимент по этому поводу.

Правда, System.gc(); предлагает только запустить сборщик мусора.

Но вызывая System.gc(); после установки всех ссылок на null, улучшит производительность и занятость памяти.

Чтобы продлить ответ и комментарий Yiannis Xanthopoulos и Hot Licks (извините, я еще не могу прокомментировать!), вы можете установить параметры VM, как этот пример:

-XX:+UseG1GC -XX:MinHeapFreeRatio=15 -XX:MaxHeapFreeRatio=30

В моем jdk 7 это затем освободит неиспользуемую память VM, если более 30% кучи становится свободным после GC, когда VM находится в режиме ожидания. Вероятно, вам нужно будет настроить эти параметры.

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

Аргументы VM

Обновление: для java 1.8.0_73 У меня есть JVM иногда выпускает небольшие суммы с настройками по умолчанию. Появляется, только если это ~ 70% кучи не используется, хотя .. не знаю, будет ли это более агрессивным, если бы ОС была низкой в ​​физической памяти.

В моем случае, поскольку мой Java-код предназначен для переноса на другие языки в ближайшем будущем (главным образом, на C ++), я, по крайней мере, хочу заплатить за слова, чтобы освободить память правильно, чтобы впоследствии помочь в процессе переноса.

Я лично полагаюсь на обнуление переменных в качестве заполнителя для последующего правильного удаления. Например, я трачу время, чтобы свести на нет все элементы массива до фактического удаления (создания нулевого) самого массива.

Но мой случай очень специфичен, и я знаю, что занимаюсь хитами производительности, когда делаю это.

Рекомендация от JAVA заключается в присвоении null

из https://docs.oracle.com/cd/E19159-01/819-3681/abebi/index.html

Явное назначение нулевого значения переменным, которые больше не нужны, помогает сборщику мусора идентифицировать части памяти, которые можно безопасно восстановить. Хотя Java обеспечивает управление памятью, это не предотвращает утечку памяти или чрезмерное количество памяти.

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

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

Полностью из javacoffeebreak.com/faq/faq0012.html

Нить с низким приоритетом автоматически берет на себя сбор мусора для пользователя. Во время простоя поток может быть вызван, и он может начать освобождать память, ранее выделенную объекту в Java. Но не волнуйтесь - он не удалит ваши объекты на вас!

Когда ссылки на объект отсутствуют, это становится честной игрой для сборщика мусора. Вместо того, чтобы вызывать некоторую процедуру (например, free на C ++), вы просто присваиваете все ссылки объекту нулевому значению или присваиваете новый класс ссылке.

Пример:

public static void main(String args[])
{
  // Instantiate a large memory using class
  MyLargeMemoryUsingClass myClass = new MyLargeMemoryUsingClass(8192);

  // Do some work
  for ( .............. )
  {
      // Do some processing on myClass
  }

  // Clear reference to myClass
  myClass = null;

  // Continue processing, safe in the knowledge
  // that the garbage collector will reclaim myClass
}

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

System.gc();

Сборщик мусора попытается восстановить свободное пространство, и ваше приложение сможет продолжить выполнение, причем как можно больше памяти будет исправлено (могут возникнуть проблемы фрагментации памяти на определенных платформах).

Действительная причина для освобождения памяти от любой программы (java или нет) заключается в том, чтобы сделать больше памяти доступной для других программ на уровне операционной системы. Если в моем Java-приложении используется 250 МБ, я могу заставить его отключить до 1 МБ и сделать 249 МБ доступными для других приложений.