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

Question

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

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

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

Но тем не менее, так как единственная альтернатива должна уничтожить процесс JVM и пройти более длинную процедуру, которая привела бы к менее - полный итоговый отчет, messy/deprecated/dangerous/risky/one-time методы точно, что я хотел бы попробовать.

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

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

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

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

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

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

1

java synchronization gdb deadlock interrupted-exception

задан gojomo 3 March 2018 в 15:37

1 ответ

Другие вопросы по тегам:

java synchronization gdb deadlock interrupted-exception

Похожие вопросы:

score 2 · Accepted Answer

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

Нет.

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

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

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

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

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

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

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