我知道 Thread.stop() 已被弃用，并且有充分的理由:它通常不安全。但这并不意味着它从不安全……据我所知，它在我想要使用它的上下文中是安全的；而且，据我所知，我别无选择。

上下文是双人策略游戏的第三方插件:国际象棋将作为工作示例。需要给第三方代码一个当前的棋盘状态，并且(比如说)10 秒来决定它的移动。它可以返回它的移动并在允许的时间内终止，或者它可以随时发出其当前首选移动的信号；如果时间限制到期，它应该停止在它的轨道上，并且应该播放它最近的首选 Action 。

编写插件以按要求正常停止不是一个选项:我需要能够使用任意不受信任的第三方插件。所以我必须有一些方法来强行终止它。

这是我为锁定它所做的工作:

1. 插件的类被放入它们自己的线程、它们自己的线程组中。
2. 它们加载了一个类加载器，该类加载器具有高度限制性的 SecurityManager:所有类可以做的就是数字运算。
3. 这些类不会获得对任何其他线程的引用，因此它们不能对它们未创建的任何对象使用 Thread.join()。
4. 插件仅从主机系统获取两个对象引用。一是棋盘状态；这是一个深拷贝，之后会被丢弃，所以如果它进入不一致状态也没关系。另一个是允许插件设置其当前首选移动的简单对象。
5. 我正在检查 CPU 时间何时超过限制，并且我会定期检查插件的至少一个线程是否正在做某事(这样它就不会无限期地 hibernate 并避免 CPU 时间达到限制)。
6. 首选的移动没有​​足够的状态来不一致，但在任何情况下，它在返回后都会被仔细地和防御性地克隆，并且返回的那个被丢弃。至此，插件引用的主机系统中没有留下:没有线程，没有对象实例。

因此，插件似乎不能让任何东西处于不一致状态(除了它可能创建的任何对象，然后这些对象将被丢弃)；并且它不会影响任何其他线程(除了它产生的任何线程，它们将在同一个 ThreadGroup 中，因此也将被杀死)。

在我看来，不推荐使用 Thread.stop() 的原因在这里并不适用(按设计)。我错过了什么吗？这里还有危险吗？或者我是否足够仔细地隔离事物以确保不会出现问题？

还有更好的方法吗？我认为，唯一的选择是启动一个全新的 JVM 来运行不受信任的代码，并在不再需要该进程时强行终止它，但这还有一千个其他问题(昂贵、脆弱、依赖操作系统)。

请注意:我对类似“哦，它被弃用是有原因的，你想看它，伙计”这样的回答不感兴趣。我知道它被弃用是有原因的，我完全理解为什么一般从笼子里放出来是不安全的。我想问的是，是否有特定原因认为它在这种情况下是不安全的。

对于它的值(value)，这里是代码的(删节的)相关部分:

public void playMoveInternal(GameState game) throws IllegalMoveException,
        InstantiationException, IllegalAccessException,
        IllegalMoveSpecificationException {
    ThreadGroup group = new ThreadGroup("playthread group");
    Thread playthread = null;
    group.setMaxPriority(Thread.MIN_PRIORITY);
    GameMetaData meta = null;
    StrategyGamePlayer player = null;
    try {
        GameState newgame = (GameState) game.clone();
        SandboxedURLClassLoader loader = new SandboxedURLClassLoader(
          // recreating this each time means static fields don't persist
                urls[newgame.getCurPlayer() - 1], playerInterface);
        Class<?> playerClass = loader.findPlayerClass();
        GameTimer timer = new GameTimer(
                newgame.getCurPlayer() == 1 ? timelimit : timelimit2);
          // time starts ticking here!
        meta = new GameMetaData((GameTimer) timer.clone());
        try {
            player = (StrategyGamePlayer) playerClass.newInstance();
        } catch (Exception e) {
            System.err.println("Couldn't create player module instance!");
            e.printStackTrace();
            game.resign(GameMoveType.MOVE_ILLEGAL);
            return;
        }
        boolean checkSleepy = true;
        playthread = new Thread(group, new MoveMakerThread(player, meta,
                newgame), "MoveMaker thread");
        int badCount = 0;
        playthread.start();
        try {
            while ((timer.getTimeRemaining() > 0) && (playthread.isAlive())
                    && (!stopping) && (!forceMove)) {
                playthread.join(50);
                if (checkSleepy) {
                    Thread.State thdState = playthread.getState();
                    if ((thdState == Thread.State.TIMED_WAITING)
                            || (thdState == Thread.State.WAITING)) {
                        // normally, main thread will be busy
                        Thread[] allThreads = new Thread[group
                                .activeCount() * 2];
                        int numThreads = group.enumerate(allThreads);
                        boolean bad = true;
                        for (int i = 0; i < numThreads; i++) {
                            // check some player thread somewhere is doing something
                            thdState = allThreads[i].getState();
                            if ((thdState != Thread.State.TIMED_WAITING)
                                    && (thdState != Thread.State.WAITING)) {
                                bad = false;
                                break; // found a good thread, so carry on
                            }
                        }
                        if ((bad) && (badCount++ > 100))
                            // means player has been sleeping for an expected 5
                            // sec, which is naughty
                            break;
                    }
                }
            }
        } catch (InterruptedException e) {
            System.err.println("Interrupted: " + e);
        }
    } catch (Exception e) {
        System.err.println("Couldn't play the game: " + e);
        e.printStackTrace();
    }
    playthread.destroy();
    try {
        Thread.sleep(1000);
    } catch (Exception e) {
    }
    group.stop();
    forceMove = false;
    try {
        if (!stopping)
            try {
                if (!game.isLegalMove(meta.getBestMove())) {
                    game.resign(GameMoveType.MOVE_ILLEGAL);
                }
                else
                    game.makeMove((GameMove) (meta.getBestMove().clone()));
                // We rely here on the isLegalMove call to make sure that
                // the return type is the right (final) class so that the clone()
                // call can't execute dodgy code
            } catch (IllegalMoveException e) {
                game.resign(GameMoveType.MOVE_ILLEGAL);
            } catch (NullPointerException e) {
                // didn't ever choose a move to make
                game.resign(GameMoveType.MOVE_OUT_OF_TIME);
            }
    } catch (Exception e) {
        e.printStackTrace();
        game.resign(GameMoveType.MOVE_OUT_OF_TIME);
    }
}

最佳答案

虽然我可以想象您仔细检查过的代码可以使用 Thread.stop() 安全停止的场景，但您说的恰恰相反，您非常不信任以至于您正在尝试的代码通过 SecurityManager 限制其操作。

那么会出现什么问题呢？首先，停止并不比中断更可靠。虽然忽略中断更容易，但一个简单的 catch(Throwable t){} 足以让 Thread.stop() 不再工作，这样的 catch 可能出现在代码中，即使没有阻止 Thread.stop() 工作的意图，尽管它是糟糕的编码风格。但是编码人员想要忽略Thread.stop() 甚至可能添加一个catch(Throwable t){} 和/或catch( ThreadDeath t){} 有意。

说到糟糕的编码风格，应该始终使用 try … finally … 来实现锁定，以确保即使在异常情况下也能保证释放锁。如果停止的代码未能正确执行此操作，则当线程将停止时，锁可能会保持锁定状态。

底线是，在同一个 JVM 中，您无法保护自己免受不受信任的代码的侵害。 JVM 是保护外部的沙箱。举一个简单的例子:恶意代码可能会通过执行大量小内存分配来开始消耗内存。您无法在 JVM 中执行任何操作来保护在同一 JVM 中运行的某些代码免受它的侵害。您只能对整个 JVM 实现限制。

所以唯一的解决方案是在不同的 JVM 中运行插件。

关于java - 在仔细锁定但不受信任的代码上使用 Thread.stop()，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25489720/