Как необработанные исключения влияют на JVM?

Question

Мой проект получил около 20 необработанных исключений, неважно почему, и мне было интересно, как они влияют на JVM?Это не терпит крах, но мне все еще интересно, каковы их следы в JVM.Куда они идут?

Answer 1

Все исключения обрабатываются либо вашим кодом, либо «обработчиком необработанных исключений». Единственный способ избежать обработки исключения - это возврат из блока finally или выход из программы.

Необработанное исключение / ошибкаприведет к концу запущенного потока.Тем не менее, если это приемлемый ответ, нет причин, по которым это должно расстраивать ваше приложение.

Одна проблема с исключениями состоит в том, что они имеют некоторые накладные расходы, и если вы создаете их слишком много, это может снизить производительность.

Answer 2

У каждого потока есть нечто, называемое UncaughtExceptionHandler . Всякий раз, когда у вас есть случайное исключение, которое никто не перехватывает, вызывается метод UncaughtExceptionHandler uncaughtException потока. Обычно поток завершается при необработанных исключениях.

Я не думаю, что о производительности для необработанных исключений и обработанных исключений есть много, так как единственной серьезной проблемой производительности, за исключением исключения, является заполнение трассировки стека, которая выполняется во время создания самого исключения (конструктор заканчивается вызов fillInStackTrace () ). Если необработанные исключения означают меньшие блоки try-catch (если это так в вашем случае), то вы можете думать с точки зрения, что try-catch как правило дороги.

Answer 3

JVM совершенно не зависит от необъяснимых исключений. Это обычно убивает поток, хотя и не всегда. В случае EventQueue одно событие завершается ненормально, но события продолжают поступать.

Неучитанные исключения не годятся. Если вы получаете 20 необработанных исключений и у вас нет других проблем, вы можете улучшить производительность своей программы, избавившись от кода и потоков, которые их производят; они, очевидно, не делают ничего, что нужно делать (по крайней мере, из строки, которая вызвала исключение).

Самая большая проблема, с которой я столкнулся, с неисследованными исключениями, заключается в том, что они дестабилизируют программу. Одно поле получает неправильное число, более поздние вычисления (в других потоках или событиях) используют это плохое число, и оттуда дела идут вниз. Иногда программа восстанавливается - что хорошо в демоверсии - а иногда она медленно становится все хуже и хуже - что в демо хуже, чем ненормальное завершение. Часто след стека не виден. Даже когда это должно быть очевидно, я знаю, что тестировщики и пользователи не могли видеть это, пока они не позвонили мне, я выяснил, что должно было произойти, и сказал им искать это. («О, да, здесь она находится под моей игрой в пасьянс. Извините, если я сказал это определенно имел не отображал какие-либо сообщения.« NullPointerException ». *

Незаметные исключения обычно выглядят как незначительная ошибка в вычислениях. Я потратил много времени на проверку опечаток в моем коде. Только когда я убедился в том, что программа никак не может сделать то, что она сделала, я понял, что это непонятное исключение. Кроме того, эти ошибки могут быть очень сложно воспроизвести; программа становится сумасшедшей, но в другом месте и по-разному. (Оставьте вывод вашей системы на top вашей пасьянса, и все ваши проблемы с отладкой исчезнут.)

В Java 1.5 появился новый метод Thread.setDefaultUncaughtExceptionHandler, который позволяет вам убить программу или иным образом справиться с этой угрозой. Использование большого количества блоков try / catch может дать вам лучший контроль (если вы этого хотите) и было единственным (я знал) способом справиться с этим до 1.5.

Answer 4

Любое неперехваченное Throwable ( Исключение времени выполнения или Ошибка ) уничтожит нить, в которую был брошен бросаемый объект. Когда нет потоков (не демонов), процесс JVM завершится.

Если вы запустите свой код поверх хорошего механизма пула потоков, пул потоков обнаружит, что рабочий поток умер, и создаст новый рабочий поток на его месте. Я лично считаю, что вы не должны ловить Throwable , а вместо этого ловить исключения времени выполнения.