Это может быть странный вопрос, но блоки «try-catch» добавляют к памяти в серверной среде больше, чем просто запуск определенного блока кода. Например, если я выполняю трассировку стека печати, поддерживает ли JVM дополнительную информацию. Или больше информации сохраняется в куче?Обработка исключений и память
try {
... do something()
} catch(Exception e) {
e.printStackTrace();
}
... do something()
Исключением будет ссылка на трассировку стека. printStackTrace будет выделять больше памяти, поскольку она форматирует трассировку стека во что-то красивое.
Пытаться поймать блок, скорее всего, приведет к значительной степени статическим кодом/сегмента данных, но не во время выполнения распределения памяти
Трассировка стека строится, когда создается исключение. Печать трассировки стека не требует больших затрат памяти, чем печать чего-либо еще.
Блок try/catch может иметь некоторые служебные накладные расходы, но не в виде повышенных требований к памяти.
Важным здесь, как только исключение переменной «е» больше не достижимы (то есть, из области) он становится доступным для сбора памяти.
По большей части, не беспокойтесь о памяти/производительности, когда происходят исключения. Если у вас есть исключение, являющееся общим кодовым кодом, то это означает, что вы злоупотребляете исключениями.
Если ваш вопрос больше для академических целей, то я не знаю, в полной мере, что происходит там с точки зрения кучи/памяти. Однако Джошуа Блох в «Эффективной Java» упоминает, что блоки catch блока try catch часто относительно неоптимизированы большинством реализаций JVM.
Технически ответ на ваш вопрос, вероятно, нет. Существует множество причин избегать бросать исключения, когда это возможно, но память на самом деле не вызывает беспокойства.
Настоящая причина только бросать Исключения для действительно исключительных условий - это SLOW. Генерация исключения включает тщательное изучение стека. Это совсем не быстрая операция. Если вы делаете это как часть регулярного потока исполнения, это заметно повлияет на вашу скорость. Я однажды написал систему ведения журнала, которая, по моему мнению, была очень умной, потому что она автоматически выяснила, какой класс вызвал ее, генерируя исключение и рассматривая стек таким образом. В конце концов мне пришлось вернуться и принять участие, потому что это заметно замедлило все остальное.
Хотя я не имел прямого отношения к потреблению памяти, в течение некоторого времени здесь обсуждался вопрос: How slow are the Java exceptions? На мой взгляд, стоит посмотреть.
У меня также было это link в моих закладках. Насколько я могу вспомнить, он дал пример ускорения, возможного, когда генерация трассировки стека пропускается при генерации исключений, но теперь сайт кажется опущенным.