Lingering threads in multiple tests

[aoli-al]

Guava Version

514f212777da34df57fb9ce875ce77948bf95473

Description

While running Guava tests, I noticed multiple threads created by different tests that were left open.

Here is the incomplete list:

The thread pool was opened here, but the shutdown was not called.

https://github.com/google/guava/blob/514f212777da34df57fb9ce875ce77948bf95473/guava-tests/test/com/google/common/cache/CacheBuilderTest.java#L496

In FuturesTest.java, multiple tests call newSingleThreadExecutor() without shutdown.

https://github.com/google/guava/blob/514f212777da34df57fb9ce875ce77948bf95473/guava-tests/test/com/google/common/util/concurrent/FuturesTest.java#L444

In TestThread.java, calling stop() may throw UnsupportedOperationException for the new version of Java. Thus, the join method will not be called. (maybe call interrupt when stop is not available?)

https://github.com/google/guava/blob/514f212777da34df57fb9ce875ce77948bf95473/guava-tests/test/com/google/common/util/concurrent/TestThread.java#L76

Example

Any test mentioned above.

Expected Behavior

The test should clean up threads.

Actual Behavior

Threads left open.

Packages

No response

Platforms

No response

Checklist

• [X] I agree to follow the code of conduct.

• [X] I can reproduce the bug with the latest version of Guava available.

[aoli-al]

7320 addresses the lingering threads in CacheBuilderTest and FutureTest; however, the threads in TestThread are still not properly closed.

I tried to call thread.interrupt in TestThread::tearDown, but it does not work for UninterruptibleMonitorTest. Shall I create another issue to track this or just leave this issue open?

[cpovirk]

We probably should use interrupt() so that we at least get rid of the threads from InterruptibleMonitorTest. I think the threads from UninterruptibleMonitorTest are unavoidably stuck under newer versions of Java. That is not great, but it should be mostly harmless, I hope. (If we see bigger problems in the future, we could consider trying to run those tests in a separate VM (which I assume they are not run in currently) or even exclude them entirely from our external CI, leaving them to run internally (assuming that we don't see similar problems there :)).)

We should probably make our tearDown() method catch the UnsupportedOperationException from stop() while we're there. It doesn't fail the test, but it's probably spamming output. (We could still output something to acknowledge what's going on, but we could at least make it shorter than a full stack trace. And we probably don't need to bother at all if we leave a comment.)