Есть ли (простой) способ определить, какие объекты удаляет GC?

У меня есть программа на Java, которая создает дюжину массивов длиной примерно 160 миллионов каждый. Массивы содержат примитивы (char, short и float). В моем алгоритме я заметил (с помощью jprofiler), что сборщик мусора работает в моей системе довольно часто (машина с виртуальной машиной Windows в облаке Google, 16 ядер ЦП, 64 ГБ ОЗУ), но я не могу понять, почему сборщик мусора работает так часто и потребляют 80% общей вычислительной мощности процессора.

Поэтому я подумал: если бы я мог выяснить (либо с помощью команд/журналов jvm, либо, предпочтительно, с помощью профилировщика, такого же, как jprofiler), какие именно объекты это был «сбор мусора», у меня был бы шанс понять, что происходит, и либо исправить простой проблема или перепроектирование, основанное на моем лучшем понимании того, что делает Java. (Насколько мне известно, я свел к минимуму создание объектов; хотя я использую много функций параллельной потоковой передачи jdk8, поэтому я не знаю, вызывает ли это как-то проблемы с сборкой мусора.) Есть ли способ определить какие объекты (или какие типы объектов) сборщик мусора пытается собрать в определенное время, чтобы я мог лучше понять, почему сборщик мусора работает так часто и так интенсивно?


person Jonathan Sylvester    schedule 30.07.2018    source источник
comment
Просто чтобы правильно понять: вы не осознавали, что может быть проблема, т.е. не имели проблем с производительностью, пока инструмент профилирования не сказал вам, что GC тратит 80% процессорного времени? Может быть, просто ваше приложение не требует много процессорного времени для себя? Кроме того, вы слишком заморачиваетесь ненужными деталями. Первое, на что следует обратить внимание, это «Сколько памяти кучи было выделено JVM?» и «Какая часть пространства кучи фактически используется JVM? ».   -  person Holger    schedule 31.07.2018
comment
Я заметил, что ЦП не был загружен на 100% (чего я и ожидал), а затем при профилировании я заметил, что сборщик мусора работает довольно быстро. В качестве ответа на ваши другие 2 вопроса я установил -Xmx на 33G, но я заметил, что объем используемого размера (согласно jprofiler) варьировался от 11G до 15G, а зафиксированный размер варьировался от 16G до 25G. Я предполагаю, однако, что нет явного (или, по крайней мере, простого) способа определить, какие объекты (или типы объектов) собирает сборщик мусора, чтобы я мог отследить (потенциальную) проблему?   -  person Jonathan Sylvester    schedule 01.08.2018
comment
Проблема в том, что, в отличие от разговорного термина «сборщик мусора», JVM не собирает мусор, а скорее обходит объекты, которые доступны, а значит, все еще живы. После перемещения этих объектов в новую область памяти весь исходный блок памяти можно считать свободным, не зная, какие старые объекты он содержал ранее. Это означает, что а) мы не можем идентифицировать эти мертвые объекты без дополнительных усилий и б) мы не хотим и не должны их идентифицировать, так как эти старые объекты не предполагают никакой работы с JVM. Имеют значение еще живые объекты, т.е. при почти полной куче   -  person Holger    schedule 01.08.2018
comment
Но поскольку сборка мусора использует ЦП, отсутствие использования ЦП на 100% предполагает, что сборка мусора здесь вообще не является фактором производительности. Наличие даже отдаленно не полной кучи подтверждает это предположение. Судя по всему, в производительности вашего приложения преобладают операции ввода-вывода (или ему не хватает работы/потоков для всех процессоров или оно страдает от блокировок).   -  person Holger    schedule 01.08.2018
comment
@Holger Это отличный, отличный момент ... проверим ....   -  person Jonathan Sylvester    schedule 01.08.2018


Ответы (1)


В JProfiler для этой цели можно использовать запись распределения.

Чтобы отобразить объекты, собранные мусором, в представлении «Записанные объекты», измените селектор живости на панели инструментов на «Объекты, собранные мусором» или «Живые объекты и объекты, собранные мусором». Диалоговое окно параметров дерева вызовов распределения и представлений горячих точек распределения имеет эквивалентный раскрывающийся список.

person Ingo Kegel    schedule 02.08.2018