Надежная остановка неотвечающего потока

Для меня isAlive возвращает false, если процесс завершается из-за Thread.stop.

Я сделал следующий пример, и он успешно убивает ошибочный поток.

import java.util.Arrays;
public class BrokenThreads{
    static boolean[] v = { true };
    public static void call(){
            try{
                while(true){
                    Thread.sleep(200);
                }
            
            } catch ( Throwable td){
                System.out.println("restarting");
                call();
            }   
    }
    public static void main(String[] args) throws Exception{
        
        Thread a = new Thread( BrokenThreads::call);
        
        a.start();
        Thread.sleep(500);
        System.out.println( Arrays.toString( a.getStackTrace() ) );
        while(v[0]){
            a.stop();
            System.out.println(a.getStackTrace().length);
            v[0] = a.isAlive();
        }
        System.out.println("finished normally");
        System.out.println( Arrays.toString( a.getStackTrace() ) );
    }
}

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

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

Я думаю, что вопрос описывает сценарий, который является причиной того, что Thread.stop() устарел с незапамятных времен, но еще не был удален … просто чтобы иметь «последний вариант», который следует использовать только в действительно отчаянных случаях и зная обо всем негативном влияние.

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

Хорошо, во время тестирования ваш собственный код может выйти из строя, и вам нужен аварийный перерыв — для этого все еще достаточно Thread.stop(), если вы не хотите убивать всю JVM (что было бы лучше в большинстве случаев) . Но опять же, вы должны встроить это в код до того, как начнете тест…

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

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

Что вы можете сделать, так это изолировать поток, запустив на нем .finalize(), а затем заставить JVM выполнять операции GC, такие как Runtime.gc(), System.runFinalization(), при этом принудительно прерывая этот конкретный поток, чтобы обойти его поведение при воскрешении.

Я думаю, что .finalize() фактически устарел с java11 или, может быть, раньше, так что, вероятно, это вам не сильно поможет.

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

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

Примечание. Если этот инвазивный поток вызывает собственный код dll, который зацикливается на своем вызывающем, то ваша JVM выйдет из строя, если вы пометите разделы ее адресного пространства как сборщик мусора.