FULL PRODUCT VERSION :
java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601] (fully patched)

A DESCRIPTION OF THE PROBLEM :
There are multiple issues with ForkJoinPool.commonPool

1. The default thread pool does not change Thread.contextClassLoader to the system class loader. When ForkJoinPool.commonPool is used in a multi-class loader environment (e.g. a JavaEE container) this causes references to be retained to the class loader associated with the code that first uses the pool. This is highly likely to cause a memory leak.

2. The InnocuousForkJoinWorkerThread does not modify Thread.contextClassLoader so undesirable class loader references are retained even when using the InnocuousForkJoinWorkerThreadFactory

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Execute this test case:

https://github.com/markt-asf/memory-leaks/blob/master/src/org/apache/markt/leaks/concurrent/ForkJoinThreadLeak.java

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The console should report no leaks detected.
ACTUAL -
The console reports that a memory leak is detected and use of a profiler confirms the leak.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
https://github.com/markt-asf/memory-leaks/blob/master/src/org/apache/markt/leaks/concurrent/ForkJoinThreadLeak.java
---------- END SOURCE ----------