Кто называет прерывание Потока Java () методом, если я не?
Я считал и перечитал Параллелизм Java на практике, я считал несколько потоков здесь на предмете, я прочитал статью IBM, Имеющую дело с InterruptedException и все же существует что-то, что я просто не схватываю, который я думаю, может быть разломан на два вопроса:
Если я никогда не прерываю другие потоки сам, что может инициировать InterruptedException?
Если я никогда не прерываю другие потоки сам с помощью прерывания () (скажите, потому что я использую другие средства отменить мои рабочие потоки, как отравленные пилюли и в то время как (! отмененный), разрабатывают цикл [как оба объясненные в JCIP]), что затем имеет в виду InterruptedException? Что я, как предполагается, делаю после ловли той? Завершить работу моего приложения?
5 ответов
Механизм прерывания потока является предпочтительным способом заставить (взаимодействующий) поток ответить на запрос о прекращении того, что он делает. Любой поток (включая сам поток, я думаю) может вызвать interrupt() на потоке.
На практике обычные случаи использования interrupt() связаны с тем, что какой-то фреймворк или менеджер говорит какому-то рабочему потоку остановить то, что он делает. Если рабочий поток "осведомлен о прерываниях", он заметит, что его прервали, через исключение или периодически проверяя свой флаг прерывания. Заметив, что его прервали, хорошо воспитанный поток оставит свои дела и завершит работу.
Если исходить из приведенного выше случая, то ваш код, скорее всего, будет прерван, если он выполняется в рамках Java-фреймворка или из какого-то рабочего потока. И когда он будет прерван, ваш код должен оставить то, что он делает, и привести себя к завершению наиболее подходящим способом. В зависимости от того, как был вызван ваш код, это может быть сделано путем возврата или выброса какого-либо соответствующего исключения. Но, вероятно, не следует вызывать System.exit(). (Ваше приложение не обязательно знает, почему оно было прервано, и уж точно не знает, есть ли другие потоки, которые должны быть прерваны фреймворком).
С другой стороны, если ваш код не предназначен для выполнения под контролем какого-либо фреймворка, вы можете утверждать, что InterruptedException является неожиданным исключением, т.е. ошибкой. В этом случае вы должны обращаться с исключением так же, как и с другими ошибками; например, обернуть его в непроверенное исключение, поймать и зарегистрировать его в том же месте, где вы работаете с другими неожиданными непроверенными исключениями. (В качестве альтернативы, ваше приложение может просто игнорировать прерывание и продолжать делать то, что оно делало).
1) Если я сам никогда не прерываю другие потоки, что может вызвать InterruptedException?
Один пример - если ваши Runnable объекты выполняются с помощью ExecutorService и shutdownNow() вызывается на сервисе. И теоретически, любой сторонний пул потоков или фреймворк управления потоками может законно сделать что-то подобное.
2) Если я сам никогда не прерываю другие потоки с помощью interrupt()... что тогда означает
InterruptedException? Что я должен делать, поймав его? Выключить приложение?
Вам нужно проанализировать кодовую базу, чтобы выяснить, что и почему вызывает interrupt(). Выяснив это, вы сможете понять, что должна делать ваша часть приложения.
Пока вы не узнаете, почему происходит InterruptedException, я бы посоветовал рассматривать это как жесткую ошибку; например, распечатать трассировку стека в файл журнала и закрыть приложение. (Очевидно, что это не всегда правильный ответ... но суть в том, что это "ошибка", и ее нужно довести до сведения разработчика/сопровождающего.)
3) Как узнать, кто/что вызывает
interrupt()?
На это нет хорошего ответа. Лучшее, что я могу предложить, это установить точку останова на Thread.interrupt() и посмотреть на стек вызовов.
Если вы решите интегрировать свой код с другими библиотеками, они могут вызвать прерывание () в вашем коде. например Если вы решите в будущем, чтобы выполнить свой код в исполнении ExecutorService , то это может принудительно выключить через прерывание [) .
Чтобы кратко поставить его, я бы рассмотрел не только там, где работает ваш код , но в каком контексте он может работать в будущем. например Собираетесь ли вы поставить его в библиотеку? Контейнер ? Как другие люди используют это? Вы собираетесь повторно использовать это?
Проблема с вопросом «I». «Я» обычно относится к одному экземпляру класса. Под этим я подразумеваю, что какая-либо конкретная часть низкоуровневого кода (класс) не должна опираться на реализацию всей системы. Сказав, что вы делаете некоторые «архитектурные» решения (например, какую платформу работать).
Возможные неожиданные прерывания, исходящие из JRE, отменяются задач в java.util.concurrent и отключение апплетов.
Обработка прерываний потоков обычно записывается неправильно. Поэтому я предлагаю архитектурное решение избежать причинения прерываний, где это возможно. Однако прерывания обработки кода всегда должны быть правильно написаны. Не может принять прерывания из платформы сейчас.
Как уже упоминалось, другая библиотека может прервать свои потоки. Даже если в библиотеке нет явного доступа к потокам из вашего кода, они все равно могут получить список потоков и прерывать их таким образом со следующим способом .
В InterruptedException сказано, что рутина может быть прервана, но не обязательно, что она будет прервана.
Если вы не ожидаете прерывания, то вам следует относиться к нему так же, как и к любому другому непредвиденному исключению. Если оно находится в критической секции, где неожиданное исключение может иметь чудовищные последствия, то, возможно, лучше всего попытаться очистить ресурсы и изящно завершить работу (потому что получение сигналов прерывания, что ваше хорошо спроектированное приложение, которое не полагается на прерывания, используется таким образом, что оно не было спроектировано, и поэтому должно быть что-то не так). В качестве альтернативы, если рассматриваемый код является чем-то некритичным или тривиальным, Вы можете захотеть проигнорировать (или записать в журнал) прерывание и продолжить работу.