Fortify Code scan - Use of ThreadLocal

[niraj.nath]

Hi everyone,

     I've a question regarding one of the issue raised in Fortify java code scan. I'm seeing that the use of ThreadLocal is being raised as issue under "J2EE bad Practice: Thread Management ". I'm kind of surprised as why it's being considered bad. Could someone help here with relevant information ?

Here is a sample -

@SuppressWarnings("rawtypes")

    private static ThreadLocal<HashMap<String, Constructor>> constructLocal = new ThreadLocal<HashMap<String, Constructor>>(){

          @Override protected HashMap<String, Constructor> initialValue() {

            return new HashMap<String, Constructor>();

        }

    };

Thanks in advance.

[dwinter1]

ThreadLocals are additional attributes added to a thread. Threads are usually pooled in J(2)EE, i.e. they are created once and returned into a thread pool. Such ThreadLocals behave like global variables bound to a thread. If the thread isn't used anymore, the thread is “released”, i.e. returned into the pool. The application server doesn't care about the ThreadLocals, it doesn't touch them and also doesn't clean them or release their memory.

If you store sensitive information in ThreadLocals, i.e. information which must not be shared between users or threads, you have to take care of cleaning them up yourself before the thread is released.

If you store data in ThreadLocals, their memory is not released as well. You may run in a memory leak.

See e.g. ThreadLocal and Thread Pools - The Kitchen in the Zoo