Зависание при создании большого числа объектов

Это GC.

небось объектами являются умные пикселы

сделай heap dump и посомотри что у тебя там за проблемы в visualvm Сюда!

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

Спасибо. -Xms1024M -Xmx1024M не спасло... Больше ОЗУ нет... Буду пробовать где есть оперативки побольше....

-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails

ты эти 20 миллионов объектов хранишь или таки выбрасываешь после использования? если первое, то действительно нужно либо больше памяти, либо начать её экономить
если второе, то нужно понимать, что сборщик мусора в джаве работает поколениями, и наилучший результат получается, если как можно меньше объектов перетекают из молодого поколения в старое, т.е. нужно как минимум ещё выставлять параметр Xmn. А ещё в джаве несколько сборщиков мусора и при запуске можно выбирать, который из них надо использовать.

Вообще на 1 гигабайте памяти проблем с GC паузами обычно вроде нет. Пляски вокруг них начинаются когда куча хотя бы 10 ГБ.

Да. Необходимо их хранить все время работы и они должны быть все доступны. Спасибо. Буду дальше думать...

ну тогда либо больше памяти добавить, либо начать внедрять какие-нибудь flyweight-ы для экономии памяти.
Хотя маловероятно, что на 1 ГБ тебе её хватит - даже на простой массив со 20 миллионами объектов нужно 80 МБ памяти, и это без учета размера самих объектов.

Есть ещё вариант, что ты объекты хранишь в каком-нибудь ArrayList/HashMap, который в определенный момент хочет увеличить свой размер в 1.5-2 раза (т.е. ему нужен непрерывный кусок памяти в сотню мегабайт), что приводит к вызову full GC. В таком случае может помочь заранее задать его размер (если ты знаешь сколько будет объектов и они должны влезать в память).

GC как раз чувствителен не к количеству мертвых, а к количеству живых объектов (у тебя граф большой): http://www.dynatrace.com/en/javabook/how-garbage-collection-works.html. Прицепись профайлером или посмотри дамп с помощью MAT (https://eclipse.org/mat/). Но очевидно, что раз ты там постоянно клонируешь инты и все это происходит в young space, то мелкий сборщик дергается не по теме. Посмотри еще на опции, которые определяют, по какому проценту занимаемого участка хипа триггерится GC.

Да, когда будешь профайлером цепляться, будет еще тормознее - это ожидаемо.

Спасибо всем! Точно! Там используется все время заполняющаяся мапа и я точно могу сказать каких размеров она должна быть в итоге. Копаю дальше...

Тогда, если есть возможность разместить это дело в direct NIO-буфере в виде мешанины из байт и эффективно работать с данными в такой форме, GC не будет вмешиваться.

HashMap в Java выделяет для себя память с запасом - по дефолту когда таблица заполняется на 75%, создаётся новая в два раза больше и ссылки на данные копируются туда. В итоге если памяти в притык, то может быть ой.

Тьфу, не туда ответил.

Читайте про настройку GC

http://it-ebooks.info/book/854/

http://www.booksgid.com/programmer/42539-java.-novoe-pokolenie-razrabotki.html

(Глава 6)

Ну, а про то, как НЕ пейсать висючие программы, то это курить «Горький вкус Java», однозначно -

http://www.manning.com/tate/

Ясно. Спасибо. Да, виноват GC. Программа страшно «висючая», такое громадное число объектов создается и используется все время работы программы и никуда не деться... Еще там есть графы, алгоритмы на них (имел проблемы с java.lang.StackOverflowError, -Xss спас.). Добился приемлемого результата настройкой параметров и небольшой модификацией кода (теперь срабатывание FullGC не доставляет такой боли). Вот такая жава... Всем спасибо.