Любой способ прервать, уничтожить или иным образом раскрутить (сняв блокировки синхронизации) один заблокированный поток Java, позволяющий другим потокам продолжить?

Question

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

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

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

JVM - это 64-разрядная версия Sun 1.6.0_16 в Ubuntu, а расходуемый поток ожидает блокировки объекта-монитора.

Может ли сигнал ОС, направленный на конкретный поток, создать исключение InterruptedException в потоке с расходными данными?

Может ли подключение с помощью gdb и непосредственное вмешательство в данные JVM или вызов процедур JVM разрешить принудительное освобождение монитора объектов, удерживаемого потоком расходных материалов?

Будет ли Thread.interrupt() из другого потока сгенерировать InterruptedException из кадра ожидания до блокировки? (С некоторыми усилиями я могу внедрить произвольный сценарий beanhell в работающую систему.)

Может ли устаревший Thread.stop() быть отправлен через JMX или любым другим методом удаленного внедрения?

Любые идеи оценены, чем «опаснее», тем лучше! И, если ваше предложение сработало на личном опыте в аналогичной ситуации, лучше всего!

Answer 1

Может ли сигнал ОС, направленный на конкретный поток, создать InterruptedException в расходуемом потоке?

номер

Может ли подключение с помощью gdb и непосредственное вмешательство в данные JVM или вызов процедур JVM позволить принудительное освобождение монитора объектов, удерживаемого потоком расходных материалов?

В теории Да. На практике вам потребуется глубокое понимание внутренних особенностей JVM, чтобы иметь какие-либо шансы на успех. Итак, реально №

Будет ли Thread.interrupt() из другого потока генерировать InterruptedException из фрейма ожидания до блокировки? (С некоторыми усилиями я могу внедрить произвольный сценарий beanhell в работающую систему.)

В теории Да. На практике сценарию beanshell необходимо найти объект Thread для прерывания потока. Это может включать обход дерева ThreadGroup объектов и т. Д. Другая проблема заключается в том, будет ли прерванный поток вести себя правильно. Например, многие люди пишут свой код ожидания / уведомления, чтобы перехватить / проигнорировать InterruptedException и повторить попытку. Если вы сделали это, прерывание, вероятно, не принесет пользы.

Может ли устаревший Thread.stop () быть отправлен через JMX или любым другим методом удаленного внедрения?

Если вы можете позвонить Thread.interrupt(), вы можете использовать тот же подход для вызова Thread.stop(). Обычно я бы сказал, не делай этого. Но в этой ситуации стоит попробовать.

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

Answer 2

Забудь об этом. В лучшем случае вы можете обнаружить тупик с помощью сторожевого таймера, игнорировать застрявшие потоки и создать новые потоки для продолжения работы. Не очень сытно. Вы не можете разблокировать вовлеченные замки, и есть два удерживаемых замка (или больше). Вы не можете заставить "расходуемую" нить освободить замок, который она удерживает.

Существует довольно простой способ обнаружения потенциальных тупиков: назначьте уровень от 1 и выше для каждой блокировки. Примените правило «Удерживая блокировку, поток должен получать блокировки только с более низким уровнем». Если вы поймете нарушение правила, исправьте нумерацию. Если это не может быть исправлено, то у вас есть потенциальный тупик, который при неудаче может превратиться в настоящий тупик. Измени свой код.