Почему я получаю OutOfMemoryError при вставке 50 000 объектов в HashMap?

Вы можете увеличить максимальный размер кучи, передав -Xmx128m (где 128 - количество мегабайт) в java. Я не могу вспомнить размер по умолчанию, но мне кажется, что это было что-то довольно маленькое.

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

// Get current size of heap in bytes
long heapSize = Runtime.getRuntime().totalMemory();

// Get maximum size of heap in bytes. The heap cannot grow beyond this size.
// Any attempt will result in an OutOfMemoryException.
long heapMaxSize = Runtime.getRuntime().maxMemory();

// Get amount of free memory within the heap in bytes. This size will increase
// after garbage collection and decrease as new objects are created.
long heapFreeSize = Runtime.getRuntime().freeMemory();

(Пример из Альманах Java-разработчиков)

Это также частично адресовано в Часто задаваемые вопросы о виртуальной машине Java HotSpot и в Страница настройки Java 6 GC.

Также можете взглянуть на это:

http://java.sun.com/docs/hotspot/gc/

Вероятно, вам нужно установить флаг -Xmx512m или какое-то большее число при запуске java. Я думаю, что по умолчанию 64 МБ.

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

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

По умолчанию JVM использует ограниченное пространство кучи. Предел зависит от реализации JVM, и неясно, какую JVM вы используете. В ОС, отличных от Windows, 32-разрядная JVM Sun на машине с 2 ГБ или более будет использовать максимальный размер кучи по умолчанию 1/4 физической памяти или 512 МБ в вашем случае. Однако по умолчанию для JVM в «клиентском» режиме максимальный размер кучи составляет всего 64 Мбайт, что может быть тем, с чем вы столкнулись. JVM других производителей могут выбирать другие значения по умолчанию.

Конечно, вы можете явно указать ограничение кучи с помощью параметра -Xmx<NN>m для java, где <NN> - это количество мегабайт для кучи.

Приблизительно, ваша хеш-таблица должна использовать только около 16 Мбайт, поэтому в куче должны быть другие большие объекты. Если бы вы могли использовать ключ Comparable в TreeMap, это сэкономило бы немного памяти.

Подробнее см. «Эргономика в 5.0 JVM».

Еще одна вещь, которую стоит попробовать, если вы заранее знаете количество объектов, - это использовать конструктор HashMap (int capacity, double loadfactor) вместо конструктора no-arg по умолчанию, который использует значения по умолчанию (16,0.75). Если количество элементов в вашем HashMap превышает (capacity * loadfactor), тогда размер базового массива в HashMap будет изменен до следующей степени 2, и таблица будет перефразирована. Для этого массива также требуется непрерывная область памяти, поэтому, например, если вы удваиваете массив размером 32768 до 65536, вам понадобится фрагмент памяти размером 256 КБ. Чтобы избежать лишних затрат на выделение и повторное хеширование, просто используйте с самого начала хеш-таблицу большего размера. Это также уменьшит вероятность того, что у вас не будет непрерывной области памяти, достаточно большой, чтобы поместиться на карте.

Реализации обычно поддерживаются массивами. Массивы - это блоки памяти фиксированного размера. Реализация хэш-карты начинается с хранения данных в одном из этих массивов с заданной емкостью, скажем, 100 объектов.

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

Обычно причиной такой проблемы является код, увеличивающий емкость карты путем копирования элементов в больший массив. Существуют «глупые» и умные реализации, в которых используется коэффициент роста или загрузки, определяющий размер нового массива на основе размера старого массива. Некоторые реализации скрывают эти параметры, а некоторые - нет, поэтому вы не всегда можете их установить. Проблема в том, что, когда вы не можете установить его, он выбирает некоторый коэффициент загрузки по умолчанию, например 2. Таким образом, новый массив вдвое больше старого. Теперь ваша предположительно 50k карта имеет резервный массив 100k.

Посмотрите, сможете ли вы снизить коэффициент загрузки до 0,25 или около того. это вызывает больше конфликтов хэш-карты, что снижает производительность, но вы сталкиваетесь с узким местом памяти, и это необходимо.

Используйте этот конструктор:

(http://java.sun.com/javase/6/docs/api/java/util/HashMap.html#HashMap(int, с плавающей запятой))

Объем кучи Java ограничен по умолчанию, но это все еще звучит чрезмерно (хотя насколько велики ваши 50000 сегментов?)

Я подозреваю, что у вас есть другая проблема, например, массивы в наборе становятся слишком большими, потому что все назначается в один и тот же «слот» (также, конечно, влияет на производительность). Однако это кажется маловероятным, если ваши очки распределены равномерно.

Мне интересно, почему вы используете HashMap, а не TreeMap? Несмотря на то, что точки двумерны, вы можете разделить их на подклассы с помощью функции сравнения, а затем выполнить поиск log (n).

Некоторые люди предлагают изменить параметры HashMap, чтобы ужесточить требования к памяти. Я бы посоветовал измерять вместо того, чтобы угадывать; это может быть что-то еще, вызывающее ошибку OOME. В частности, я бы предложил использовать либо Профилировщик NetBeans, либо VisualVM (который поставляется с Java 6, но я вижу, что вы застряли с Java 5).

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