Вызовите явное удаление объекта Java

System.gc () - это только рекомендация для виртуальной машины Java. Вы называете это, и JVM может или не может запустить сборку мусора.

OutofMemoryException может быть вызвано двумя вещами. Либо вы держите (нежелательные) ссылки на ваши объекты, либо вы принимаете на многие пакеты.

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

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

Вы можете TUNE Коллекция мусора в Java, но вы не можете заставить.

Вам нужно найти Если вы держите на объекты дольше, чем необходимо. Первый шаг будет получать профилировщик в случае и посмотреть на кучу и понять, почему объекты не собираются.

Несмотря на то, что вы дали JVM 1GB, возможно, ваше молодое поколение слишком мало, если создаются многие объекты, очень быстро заставляют их в более старые поколения, где они не будут удалены как быстро.

Некоторая полезная информация о настройке GC: http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

Если ваш сервер работает как минимум за несколько минут до того, как он умирает, вы можете попробовать запускать его в Visual VM. Вы можете по крайней мере получить лучшее представление о том, как быстро растет куча, и какие объекты в нем.

Сервер принимает пакеты от клиентов (часто много мегабайт) и пересылает их другим клиентам.

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

Возможно, что у вас также есть утечка памяти, но если вышеизложенное верно, то эта конструкция "хранить и пересылать" - ваша самая большая проблема. Вы, вероятно, можете сократить использование памяти на 95%, если перепроектируете приложение так, чтобы оно не получало пакеты полностью, а передавало их непосредственно клиентам, т.е. читало только небольшую часть пакета за раз и немедленно передавало клиентам. Нетрудно сделать это таким образом, чтобы для клиентов это выглядело точно так же, как при хранении и пересылке.

Вручную запуск System.gc не является хорошим ответом, так как другие размещены здесь. Он не гарантируется запустить, и он вызывает полный GC, который, вероятно, повесит ваш сервер в течение длительного времени, пока он работает (> 1 сек, если вы даете свой сервер GB RAM, я видел несколько минут Длинные паузы на больших системах). Вы можете настроить свой GC, который, безусловно, поможет, но не полностью исправить проблему.

Если вы читаете объекты из одного потока, а затем пишу их в другой, то есть точка, в которой вы держите весь объект в памяти. Если эти объекты, как вы указываете, большие, то это может быть ваша проблема. Попробуйте переписать свой IO, чтобы вы читали байты от 1 поток и напишите их другому, не так явно держите полный объект (хотя я не вижу, как это будет работать с сериализацией / дезерриализацией объекта, если вам нужно проверить / подтвердить объекты ).

просто добавить ко всем предыдущим ответам : System.gc() - это не команда для JVM, чтобы инициировать сбор мусора... это кроткое направление и не гарантирует, что что-то случится. Спецификация JVM оставляет за поставщиками право принимать вызовы о том, что должно быть сделано на вызовах gc. Продавцы могут даже ничего не делать вообще!

Наткнулся на этот старый вопрос во время поиска чего-то другого. Я замечаю, что вы так и не получили полного ответа.

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

Спецификация: Хорошо сформированное двоичное дерево считается «сбалансированным по высоте», если (1) оно пустое, или (2) его левый и правый потомки сбалансированы по высоте, и высота левого дерева находится в пределах 1 от высоты правого дерева.

Теперь, когда у вас есть спецификация, код является тривиальным для записи. Просто следуйте спецификации:

IsHeightBalanced(tree)
    return (tree is empty) or 
           (IsHeightBalanced(tree.left) and
            IsHeightBalanced(tree.right) and
            abs(Height(tree.left) - Height(tree.right)) <= 1)

Перевод этого на выбранный вами язык программирования должен быть тривиальным.

Бонусное упражнение : этот наивный набросок кода слишком много раз пересекает дерево при вычислении высоты. Можете ли вы сделать его более эффективным?

Супер бонусное упражнение : предположим, дерево массово несбалансировано. Например, миллион узлов глубоко с одной стороны и три глубоко с другой. Есть ли сценарий, в котором этот алгоритм сдувает стек? Можете ли вы исправить реализацию так, чтобы она никогда не сдувала стек, даже когда дано массово несбалансированное дерево?

UPDATE : Donal Fellows точек в своем ответе, что есть разные определения «сбалансированных», которые можно выбрать. Например, можно принять более строгое определение «сбалансированной высоты» и потребовать, чтобы длина пути к ближайшему пустому потомку находилась в пределах одного из путей к самому удаленному пустому потомку. Мое определение менее строгое, чем это, и поэтому допускает больше деревьев.

Можно также быть менее строгим, чем мое определение; можно было бы сказать, что сбалансированное дерево - это дерево, в котором максимальная длина пути к пустому дереву на каждой ветви отличается не более чем на две, или на три, или на какую-то другую константу. Или максимальная длина пути составляет часть минимальной длины пути, например, половину или четверть.

Это действительно не имеет значения обычно. Точка любого алгоритма балансировки дерева состоит в том, чтобы гарантировать, что вы не окажетесь в ситуации, когда у вас есть миллион узлов с одной стороны и три с другой. Определение Донала прекрасно в теории, но на практике это боль, возникающая при использовании алгоритма балансировки деревьев, который соответствует этому уровню строгости. Экономия на производительности обычно не оправдывает затрат на внедрение. Вы тратите много времени на ненужные перестановки деревьев, чтобы достичь такого уровня равновесия, который на практике не имеет большого значения. Кого волнует, если иногда требуется сорок ветвей, чтобы добраться до самого дальнего листа в миллионном узле несовершенно сбалансированного дерева, когда теоретически оно может занять всего двадцать в идеально сбалансированном дереве? Дело в том, что на это никогда не уходит миллион. Получить от худшего случая миллион вниз до худшего случая сорок, как правило, достаточно хорошо; вы не должны идти все пути к оптимальному делу.

Вы говорите, что вам явно нужен весь полученный пакет, прежде чем вы сможете отправить его? Что ж,это не значит, что вы должны хранить все это в памяти, не так ли? Возможно ли изменение архитектуры, чтобы сохранить полученные пакеты во внешнем хранилище (возможно, ram-disk или DB, если даже SSD слишком медленный) и затем направить их непосредственно получателю, не загружая их полностью в память?

Если вы получаете исключения OutOfMemory, очевидно, что-то все еще содержит ссылку на эти объекты. Вы можете использовать такой инструмент, как jhat , чтобы узнать, где находятся эти ссылки.

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

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

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

Чтобы лучше понять, что такое лучшие практики, прочтите Эффективная Java, глава 2 - это о "Создании и уничтожении объектов"

Если у вас есть индекс SomenumberFiflefield , то это утверждение будет либо просто разбито на два сканирования диапазона в индексе или обрабатывается как сканирование таблицы / сканирование индекса фильтр.

Последнее более вероятно, при условии, что большинство ваших строк имеют somenumberfield = 999999

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

время сравнения фильтра незначительно по сравнению с временем, необходимым для получения страниц данных.

Когда JVM находится на краю outofmemoryError , он будет работать .

Так что звонит System.gc () Самостоятельно, не собираюсь решить проблему. Проблема должна быть исправлена ​​где-то еще. Существуют в основном два способа:

1. написать эффективный код памяти и / или исправить утечки памяти в вашем коде.
2. Дайте JVM больше памяти.

Использование java Profiler может дать много информации о использовании памяти и потенциальной утечки памяти.

Обновление : Согласно вашему редактированию с дополнительной информацией о коде, вызывающем эту проблему, посмотрите на Ответ Джеффа Ридзи в этой теме , который предлагает использовать objectInputStream # ReadUnshared () и ObjectOutputStream # TrueUnshared () вместо этого. (Связанные) Javadocs также объясняет это довольно хорошо.

Объектные потоки содержат ссылки на каждый записанный/читаемый из них объект. Это связано с тем, что протокол сериализации допускает обратные ссылки на объекты, которые появились ранее в потоке. Возможно, вы все же сможете использовать эту конструкцию, но вместо writeObject/readObject используйте writeUnshared/readUnshared. Я думаю, но не уверен, что это помешает потокам сохранять ссылки на объект.

Как говорит Коуэн, метод reset() также используется здесь. Самое безопасное, что можно сделать, это, вероятно, использовать writeUnshared сразу после reset() при записи на ваш ObjectOutputStreams