ExecutorService.newFixedThreadPool() - Possible thread leak?

[pacionet]

We have a web service REST which invokes a method which sends some mail, using multithreading, like this:

[...]

executor = Executors.newFixedThreadPool(10);

list = new ArrayList<Future<Integer>>();

for (int i = 0; i < recipients.length; i++) {

email = new Email();

[...]

worker = new EmailService(email);

future = executor.submit(worker);

list.add(future);

}

executor.shutdown();

while (!executor.isTerminated()) {}

[...]

When i monitor THREAD USAGE from Wildfly 10.1.0 console (STANDALONE SERVER -> MONITOR JVM ) I noticed that:

THREAD USAGE->

     LIVE: increasing every time i invoke the method

     DAEMON: not increasing

The statement executor.shutdown() seems not to kill the threads .  The thread simply send a mail and returns.

Some hints?

[pacionet]

Probably it's a false problem.

I tried a load test with 600 task executed by 10 thread and I had no problems.

[jaikiran]

I don't see any WildFly or Java EE constructs in this code, so the behaviour/semantic should be exactly like what the javadoc of Executors#newFixedThreadPool dictates.

Mario Rossi wrote:

The statement executor.shutdown() seems not to kill the threads .

Can you get a thread dump and point us to the threads that you think are still running and not killed?

[dmlloyd]

Also I'd like to add that using a spin loop to wait for the executor shutdown is probably a bad idea; there is an awaitTermination method which is probably better.

Finally it's likely better to share a single thread pool over the life of the application than to create a new one on every request.  Java EE 7 has a facility for using thread pools safely from a Java EE application.