Этот абзац взят из спецификаций jvm:
A Java Virtual Machine may permit a small but bounded amount of execution to occur before an asynchronous exception is thrown. This delay is permitted to allow optimized code to detect and throw these exceptions at points where it is practical to handle them while obeying the semantics of the Java programming language.
У меня проблемы с пониманием второй части, то есть причины, по которой jvm позволяет потоку работать в течение некоторого времени, прежде чем stop его остановит.




Вспомним определение асинхронных исключений:
Most exceptions occur synchronously as a result of an action by the thread in which they occur. An asynchronous exception, by contrast, can potentially occur at any point in the execution of a program.
Поэтому, когда в результате действия возникает исключение, вы просто знаете, что, например, при выполнении инструкции бежать исключение произойдет безоговорочно, при выполнении целочисленного деления делитель может быть равен нулю или при доступе к члену объекта ссылка может быть null. Это ограниченный набор действий, и оптимизатор изо всех сил пытается сократить его еще больше, используя анализ кода, чтобы доказать, что делитель не может быть равен нулю, соответственно. ссылка не может быть null в определенных местах кода. В противном случае он должен вставить проверку на наличие ошибочного условия, чтобы сгенерировать и при необходимости обработать исключение. Но только в этих конкретных местах кода.
Напротив, асинхронное исключение может возникнуть в месте кода каждый и может потребовать явной проверки типа «вызвал ли другой поток stop в моем потоке с момента последней проверки». Вы не хотите, чтобы такие проверки выполнялись после каждой инструкции, поскольку это означало бы, что на такие проверки будет потрачено больше времени, чем на фактическую работу.
Следовательно, разрешено выполнять более одной инструкции до следующей проверки, если гарантируется, что время достижения следующей проверки будет ограничено, поэтому это исключит обратные переходы с непредсказуемым количеством итераций без проверки. . Также имейте в виду, что в оптимизированном коде могут быть незафиксированные действия, например значения измененных переменных хранятся в регистрах ЦП. Таким образом, даже после обнаружения того, что произошло асинхронное исключение, код должен зафиксировать эти ожидающие действия, например запишите эти значения обратно в общую память, прежде чем оставить код реагировать на исключение.