Является ли этот пример кода просто простым или здесь есть причина использовать прерывание ()

Поток здесь просто умирает после вызова interrupt(), верно?

Исполняющий поток не завершится после прерывания, вы думаете Thread#stop. Поток потока может продолжать работать даже после завершения выполнения. Runnable — это просто задача, которую выполняет поток.

После завершения этой задачи важно ли потоку знать, что произошло прерывание? Что, если потоку нужно ответить на какой-то другой запрос на отмену, и это делает другой поток?

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

В Java вам нужно обрабатывать прерывание потока. Для этого необходим опрос Thread.isInterrupted(). Когда ваш код является частью Runnable, вам необходимо установить флаг прерывания потока в случае InterruptedException, чтобы последующие задачи, выполняемые этим потоком (код выше стека вызовов), могли опрашивать Thread.isInterrupted() и соответствующим образом обрабатывать прерывание. Это также дает потоку возможность завершиться без ошибок, вместо того, чтобы сразу его убить. Это то, что делает Thread.stop().

Object.wait и Thread.sleep — это два примера, которые сначала проверяют флаг и выдают InterruptedException, если он установлен.

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

Если вы передадите Runnable в поток, то, очевидно, ничто не будет читать прерывание, восстановленное как последнее, что сделал Runnable. Когда поток завершается, значение флага прерывания становится недоступным.

Если Runnable передается в Executor, то Executor отвечает за установку флага прерывания в своих потоках. Также Исполнитель должен знать лучше, чем полагаться на задачи для восстановления флага прерывания. Поэтому обычно не имеет значения, если задача Executor не восстанавливает состояние прерывания.

Но могут быть крайние случаи; Runnable может потребоваться для запуска текущим потоком, а не для передачи другому потоку. Например, если вы отправляете задачу исполнителю, у которого есть политика отклонения, которая заставляет задачу выполняться в вызывающем потоке, то прерывания вызывающего потока могут быть потеряны, если он выполняет задачу, отклоненную исполнителем, который не восстановить флаг прерывания.

Было бы лучше иметь возможность изменить конфигурацию исполнителя, не беспокоясь о том, хорошо ли ведут себя задачи для этой конфигурации. Задачи - это дырявые абстракции, и это невозможно в целом, но для этой конкретной проблемы это возможно: пусть ваши задачи восстанавливают флаг прерывания во всех случаях, просто на всякий случай.

Документация по Java определяет эффект Thread.interrupt() как

Если этот поток заблокирован при вызове методов wait(), wait(long) или wait(long, int) класса Object или методов join(), join(long), join(long, int) , sleep(long) или sleep(long, int) этого класса, то его статус прерывания будет очищен, и он получит InterruptedException.

Если этот поток заблокирован в операции ввода-вывода на InterruptibleChannel, тогда канал будет закрыт, статус прерывания потока будет установлен, и поток получит ClosedByInterruptException.

Если этот поток заблокирован в селекторе, тогда будет установлен статус прерывания потока, и он немедленно вернется из операции выбора, возможно, с ненулевым значением, как если бы был вызван метод пробуждения селектора.

Если ни одно из предыдущих условий не выполняется, тогда будет установлен статус прерывания этого потока.

Обратите внимание на последний абзац; по сути, если ваш поток в настоящее время не выполняет одну из упомянутых операций в стиле ожидания, прерывание потока просто устанавливает флаг, но никак иначе не влияет на поток управления. Это справедливо независимо от того, исходит ли вызов из другого потока или из самого потока-жертвы.

Другими словами:

try {
   while (true) {
        queue.take();
    }
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();
}

// When an interrupt is received, the thread resumes
// execution here. It will notice the effect of the
// Thread.currentThread().interrupt() only, if it tries
// to perform any of the mentioned special wait operations
// here.

synchronized (someLockObject) {

    while (!someCondition) {

        // Will immediately terminate with an `InterruptedException`,
        // since we properly restored the interrupt status
        // above.

        someLockObject.wait();
    }
}

Этот метод позволяет всему коду в текущем стеке вызовов распознать прерывание, выполнить необходимую очистку и «упорядоченное» завершение работы. Если вы не восстановите состояние прерывания, то код, следующий за try/catch, может ошибочно предположить, что все в порядке, и что он должен возобновить выполнение в обычном режиме.