Stopping a thread that could be looping forever

I have a program where I compile java code a user types into a text field, and then run it. A run the code in a seperate thread, so that the GUI they use to input the source code doesn't get locked up.

The GUI has an abort button that should stop the thread. My issue is that开发者_开发问答 I need to stop the compiling thread no matter what is going on inside of it, which means I must account for a case where the thread is caught in an infinite loop (due to user error), and it cannot properly end itself using a safe flag. I've read up on many solutions that involve using a flag of some kind, but they aren't available to me because of this looping issue. I need to have the thread stop and the memory it's using freed (I can't just let it sit in the background forever, unless that is the only solution left). Any advice or alternative solutions? Hopefully some fresh perspectives could help squash this issue.

Edit:

Here's a sample bit of user submitted code:

public class RunMe extends SomethingThatRuns {
    public void run() {
        int i = 0;
        while (i = 0) {
            //Prepare to get stuck!
        }
    }
}

I'll compile this class, and then run it. This is where it will get stuck, and the run() method can never finish, or even loop to check a flag.

You can run it in a new JVM so you can kill it when you want. Thinking about security this may be a good thing to do too.

Call stop() on the thread.

Yes, this is a deprecated method. However, it really shouldn't be "deprecated", it should be "dangerous." In some circumstances, however, there's really no choice but to use it, and the invocation of an "agent" provided by a user is one of those cases.

Make sure that your program doesn't use any data that are manipulated by this user thread; or, if you do, devise some transactional mechanism to exchange data safely between the threads.

Even this method isn't guaranteed to terminate the thread. For example, the user can catch the resulting Throwable and ignore it. Or, the thread implementation might not respond to stop() calls if the thread is in some native code. But it's your best chance.

The core issue here is the fact that the code even allows an infinite loop to be entered as part of user error. Fix that, and everything else will become easier to deal with.

Properly-behaving threads should usually terminate themselves gracefully when there's no work to do (or return quietly to a thread pool to ask for more work, if that's your application's design). If you feel like you need to have one thread forcefully kill another then you've likely got a fundamental design issue. It's fine to have one thread tell another, "Hey, you should terminate now so that I can join with you..." because that allows your threads to clean things up as they finish. Forcefully destroying threads just isn't the right way to manage these situations.

You can use them to insert a interrputed check in every loop and maybe in other places too.

I can see two options:

• As you compile the user code you can edit it before. You may use ANTLR to parse and modify the code.
• There are bytecode manipulation frameworks like ASM that allow you to manipulate code that is already compiled.

I don't think it is easy but it might be a way.

interupt(); the Thread in the gui

and in the code that the thread runs regularly check for Thread.interrupted() and throw an exception when you do especially inside loops

At a high level, you are asking how one thread might go about stopping another thread. To that end, see this SO question Stopping a Thread in Java?.