Maven 中 System.out.println 时重置线程中断标志

Question

Consider this program

class Interrupted {
public static void main(String[] args) {
    assertFalse(Thread.currentThread().isInterrupted());
    assertFalse(Thread.currentThread().isInterrupted());
    Thread.currentThread().interrupt();
    System.out.println("hello world");
    assertTrue(Thread.currentThread().isInterrupted(), "first");
    assertTrue(Thread.currentThread().isInterrupted(), "second");
}

private static void assertFalse(boolean value) {
    if (value) {
        throw new RuntimeException("should be false");
    }
}

private static void assertTrue(boolean value, String text) {
    if (!value) {
        throw new RuntimeException("should be true " + text);
    }
}

}

This program runs fine when you run it from the command line (java -cp target/classes example.sometest.Interrupted ), or from IntelliJ, or Eclipse. But when you run it from "mvn test" then it fails. The call to System.out.println resets the interrupted flag. What is going on? My unit tests in one of my projects do System.out.println and expect the flag to not be reset.

public class InterruptedTest {
@Test
void test() {
    Interrupted.main(null);
}

Output of "mvn test"

[ERROR] example.sometest.InterruptedTest.test  Time elapsed: 0.019 s  <<< ERROR!
java.lang.RuntimeException: should be true first
at example.sometest.InterruptedTest.test(InterruptedTest.java:8)

Answer 1

You don't 'own' that flag - any method is more or less free to lower that and deal with the problem. It's a bit bizarre that the mvn test handler has some I/O op that will trigger on this flag (thus lowering it), but not show any error.

Here's the central problem you're facing:

All methods can be sorted into three categories:

• Completely ignore the interrupted flag; they don't abort when it is raised, and they do not lower it.
• Are specified to deal with it. For core libraries, these are easy: They always are declared to throws InterruptedException and they always deal with it by aborting immediately, lowering the flag , and throwing it. This goes far: If the flag is on and you call Thread.sleep , for example, that call will immediately lower that flag and throw InterruptedException.
• The ¯\\ (ツ) /¯ methods: Think blocking file IO and such. Because of differences of underlying OS implementations, if you raise the interrupt flag on a thread whilst it is in the middle of a blocking operation (or start a blocking call when it is already up), then that blocking call may completely ignore it, or it may deal with it. If it does, it will almost invariably lower the flag and throw IOException with a message indicating that it got interrupted.

And that's just the methods in core java. Because it is a global public state variable, it's pretty much impossible to try to write code to deal with this properly. What should occur on an interrupt is intentionally not clearly specified.

Apparently something in maven is calling blocking output (that's logical: Every System.out call blocks in theory, and that's enough - if the OS supports it, something as trivial as System.out.println() will lower that flag and throw something), but is then ignoring the exception that falls out which is odd, but, I guess that's happening.

Here's the key point though: That flag is extremely fragile - a ton of core methods, if called, will lower it, and it's not possible to know which ones (at the very least all methods declared to throw InterruptedException , but many more, and it's OS dependent which ones), so whatever code you wrote that is somehow dependent on this may need to be revisited. There certainly is no --stop-messing-with-my-interrupt-flag maven option, I'm afraid :(