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

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

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

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

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

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

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

См. более подробный раздел об Эргономике в руководстве Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning.

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

Есть ли у вас много объектов, которые представляют одно и то же значение? Если да, объедините эти дублирующиеся объекты с помощью простого 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 interner.

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

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

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

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

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

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

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

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

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

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

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

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

Экспериментировали ли вы с разными алгоритмы сборки мусора? Как работает UseConcMarkSweepGC или UseParNewGC.

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

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

программа с анализатором памяти.