У меня есть Java-программа, которая работает с (большим) графом. Таким образом, он использует значительный объем пространства кучи (~ 50 ГБ, что составляет около 25% физической памяти на хост-компьютере). В какой-то момент программа (многократно) выбирает один узел из графа и выполняет с ним некоторые вычисления. Для некоторых узлов это вычисление занимает намного больше времени, чем ожидалось (30-60 минут вместо ожидаемых нескольких секунд). Чтобы профилировать эти операции, чтобы выяснить, что занимает так много времени, я создал тестовую программу, которая создает только очень небольшую часть большого графа, а затем выполняет ту же операцию на одном из узлов, для вычисления которого потребовалось очень много времени. оригинальная программа. Таким образом, тестовая программа, очевидно, использует очень мало места в куче по сравнению с исходной программой.

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

Итак, мои вопросы: что еще может быть, что объясняет такую ​​огромную разницу во времени? Я не знаю много о том, как Java внутренне организует кучу. Есть ли что-то, что занимает значительно больше времени для большой кучи с большим количеством живых объектов? Может ли быть так, что при такой настройке выделение объектов занимает гораздо больше времени, потому что требуется больше времени, чтобы найти подходящее место в куче? Или же виртуальная машина выполняет внутреннюю реорганизацию кучи, которая может занять много времени (очевидно, помимо сборки мусора).

Я использую Oracle JDK 1.7, если это имеет какое-либо значение.