Здравствуйте, все.
Встала такая проблема.
Имеется Web-приложение. Периодически, при выполнении юзверем определённого набора действий (составляется сложный запрос к базе, создаётся туча объектов и т.д.), где-то в недрах процедуры, которая это обрабатывает, вылетает java.lang.OutOfMemoryException.
"Где-то в недрах процедуры" - в том смысле, что исключение возбуждается в ней, но сделать с нец ничего нельзя - нет исходников.

Вопрос: если перед вызовом этой процедуры в отдельном потоке запустить System.gc(), как это может отразиться на производительности сервера приложений и какие могут быть побочные эффекты?
Понимаю, что такой способ - это нездорово, но другого ничего на ум не идёт.
Заранее спасибо.

А можно ссылку привести на эту статью?

Насчёт кэша Вы правы - он используется, но без него никак.
Насчёт того, что System.gc() не всегда будет срабатывать - процедура, которая падает с исключением, используется, может, раза 4 в месяц, а то и меньше. Соответственно и System.gc() будет вызываться столько же. Главное, чтобы первый вызов прошёл.
А если под JVM памяти больше выделять - тогда получится, что с ростом базы всё равно придём к исключению.

Кстати, ещё вопрос - насколько System.gc() снижает производительность сервера? (А то может, проще перестартовать сервак, чем изобретать такие извраты :-)

В документации Sun про сборщик мусора сказано, что он автоматически (прозрачно для пользователя) выполняется в отдельном потоке с низким приоритетом.
В JavaDoc про gc() написано, что его вызов "предлагает" JVM приложить усилия для сборки мусора, и после того, как он gc() отработает, считается, что "мусор убран".
Получается, в моём случае память выделяется быстрее, чем её успевает вернуть сборщик мусора. По-любому без gc() не обойтись. Вот только более подробно про его работу я ничего не нашёл.
Теперь вопрос, собственно, сводится к следующему: гарантирует ли gc() начало сборки мусора, и насколько его выполнение загрузит сервер. Вложенный вопрос: если gc() вызвать не в отдельном потоке, сколько он будет выполняться?
Протестировать это не могу, потому как кто ж даст на рабочей проге тестировать...
А если сервер запустить локально на моей машине, то исключения OutOfMemory я могу сутками ждать...

Спасибо за разъяснения по поводу кэша :-)
Но я очень сильно подозреваю, что память жрут мёртвые объекты, на которые уже никто не ссылается (ну специфика там такая, что их много плодится). В этом случае gc() поправит?

А насколько gc() загрузит сервер? Понимаю, что очень абстрактный вопрос, но хоть какие-нибудь оценки?

Всем спасибо :-)
После обкатки решения обязательно сообщу результаты.

Может, кому пригодятся результаты моих изысканий :-)
Покопавшись в доках и попытавшись немного попрограммить :-), выяснил следующее (возможно, это зависит от реализации VM, но это не противоречит докам):

1. Приоритет сборки мусора действительно растёт при уменьшении объёма досупной памяти в куче.
2.
а) Вызов System.gc() запускает сборку мусора ВСЕГДА. При тесте создал 1 объект, у которого в финализаторе печатал в консоль строку. После System.gc() сообщение напечаталось.
б) Можно и не оформлять вызов gc() в отдельном потоке - поток ему и так выделят.

Кстати, г-н wessen по поводу роста кэша был прав со страшной силой :-). Хотя кэш и был сделан на основе WeakHashMap, это не спасало, когда после запроса, который возвращал много данных, пользователь кидался выполнять ту самую зло###чую функцию.
В качестве варианта решения проблем с кэшем в книжке "Горький вкус Java" советуют цеплять к объектам кэша временнЫе метки, а в отдельном потоке мониторить - если возраст объекта больше заданного удалять его из кэша.
В моей же ситуации оказалось проще тупо очищать кэш перед выполнением этой страшной функции.

2 Timm
Возможно. Я сделал приписку в скобках, что сказанное мной может зависеть от VM. Просто у меня происходило так, как описано.
Я не претендую на истину в последней инстанции :-)