может ли быть утечка памяти в java

<p>я получил этот вопрос много раз. какой хороший способ ответить</p>

<blockquote> <p>может ли быть утечка памяти в java?</p> </blockquote><p>ответ в том, что это зависит от того, о какой утечке памяти вы говорите.</p><p>классические утечки памяти в c/c++ происходят, когда приложение игнорирует <code>free</code> или <code>dispose</code> объект, когда они закончили с ним, и оно протекает. циклические ссылки являются частным случаем этого, когда приложение испытывает затруднения, зная, когда <code>free</code><em><code>dispose</code>, и в результате этого пренебрегает. схожие проблемы связаны с тем, что приложение использует объект после его освобождения или пытается дважды его освободить. (вы можете назвать последние проблемы утечками памяти или просто ошибками. в любом случае ...)</p><p>java и другие (полностью<sup>1</sup>) управляемые языки \_/в основном</em> не страдают от этих проблем, потому что gc заботится об освобождении объектов, которые более недоступны. (конечно, проблем с висящим указателем и отсутствием двойного освобождения не существует, и циклы не являются проблематичными, как для «умных указателей» c/c++ и других схем подсчета ссылок.)</p><p>но в некоторых случаях gc в java будет пропускать объекты, которые (с точки зрения программиста) следует собирать мусором. это происходит, когда gc не может понять, что объект не может быть достигнут:</p><ul> <li>логика/состояние программы может быть таким, что пути выполнения, которые будут использовать некоторую переменную, не могут возникать. разработчик может видеть это как очевидное, но gc не может быть уверен, и ошибается в сторону осторожности (как это требуется).</li> <li>программист может ошибаться, и сборщик мусора избегает того, что в противном случае может привести к зависанию.</li> </ul><p>(обратите внимание, что причины утечек памяти в java могут быть простыми или довольно тонкими; см. ответ @ jonathan.cone для некоторых тонких. последний может включать внешние ресурсы, на которые вы <em>не должны</em> полагаться на gc, чтобы разберись в любом случае.)</p><p>в любом случае, вы можете столкнуться с ситуацией, когда нежелательные объекты не могут быть собраны в мусор, и зависают, связывая память ... утечка памяти.</p><p>тогда возникает проблема, заключающаяся в том, что приложение или библиотека java могут выделять объекты вне кучи через собственный код, которым необходимо управлять вручную. если приложение/библиотека содержит ошибки или используется неправильно, вы можете получить утечку памяти. (например: <a href="https://stackoverflow.com/questions/17015448/android-bitmap-memory-leak">утечка памяти android bitmap</a> ... отмечая, что эта проблема исправлена в более поздних версиях android.)</p><hr><p><sup>1 - я имею в виду пару вещей. некоторые управляемые языки позволяют писать неуправляемый код, где вы можете создавать классические утечки памяти. некоторые другие управляемые языки (или, точнее, языковые реализации) используют подсчет ссылок, а не надлежащий сборщик мусора. менеджеру хранилища на основе подсчета ссылок необходимо что-то (например, приложение), чтобы прервать циклы ... иначе произойдет утечка памяти.</sup></p>

<p>что ж, учитывая, что java использует сборщик мусора для сбора неиспользуемых объектов, вы не можете иметь висячий указатель. однако вы можете держать объект в области действия дольше, чем нужно, что можно считать утечкой памяти. подробнее об этом здесь: <a href="http://web.archive.org/web/20120722095536/http://www.ibm.com:80/developerworks/rational/library/05/0816\_guptapalanki/">http://web.archive.org/web/20120722095536/http://www.ibm.com:80/developerworks/rational/library/05/0816\_guptapalanki/</a> </p><p>вы берете тест на это или что-то? потому что это как минимум a + прямо здесь.</p>

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

<p>ответ звучит громко <strong>yes</strong>, но это, как правило, результат <em>модель программирования</em>, а не признак какого-либо дефекта в jvm. это часто случается, когда у фреймворков жизненные циклы отличаются от жизненных циклов jvm. вот некоторые примеры:</p><ol> <li> <a href="http://wiki.apache.org/commons/logging/frequentlyaskedquestions#a\_memory\_leak\_occurs\_when\_undeploying.2bac8-redeploying\_a\_webapp\_that\_uses\_commons\_logging.\_how\_do\_i\_fix\_this.3f">перезагрузка контекста</a> </li> <li> <a href="http://en.wikipedia.org/wiki/observer\_pattern">отсутствие разыменования наблюдателей (слушателей)</a> </li> <li> <a href="http://download.oracle.com/docs/cd/e13222\_01/wls/docs81/jconnector/connect.html">забыв очистить ресурсы после того, как вы их закончили</a> * </li> </ol><p>* - миллиарды консалтинговых долларов были сделаны для разрешения последнего</p>

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

<p>да, если вы не отменяете ссылки на объекты, они никогда не будут собираться мусором и использование памяти увеличится. однако из-за того, как устроен java, этого трудно достичь, в то время как в некоторых других языках это иногда трудно не достичь.</p><p>правка: прочитать ссылку амокране. хорошо.</p>

<p>книга <a href="https://rads.stackoverflow.com/amzn/click/com/0321356683">эффективная java</a> дает еще две причины "утечек памяти":</p><ul> <li>как только вы поместите ссылку на объект в <strong>cache</strong> и забудете, что она есть. ссылка остается в кеше задолго до того, как становится неактуальной. решение состоит в том, чтобы представить кэш в виде <a href="https://docs.oracle.com/javase/8/docs/api/java/util/weakhashmap.html">weakhashmap</a> </li> <li>в api, где клиенты регистрируют обратные вызовы и не регистрируют их явно. решение - хранить только слабые ссылки на них.</li> </ul>

<p>краткий ответ:</p><blockquote> <p>у компетентной jvm нет памяти утечки, но можно использовать больше памяти чем необходимо, потому что не все неиспользованные объекты были собраны мусором, еще. кроме того, сами приложения java могут содержать ссылки на объекты, которые им больше не нужны, и это может привести к утечке памяти.</p> </blockquote><p>еще более короткий ответ:</p><blockquote> <p>ява является языком и не может иметь утечки памяти, только java virtual машины могут.</p> </blockquote>

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

<p>да, это может быть в контексте, когда программа ошибочно удерживает ссылку на объект, который никогда больше не будет использоваться, и поэтому он не очищается gc.</p><p>примером этого было бы забыть закрыть открытый поток:</p><pre><code>class memoryleak { private void startleaking() throws ioexception { stringbuilder input = new stringbuilder(); urlconnection conn = new url("www.example.com/file.txt").openconnection(); bufferedreader br = new bufferedreader(new inputstreamreader(conn.getinputstream(), standardcharsets.utf\_8)); while (br.readline() != null) { input.append(br.readline()); } } public static void main(string[] args) throws ioexception { memoryleak ml = new memoryleak(); ml.startleaking(); } } </code></pre>

<p>один простой ответ: jvm позаботится обо всей вашей инициализации pojo [простых старых объектов java], если вы не работаете с jni. с jni, если вы сделали какое-то выделение памяти с помощью собственного кода, вы должны позаботиться об этой памяти самостоятельно.</p>

<p>да. утечка памяти - это неиспользуемая память, которая не передается диспетчеру памяти приложением.</p><p>я много раз видел java-код, который хранит элементы в структуре данных, но элементы никогда не удаляются оттуда, заполняя память до тех пор, пока не возникнет ошибка outofmemoryerror:</p><pre><code>void f() { list<integer> w = new arraylist<integer>(); while (true) { w.add(new integer(42)); } } </code></pre><p>хотя этот пример слишком очевиден, ошибки памяти java, как правило, более тонкие. например, используя dependency injection для сохранения огромного объекта на <a href="http://docs.jboss.org/seam/2.2.1.cr1/reference/en-us/html/concepts.html#d0e3960">компоненте с <code>session</code> scope</a> , не освобождая его, когда объект больше не используется.</p><p>на 64 битах vm это имеет тенденцию ухудшаться, поскольку пространство подкачки памяти начинает заполняться, пока система не сканирует слишком много операций io.</p>