В дополнение ко всем остальным я должен сказать, что даже если вы сможете воспроизвести ошибку OutOfMemory и выяснить, где она произошла, вы, вероятно, не нашли ничего, что стоит знать.
Проблема в том, что OOM возникает, когда распределение не может быть выполнено. Однако реальная проблема заключается не в этом распределении, а в том, что другие выделения в других частях кода не были отменены (отменены ссылки и сборщик мусора). Неудачное распределение здесь может не иметь никакого отношения к источнику проблемы (без каламбура).
Эта проблема больше в вашем случае, так как могут пройти недели, прежде чем начнутся проблемы, предлагая либо редко используемое приложение, либо ненормальный путь к коду, либо относительно ОГРОМНЫЙ объем памяти по сравнению с тем, что было бы необходимо, если бы код был OK.
Возможно, было бы неплохо спросить, почему этот объем памяти настроен для JBoss, а не что-то другое. Если это рекомендовано поставщиком, чем, возможно, они уже знают об утечке и требуют, чтобы это смягчило последствия ошибки.
Для такого рода ошибок действительно полезно иметь представление о том, в каком пути кода возникает проблема, чтобы вы могли проводить целевые тесты. И протестируйте с помощью профилировщика, чтобы вы могли видеть во время выполнения, какие объекты (списки, карты и т. Д.) Растут без сжатия.
Это дало бы вам возможность декомпилировать правильные классы и посмотреть, что с ними не так. (Закрытие или очистка в блоке try, а не в блоке finally).
В любом случае, удачи. Я думаю, что предпочел бы найти иголку в стоге сена. Когда вы найдете иглу, по крайней мере, знаете, вы нашли ее:)