Memory Leaks using Executors.newFixedThreadPool()

I believe the issue you encountered is the threadPool not releasing its resources. You need to call threadPool.shutdown() after you are finished submitting or executing. This will wait until the tasks have completed before terminating threads which can then be garbage collected.

From official Java api website:

"An unused ExecutorService should be shut down to allow reclamation of its resources." https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ExecutorService.html#shutdown()

Alternatively you can use a newCachedThreadPool() which "Creates a thread pool that creates new threads as needed, but will reuse previously constructed threads when they are available" see https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html

When I encountered this problem, I went with the newFixedThreadPool() and shutdown option.

I think you have no problem with memory leak, I cannot see it from your jconsole chart at least. There is no major GC collection. So it seems only more and more objet allocated into tenured(old) generation. To ensure about memory leak you should Perform GC and after that compare allocated memory. If you find a leak you are able to make a heap dump with jmap or visual tool(standart JDK tools). After this heap dump can be analyzed with MAT. Before taking heap dump it is better to Perform GC to decrease heap dump file size.

Some notes:

• Threads count shouldn't affect heap memory explicitly. It maybe useful for you to review next java memory structure. So thread require stack memory not a heap.
• In general it is not good idea to create cache for not heavy object, because of GC works algorithm.
• Also I think you should consider cached thread pool or calibrate ThreadPoolSize according server hardware.

After the usage of ExecutorService, You need to stop the thread pool, as it is the same resource, like a file or a database or anything else that requires an explicit release. ExecutorService has methods shutdown() and shutdownNow() which can be used in a finally block to gargabe collect.

import java.util.concurrent.CountDownLatch;import java.util.concurrent.ExecutorService;import java.util.concurrent.Executors;class SimpExec {  public static void main(String args[]) {    CountDownLatch countDownLatch = new CountDownLatch(5);    CountDownLatch CountDownLatch2 = new CountDownLatch(5);    ExecutorService eService = Executors.newFixedThreadPool(2);    eService.execute(new MyThread(countDownLatch, "A"));    eService.execute(new MyThread(CountDownLatch2, "B"));    try {      countDownLatch.await();      CountDownLatch2.await();    } catch (InterruptedException exc) {      System.out.println(exc);    }      finally{        eService.shutdown(); // This is the method we use to avoid memory Leaks.        // eService.shutdownNow(); // -do-       }  }}class MyThread implements Runnable {  String name;  CountDownLatch latch;  MyThread(CountDownLatch c, String n) {    latch = c;    name = n;    new Thread(this);  }  public void run() {    for (int i = 0; i < 5; i++) {      latch.countDown();    }  }}

If you forget to shutdown, the memory leak happens, It is also like streams that are not normally closed by JVM, because the default Executors does not create daemon threads.