когда system.gc () что-то делает?

<p>я знаю, что сборка мусора автоматизирована в java. но я понял, что если вы вызываете <code>system.gc()</code> в своем коде, jvm может или не может решить выполнить сборку мусора в этот момент. как это работает точно? на каком основании/параметрах именно jvm решает сделать (или не делать) gc, когда видит <code>system.gc()</code>?</p><p>есть ли примеры, в которых случае стоит добавить это в свой код?</p>

<p>на практике он <em>обычно</em> решает сделать сборку мусора. ответ зависит от множества факторов, например, от того, на какой jvm вы работаете, в каком режиме он работает и какой алгоритм сборки мусора он использует.</p><p>я не буду зависеть от этого в вашем коде. если jvm собирается сгенерировать outofmemoryerror, вызов system.gc () не остановит его, потому что сборщик мусора попытается освободить столько, сколько сможет, прежде чем он достигнет этого предела. единственный раз, когда я видел его на практике, это в ide, где он прикреплен к кнопке, которую пользователь может нажать, но даже там это не очень полезно.</p>

<p>единственный пример, который я могу вспомнить, где имеет смысл вызывать system.gc (), - это профилирование приложения для поиска возможных утечек памяти. я полагаю, что профилировщики вызывают этот метод непосредственно перед тем, как сделать снимок памяти.</p>

<p>вы не можете управлять gc в java - решает vm. я никогда не сталкивался со случаем, когда требуется <code>system.gc()</code> <em> </em>. поскольку вызов <code>system.gc()</code> просто предлагает, что vm выполняет сборку мусора, а также выполняет полную сборку мусора (старое и новое поколения в куче из нескольких поколений), то это может фактически вызвать <strong>больше</strong> циклов процессора потребляется, чем необходимо.</p><p>в некоторых случаях может иметь смысл предложить vm выполнить полную коллекцию сейчас, поскольку вы можете знать, что приложение будет простаивать в течение следующих нескольких минут, прежде чем произойдет тяжелая работа. например, сразу после инициализации большого количества временных объектов во время запуска приложения (то есть, я только что кэшировал тонну информации и знаю, что не буду много работать в течение минуты или около того). подумайте о ide, таком как запуск eclipse - он многое делает для инициализации, поэтому, возможно, сразу после инициализации имеет смысл сделать полный gc на этом этапе.</p>

<p>спецификация языка java не гарантирует, что jvm запустит gc при вызове <code>system.gc()</code>. это причина того, что "может или не может решить сделать gc в этот момент".</p><p>теперь, если вы посмотрите на <a href="http://openjdk.java.net/">исходный код openjdk</a> , который является основой oracle jvm, вы увидите, что вызов <code>system.gc()</code> действительно запускает цикл gc. если вы используете другую jvm, такую как j9, вы должны проверить их документацию, чтобы узнать ответ. например, jvm azul имеет сборщик мусора, который работает непрерывно, поэтому вызов <code>system.gc()</code> ничего не даст</p><p>в некоторых других ответах упоминается запуск gc в jconsole или visualvm. по сути, эти инструменты делают удаленный вызов <code>system.gc()</code>.</p><p>обычно вы не хотите запускать цикл сборки мусора из своего кода, так как он портится с семантикой вашего приложения. ваше приложение занимается бизнесом, jvm заботится об управлении памятью. вы должны разделить эти проблемы (не заставляйте ваше приложение управлять памятью, сосредоточьтесь на бизнесе).</p><p>однако есть несколько случаев, когда вызов <code>system.gc()</code> может быть понятен. рассмотрим, например, микробенчмарки. никто не хочет, чтобы цикл гх происходил в середине микробенчмарка. таким образом, вы можете запустить цикл gc между каждым измерением, чтобы убедиться, что каждое измерение начинается с пустой кучи.</p>

<p>вы должны быть очень осторожны, если вы звоните <code>system.gc()</code>. вызов этого может добавить ненужные проблемы с производительностью в ваше приложение, и это не гарантирует на самом деле выполнить коллекцию. на самом деле можно отключить явную функцию <code>system.gc()</code> через аргумент java <code>-xx:+disableexplicitgc</code>.</p><p>я настоятельно рекомендую прочитать документы, доступные по адресу <a href="http://java.sun.com/javase/technologies/hotspot/index.jsp">java hotspot garbage collection</a> , чтобы получить более подробную информацию о сборке мусора.</p>

<p><code>system.gc()</code> реализуется виртуальной машиной, и то, что она делает, зависит от конкретной реализации. например, разработчик может просто вернуться и ничего не делать.</p><p>что касается того, когда выдавать сбор вручную, то единственное время, когда вы можете захотеть это сделать, - это когда вы оставляете большую коллекцию, содержащую множество небольших коллекций - например, <code>map<string,<linkedlist>></code> - и хотите попробовать выполнить перфект и там, но по большей части, вы не должны беспокоиться об этом. gc знает лучше, чем вы - к сожалению - большую часть времени.</p>

<p>если вы используете прямые буферы памяти, jvm не запускает gc для вас, даже если у вас недостаточно прямой памяти.</p><p>если вы вызываете <code>bytebuffer.allocatedirect()</code> и получаете outofmemoryerror, вы можете обнаружить, что этот вызов в порядке после запуска gc вручную.</p>

<p>большинство jvm запускают gc (в зависимости от параметров -xx: diableexplicitgc и -xx: + explicitgcinvokesconcurrent). но спецификация просто не так хорошо определена, чтобы впоследствии обеспечить лучшую реализацию.</p><p>спецификация требует уточнения: <a href="http://bugs.sun.com/view\_bug.do?bug\_id=6668279">ошибка № 6668279: (спецификация) system.gc () должна указывать, что мы не рекомендуем использовать и не гарантируем поведение</a> </p><p>внутренне метод gc используется rmi и nio, и они требуют синхронного выполнения, которое: это в настоящее время обсуждается:</p><p> <a href="http://bugs.sun.com/view\_bug.do?bug\_id=5025281">ошибка # 5025281: разрешить system.gc () запускать одновременные (не останавливающие мир) полные коллекции</a> </p>

<p><code>garbage collection</code> хорош в <code>java</code>, если мы выполняем программное обеспечение, закодированное в java на рабочем столе/ноутбуке/сервере. вы можете вызвать <code>system.gc()</code> или <code>runtime.getruntime().gc()</code> в <code>java</code>.</p><p>просто отметьте, что ни один из этих звонков не гарантирует ничего. это всего лишь предложение для jvm запустить сборщик мусора. это зависит от jvm, независимо от того, запускает ли он gc или нет. итак, короткий ответ: мы не знаем, когда это произойдет. более длинный ответ: jvm запустит gc, если у него будет время для этого.</p><p>полагаю, то же самое относится и к android. однако это может замедлить работу вашей системы.</p>

<p>обычно vm автоматически выполняет сборку мусора, прежде чем выдать исключение outofmemoryexception, поэтому добавление явного вызова не должно помочь, за исключением того, что оно, возможно, перемещает попадание производительности в более ранний момент времени.</p><p>тем не менее, я думаю, что столкнулся со случаем, когда это может быть актуально. я не уверен, хотя, поскольку мне еще предстоит проверить, имеет ли это какой-либо эффект:</p><p>когда вы отображаете файл в память, я считаю, что вызов map () создает исключение ioexception, когда достаточно большой блок памяти недоступен. я думаю, что сбор мусора непосредственно перед файлом map () может помочь предотвратить это. как вы думаете?</p>

<p>мы никогда не сможем форсировать сборку мусора. system.gc предлагает только vm для сборки мусора, однако, на самом деле, в какое время работает механизм, никто не знает, как указано в спецификациях jsr.</p>

<p>нужно сказать, что нужно потратить много времени на тестирование различных параметров сборки мусора, но, как было упомянуто выше, это обычно бесполезно.</p><p>в настоящее время я работаю над проектом, включающим среду с ограниченным объемом памяти и относительно большие объемы данных - есть несколько больших фрагментов данных, которые доводят мою среду до предела, и хотя я смог сократить использование памяти, так что теоретически все должно работать нормально, я все равно получаю ошибки пространства кучи - подробные параметры gc показывают, что он пытается собрать мусор, но безрезультатно. в отладчике я мог бы выполнить system.gc () и убедиться, что будет "много" доступной памяти ... не много дополнительной, но достаточно.</p><p>следовательно, единственный раз, когда мое приложение вызывает system.gc (), это когда он собирается ввести сегмент кода, где будут выделены большие буферы, необходимые для обработки данных, и тест на доступную свободную память показывает, что я не гарантированно иметь его. в частности, я смотрю на среду объемом 1 гб, где статические данные занимают не менее 300 мб, причем основная часть нестатических данных связана с выполнением, за исключением случаев, когда обрабатываемые данные имеют размер не менее 100-200 мб. источник. все это является частью процесса автоматического преобразования данных, поэтому все данные существуют в течение относительно коротких периодов времени в долгосрочной перспективе.</p><p>к сожалению, в то время как информация о различных вариантах настройки сборщика мусора доступна, это в значительной степени экспериментальный процесс, и специфика более низкого уровня, необходимая для понимания того, как справляться с этими конкретными ситуациями, получить нелегко.</p><p>несмотря на это, несмотря на то, что я использую system.gc (), я все еще продолжал настраиваться с использованием параметров командной строки и сумел значительно увеличить общее время обработки моего приложения, несмотря на то, что не смог преодолеть камень преткновения, возникающий при работе с большими блоками данных. при этом system.gc () - это инструмент .... очень ненадежный инструмент, и если вы не будете осторожны с его использованием, вам захочется, чтобы он работал не чаще, чем нет.</p>

<p>короче:</p><p>параметры зависят от vm.</p><p>пример использования - не могу вспомнить ни одного для приложений времени выполнения/производственных приложений, но полезно запустить его для некоторых профилирующих процессов, таких как вызов</p><pre><code>// test run #1 test(); for (int i=0; i<10; i++) { // calling repeatedly to increase chances of a clean-up system.gc(); } // test run #2 test(); </code></pre>

<p>если вы хотите знать, вызывается ли ваша <code>system.gc()</code>, вы можете с помощью нового java 7 update 4 получать уведомление, когда jvm выполняет сборку мусора.</p><p>я не уверен на 100%, что класс <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/management/garbagecollectormxbean.html">garbagecollectormxbean</a> был представлен в java 7 обновление 4, потому что я не смог найти его в примечаниях к выпуску, но нашел информацию в сайт <a href="http://www.javaperformancetuning.com/news/newtips138.shtml">javaperformancetuning</a> .com</p>

<p>согласно "размышлению в java" брюса эккеля, один из вариантов использования явного вызова <strong>system.gc ()</strong> - это когда вы хотите принудительно завершить, т.е. вызов метода <strong>финализировать</strong>.</p>

<p>я не могу вспомнить конкретный пример, когда хорошо запустить явный gc.</p><p>в общем, запуск явного gc может на самом деле принести больше вреда, чем пользы, потому что явный gc вызовет полную коллекцию, которая проходит значительно дольше, когда проходит через каждый объект. если этот явный gc будет вызываться повторно, это может легко привести к медленной работе приложения, так как много времени тратится на выполнение полных gc.</p><p>в качестве альтернативы, если вы просматриваете кучу с помощью анализатора кучи и подозреваете, что компонент библиотеки вызывает явные gc, вы можете отключить его, добавив: gc = -xx: + disableexplicitgc к параметрам jvm.</p>

<p>пока работает system.gc, он остановит мир: все ответы останавливаются, поэтому сборщик мусора может сканировать каждый объект, чтобы проверить, не был ли он удален. если приложение представляет собой веб-проект, все запросы останавливаются до завершения gc, и это приведет к тому, что ваш веб-проект не сможет работать в моненте.</p>