Способы уменьшить отток памяти

Я думаю, сеанс с профилировщиком памяти прольет много света на эту тему. Это дает хороший обзор того, сколько объектов создано, и это иногда показательно.

Я всегда поражаюсь, как много строк генерируется.

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

У Netbeans есть хорошая сборка. Я использовал JProfiler в прошлом. Я думаю, что если вы достаточно долго работаете с eclipse, вы можете получить ту же информацию из инструментов PPTP.

У меня такое ощущение, что вы тратите время и силы, пытаясь оптимизировать то, с чем не стоит заморачиваться.

Я трачу более 5% своего программного времени на замораживание для незначительных GC, и это кажется чрезмерным.

Переверни это. Вы тратите чуть менее 95% времени программы на полезную работу. Или, другими словами, даже если вам удалось оптимизировать сборщик мусора для работы за НУЛЕВОЕ время, лучшее, что вы можете получить, — это улучшение более чем на 5%.

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

Что, вероятно, имеет наибольшее значение, так это время настенных часов для всего пакетного задания. И (примерно) 95% времени, затраченного на работу с конкретными приложениями, — это то, где вы, вероятно, получите большую отдачу от своих усилий по профилированию / целевой оптимизации. Например, смотрели ли вы пакетную обработку обновлений, отправляемых в базу данных?

Итак... 90% моей общей памяти находится в char[] в "oracle.sql.converter.toOracleStringWithReplacement"

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

Было бы очень полезно, если бы вы уточнили свои термины «молодое» и «постоянное» поколение, потому что Java 6 имеет немного другую модель GC: Eden, S0 + S1, Old, Perm.

Вы экспериментировали с различными алгоритмами сборки мусора? Как работают «UseConcMarkSweepGC» или «UseParNewGC».

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

Вы уверены, что у вас нет утечек памяти? В модели «потребитель-производитель», которую вы описываете, редко редко данные должны находиться в старом поколении, потому что эти задания обрабатываются очень быстро, а затем «выбрасываются», или ваша очередь работы заполняется?

Вы обязательно должны наблюдать за своей программой с помощью анализатора памяти.

Вам нужно профилировать ваше приложение, чтобы увидеть, что именно происходит. И я также попытался бы сначала использовать функцию эргономики JVM, как рекомендуется:

2. Эргономика

Функция, называемая здесь эргономикой, была введена в J2SE 5.0. Цель эргономики — обеспечить хорошую производительность с минимальной настройкой параметров командной строки или без нее путем выбора

• уборщик мусора,
• размер кучи,
• и компилятор времени выполнения

при запуске JVM вместо использования фиксированных значений по умолчанию. Этот выбор предполагает, что класс машины, на которой запускается приложение, указывает на характеристики приложения (т. е. большие приложения запускаются на больших машинах). В дополнение к этим выделениям есть упрощенный способ настройки сборки мусора. С помощью параллельного коллектора пользователь может указать максимальное время паузы и желаемую пропускную способность для приложения. Это отличается от указания размера кучи, необходимого для хорошей производительности. Это предназначено для повышения производительности больших приложений, использующих большие кучи. Более общая эргономика описана в документе под названием «Эргономика в виртуальной машине Java 5.0». Рекомендуется опробовать эргономику, представленную в этом последнем документе, прежде чем использовать более подробные элементы управления, описанные в этом документе.

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

См. более подробный раздел об эргономике в сборка мусора виртуальной машины Java SE 6 HotSpot[tm] Руководство по настройке.

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

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

public class MemorySavingUtils {

    ConcurrentHashMap<String, String> knownStrings = new ConcurrentHashMap<String, String>();

    public String unique(String s) {
        return knownStrings.putIfAbsent(s, s);
    }

    public void clear() {
        knownStrings.clear();
    }
}

С компилятором Sun Hotspot родной String.intern() очень медленный для большого количества строк, поэтому я предлагаю создать собственный встроенный модуль String.

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

Прочитайте строку из файла, сохраните как строку и поместите в список. Когда в списке будет 1000 таких строк, поместите их в очередь для чтения рабочими потоками. Упомянутый рабочий поток создает объект домена, отделяет кучу значений от строки, чтобы установить поля (int, long, java.util.Date или String), и передает объект домена вместе со средством записи jdbc spring по умолчанию.

если это ваша программа, почему бы не установить меньший объем памяти, например 256 МБ?

Я предполагаю, что с таким высоким пределом памяти вы должны полностью прочитать файл в память, прежде чем выполнять обработку. Не могли бы вы рассмотреть возможность использования java.io.RandomAccessFile вместо этого?