Java. Остановись задача

Мне кажется, что если поток завис в managed-коде, то при вызове stop() ничего фатального не произойдет. Хотя зависание в managed-коде это грубая ошибка программы, и в этом месте лучше бы её исправить как-то иначе. А вот если поток передал управление операционной системе и вызов завис в unmanaged-коде, то stop() может привести к краху приложения. В дотнете имеются схожие проблемы, и там вызов Thread.Abort не работает для потоков, выполняющих в момент аборта нативный код, поскольку генерация ThreadAbortException производится только в контексте управляемого кода, и если поток зависнет в нативном коде, его можно будет прибить только вызовом нативной функции Win32, что очень небезопасно. Думаю, в java все устроено примерно так же.

А такой вариант не катит?

private boolean stopped = false;

public void run() {
while (!stoped) {
// code here
}
}

public void stop () {
stopped = true;
}

1) Как вы определите что поток именно «завис» а не выполняет полезную работу? О проблеме остановки машины Тьюринга слышали? Я скажу вам — никак не попределишь. Это фундаметальная проблема которая неразрешима.

2) Никто не пишет jVM — все пишут JVM.

3) Вы явно путаете понятия виртуальной машины и библиотеки классов (Java Class Library/JDK). Говорить, что у JVM нет метода остановки потока — абсурд. Сказали бы уже тогда, что нет инструкции :)

Может быть, метод Thread.stop() не так уж опасен?

Хм. Это сложный вопрос. Что такое «опасен»? Зависший тред сразу показывает что что-то явно не так с приложением. А если тред убить — то ничего подобного не видно: ошибки могут проявляться не тут, не сейчас, и/или не всегда, и ловить их будет оочень весело. Собственно, все эти причины описаны в тех же жавадоках, как и методы относительно правильных решений этой проблемы: docs.oracle.com/javase/7/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html

Подобная ситуация с потоками в Python: там поток даже на паузу поставить нельзя.

Вообще, я бы делал так:
1. Если каким-то образом удалось определить, что один из потоков «подвис», прибиваем всё приложение. В общем случае, как уже было сказано выше, нельзя определить, есть ли зависший поток, так что, может быть, спасёт какая-нибудь эвристика.
2. Чтобы приложение всё же продолжало работать дальше, делаем guard-процесс.

Чаще всего приложение — это какой-нибудь сервер, в котором потоки обслуживают входящие запросы. В этом случае совсем хорошо было бы сделать так. Рабочий процесс может с guard-процессом общаться каким-нибудь средством IPC (те же сокеты, например). Если рабочий процесс обнаруживает внутри себя зависший поток, он предпринимает следующие действия:
1. Отдаёт guard-процессу запустить и проинициализировать новый процесс, но пока не слушать порт (он ведь слушается рабочим процессом).
2. Освобождает порт и закрывает все соединения.
3. Отдаёт guard-процессу команду о том, что новый процесс может отныне слушать порт.
4. Рабочий процесс прибивает себя.
Так снижается время простоя сервера. Правда, получится, что одновременно будет запущено 3 процесса (из них 2 — рабочих), причём новый рабочий процесс вынужден будет выполнять, возможно дорогую, инициализацию в то время, пока старый рабочий процесс отъедает много ресурсов на зависшем потоке.

Сложно? А что хотели? Thread.stop() действительно небезопасен. Ведь все блокировки слетают и приложение остаётся в неконсистентном состоянии. Дальшейшее его повидение может быть непредсказуемым.

А плагины вот так просто тоже не ставятся на продуктивный сервер. Они должны быть «из доверенных источников». Да и вообще, что значит плагин для сервера? Кто будет делать запросы к этому плагину? Тогда нужно, чтобы и клиент знал про этот плагин и умел им пользоваться.

Язык Java создавался так, чтобы побудить программиста писать максимально безопасный код. Поэтому и были объявлены depricated всякие потенциально опасные операции типа stop(), чтобы заставить программиста более тщательно работать с потоками, а не надеятся на мухобойную stop(). Т.е. вопрос не в JCF, а в архитектуре самого языка. Вряд ли в этом будут какие-то изменения.

Добавлю свои 5 копеек про Андроид:

метод Thread#stop в виртульной машине dalvik не поддерживается вообще. Я задавал вопрос на stackoverflow, но никакого толкового ответа не получил (предложили просто убить приложение) и использовал следующее "грязное" решение:

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

Очевидные минусы: работающая нить тратит системные ресурсы (например, при выполнении на мобильном устройстве это может привести к ускорению разряда батарее).

Это всего лишь сообщение потоку: «Пожалуйста, остановись»

Нуу, интеррупт заставит подключения или методы(wait(), sleep() и пр), которые его поддерживают, плюнуть эксепшн, который потом можно словить и спокойно выйти. То есть если поток ждет на оперциях ввода-вывода из файла, сокета или базы данных(вроде как они тоже это поддержиывают) то его можно впоне безопасно остановить. То же самое и если поток ждет на мониторе или CV.

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

Да, без сомнения все будет хорошо, если мы имеем дело с правильно написанным кодом. Но если в коде есть ошибка приводящая, например, к бесконечному циклу, то корректно прервать зависший в цикле поток возможности нет.

Имхо, в java архитектурно всё верно решено — в ущерб «простоте и удобству» (сомнительной нужности) остановки некорректного («зависшего») потока предпочли предсказуемость. Метод stop() в его реализации по определению потенциально не может привести ни к чему хорошему.

Ребята, я, видимо, что-то не понимаю, но разве в заголовке «Java. Остановись задача» не пропущена запятая? (Если что, прошу простить за дурацкий вопрос и объяснить, в чем ошибся…)

Thread.stop() небезопасен в том плане, что перед уничтожением потока отпускаются все мониторы и блокировки. Таким образом, если поток совершал какие-либо действия над объектом в защищенном коде и не успел завершить логику — остальные потоки получат объект в непредсказуемом состоянии.
По сути, такая ситуация возможна в любом коде, который плохо обрабатывает исключения.

Thread.stop() все таки используется (вместе с ThreadDeath). Другого способа, кроме как постоянно смотреть флаг — нету.

Думаю, книга Java Concurrency in Practice (легко гуглится) поможет разобраться в ситуации. Целая глава там отведена описанию подходов для прекращения работы потока по требованию. Лично мое мнение — запуская сторонний код, нет вообще никаких гарантий его работоспособности в много-поточной среде.

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

Бороться понятно как — писать код корретно обрабатывающий прерывание. Если сторонняя бибилотека этого не умеет — пишем свою. Или убийство процесса и watchdog, смотря какие требования.

Дам ссылку на свои размышления по схожему поводу (http://mantonov.blogspot.com/2011/10/blog-post.html), когда стоялаи задачи реализовать сервис по запуску untrusted кода.

Вкратце говоря, если вы запускаете плагины (произвольный код, исполняющийся в вашем процессе JVM), то невозможность убить поток — ваша наименьшая проблема.

Автор плагина может сделать int[] array = new ing[1000000], и весь процесс моментально упадет с OutOfMemoryError, вы и пикнуть не успеете. Или же, в этом плагине может запустить рекурсивная функция без нормальной проверки условия выхода, и вы получаете stack overflow.

Я долго не мог поверить, что это на самом деле так, и читал документацию по Java Security Platform Architecture — но в итоге все подтвердилось, модель безопасности Java не дает вам надежно защититься от сбоев, вызванных чрезмерным потреблением ресурсов.

Самое нормальное решение в случае плагинов (если там действительно требуется серьезные усилия по безопасности) — это запускать весь код в отдельном процессе JVM (под ограниченными правами, выдавая ограниченное количество памяти), и дальше мониторить этот процесс, и убивать в случае превышения лимита по времени работы.

Я вот думаю, что Thread.stop() зря сделали deprecated. При написании прикладного кода это, безусловно, очень вредная и опасная функциональность. Однако же для системного когда (например, код сервера приложений или, допустим, OSGi контейнера), это, фактически, единственный способ относительно надёжно пристрелить поток.

С другой стороны, есть ещё два класса ситуаций, которые требуют поддержки со стороны JVM и с которыми, на текущий момент, ничего поделать нельзя. Это контроль за памятью отдельного приложения и выгрузка классов.

В принципе, для выгрузки классов можно было бы предусмотреть механизм «форсированной» выгрузки, когда все ссылки на объекты выгруженных классов заменяются на специальное значение unloaded и вызывают исключение при обращении к ним. Я думаю, это можно было бы сделать практически без накладных расходов в рантайме (ну разве что сама операция форсированной выгрузки будет не очень быстрой).

Для OutOfMemory можно было бы предусмотреть несколько изолированных «куч» с контролем границы между ними, но с учётом разделяемых данных это довольно сложно сделать.

Можно рассуждать о том, что это всё проблема кривых приложений, и.т.д, и.т.п. Но факт в том, что программисты делают ошибки, и ничего с этим не поделаешь. Надо как-то это контролировать. Не только багрепортами, но и самим рантаймом. Вот, например, при разработке Erlang это учли, и повальная смерть процессов там — вполне нормальное явление. Конечно, там нет разделяемой памяти, это существенно упрощает дело.

Есть возможность в долгих циклах вызывать метод ниже.

public static void isInterrupted() throws CancellationException {
   if (Thread.currentThread().isInterrupted()) {
      throw new CancellationException("Можно указать какой тред, например");
   }
}

// пример использования
public static void main() { 
   while(true) {
      isInterrupted();
      // какой-то код
   }

   for (int i = 0; i < 100_000; i++) {
      if (i % 100 == 0) {
         isInterrupted();
      }             
   }
}

И так далее… Можно просто размазать по коду в любых местах