Если предположить, что проблема в убийце OOM, то он убил ваш процесс в отчаянной попытке заставить функционировать ОС в условиях серьезного кризиса нехватки памяти.
Я бы пришел к выводу, что:
ваша виртуальная машина Java фактически использует более 28 ГБ;т. е. у вас значительное использование памяти без кучи, и
ОС не настроена с достаточным количеством пространства подкачки.
Я бы попытался добавить больше пространства подкачки, чтобы ОС могла в случае необходимости заменить части вашего приложения.
В качестве альтернативы, уменьшите размер кучи JVM.
Обратите внимание, что "-Xmx ..." устанавливает максимальный размер кучи, а не максимальный объем памяти, который может использовать ваша JVM.JVM помещает некоторые вещи вне кучи, включая такие вещи, как память для стеков потоков и отображаемые в память файлы, используемые вашим приложением.
Системный журнал подтверждает, что это убийца OOM на работе.
Каким образом связанный системный журнал говорит об этом?
Там написано:
Nov 15 13:53:49 ip-10-71-94-36 kernel: [3707038.606133] Out of memory: kill process 6368 (run.sh) score 4747288 or a child
Nov 15 13:53:49 ip-10-71-94-36 kernel: [3707038.606146] Killed process 9359 (java)
Консоль говорит, что Java был убит, а не что он вышел.
Правильно.Он был убит убийцей OOM операционной системы.
Если бы ему не хватило памяти, он обычно выдавал исключение OutOfMemory, чего не было.
Вот что бы произошло, если бы вы заполнили кучу Java.
Это не то, что здесь происходит.Фактическая проблема заключается в том, что физической памяти недостаточно для хранения кучи Java.Убийца OOM справляется с этим ...
Я работаю с такой огромной кучей, потому что мне нужно хранить миллионы объектов, каждый из которых требует несколько килобайт оперативной памяти.
К сожалению, вы пытаетесь использовать гораздо больше оперативной памяти, чем доступно в системе.Это вызывает сбой виртуальной памяти, затрагивая всю операционную систему.
Когда система начинает сильно перебивать, убийца OOM (не JVM) определяет ваш процесс Java как причину проблемы.Затем он убивает его (SIGKILL), чтобы защитить остальную часть системы.Если этого не произойдет, есть риск, что вся система полностью заблокируется и ее потребуется перезагрузить.
Наконец, вы сказали:
Моя коробкаимеет 35,84 ГБ ОЗУ ...
Это довольно странное значение.32 ГиБ составляют 34 359 738 368 байт или 34,35 ГБ.
Но исходя из этого и наблюдаемого поведения, я подозреваю, что это доступная виртуальная память, а не физическая ОЗУ.В качестве альтернативы вашей «коробкой» может быть виртуальная машина с включенным избыточным объемом ОЗУ на уровне гипервизора.