Является Thread.interrupt () злом?

Короткая версия:

Известно ли, что это лучшая практика, никогда не позволяющая использовать Thread.interrupt()?

Нет.

Можешь ли ты предоставить доказательство того, почему он сломан / багги, и не должен использоваться для написания робастный многопоточный код?

Обратное верно: он критичен для многопоточного кода.

См. пример Листинга 7.7 в Java Concurrency in Practice.

Более длинная версия:

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

try {
    // Some code that might throw an InterruptedException.  
    // Using sleep as an example
    Thread.sleep(10000);
} catch (InterruptedException ie) {
    System.err.println("Interrupted in our long run.  Stopping.");
    Thread.currentThread().interrupt();
}

Это делает для нас две вещи:

1. Это позволяет избежать поедания исключения из прерывания. Обработчики автоматического исключения в IDE всегда предоставляют что-то вроде ie.printStackTrace(); и комментария "TODO: Что-то полезное нужно сделать здесь!".
2. Восстанавливает статус прерывания, не заставляя проверенное исключение в этом методе. Если сигнатура метода, который вы реализуете, не имеет бросает пункт InterruptedException, то это ваша другая опция для распространения этого прерывистого статуса.

Один из комментаторов предложил использовать исключение без флажка "чтобы заставить поток погибнуть". Это предполагает, что мне заранее известно, что внезапное прерывание нити является правильным поступком. Я не знаю.

Цитирую Брайана Гетца из JCIP на странице перед перечислением, упомянутым выше:

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

Например, представьте, что я сделал это:

} catch (InterruptedException ie) {
    System.err.println("Interrupted in our long run.  Stopping.");
    // The following is very rude.
    throw new RuntimeException("I think the thread should die immediately", ie);
}

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

Например, вот что все остальные в команде должны были бы сделать немедленно:

try {
    callBobsCode();
} catch (RuntimeException e) { // Because Bob is a jerk
    if (e.getCause() instanceOf InterruptedException) {
        // Man, what is that guy's problem?
        interruptCleanlyAndPreserveState();
        // Restoring the interrupt status
        Thread.currentThread().interrupt();
    }
}

Прерывистое состояние более важно, чем любое конкретное Прерывание-перехват . Для конкретного примера почему, смотрите javadoc для Thread.interrupt():

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

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