> On 3 Feb 2022, at 16:16, Alexander Veit <gro...@nezwerg.de> wrote: > > Hi, > > after upgrading from Groovy 3.0.9 to 4.0.0 our test framework complains about > remnant threads created by the Groovy compiler. > > They are named "ForkJoinPool.commonPool-worker-N" where N is an integer > number. > > 1.) Can this behaviour be controlled? In the CompilerConfiguration and > GroovyClassLoader I couldn't find a hint. > > 2.) Is it possible to provide a custom ThreadFactoy?
They should get reclaimed over time, see javadoc for java.util.concurrent.ForkJoinPool. Excerpt: All worker threads are initialized with Thread.isDaemon() set true. A static commonPool() is available and appropriate for most applications. The common pool is used by any ForkJoinTask that is not explicitly submitted to a specified pool. Using the common pool normally reduces resource usage (its threads are slowly reclaimed during periods of non-use, and reinstated upon subsequent use). In other words, don’t worry, it’s not a resource leak. :-) But if you really want to mess with it the javadoc should help, you can set the thread factory via a system property, for instance, as well as monitoring what it’s doing. -- Rachel Greenham rac...@merus.eu
