Java - ThreadLocal or Concurrent Object Pool?

Question

Which method is more acceptable to access to a Non Thread Safe Object ?

using ThreadLocal objects :

static final ThreadLocal<NonThreadSafeParser> PARSER_THREAD_LOCAL = new ThreadLocal<NonThreadSafeParser>() {
    @Override
    protected NonThreadSafeParser initialValue() {
        return new NonThreadSafeParser();
    }
};

void parse(String input) {
    PARSER_THREAD_LOCAL.get().parse(input);
}

using a Concurrent Object Pool :

static final ConcurrentObjectPool<NonThreadSafeParser> PARSER_POOL = new ConcurrentObjectPool<>();

void parse(String input) {
    NonThreadSafeParser parser = PARSER_POOL.borrow();
    try {
        parser.parse(input);
    } finally {
        PARSER_POOL.release(parser);
    }
}

or other methods that you want to offer?

Important factors are :

Performance
Memory Usage
Garbage Collection

Generally, what are the Pros and Cons for each method?

Is there any noticeable difference between them?

Thanks.

EDIT :

An example of Concurrent Object Pools used by Kryo.

@ParkerHalo so what if it is? Looks like a valid question to me — Alexander Derck, Jan 25 '16 at 10:31
@AlexanderDerck It's actually not. "Which method do you prefer" immediately makes it eligible for closing with "Primarily opinion based" in my book. While the question itself is harmless, it's the "homeworkish" way that spoils a good question. — Kayaman, Jan 25 '16 at 11:13
@Kayaman Actually it is. The purpose of this question is not for any "Job-Interview" or "Homework!" or such things... In fact, in my current project, there's a situation where I can use both options but I want to choose the best one. — FaNaJ, Jan 25 '16 at 11:38
There rarely is a "best one", but in this case there is. Try to see if you can find out which one it is! — Kayaman, Jan 25 '16 at 11:42
Am I going mad? I can't find any built-in `ConcurrentObjectPool` class in the JDK. — biziclop, Jan 25 '16 at 11:59

score 5 · Answer 1 · answered Jan 25 '16 at 12:08

The obvious difference is of course that you have either a pool of objects, or a dedicated object per thread. This has various consequences such as ThreadLocals can be fully stateful since they're only used by a single thread. Pooled objects can be stateful, but only during the time they're checked out by a thread.

Some people think ThreadLocals are evil and even if they're not, they still require you to be a smart cookie when using them. Object pool pitfalls and advantages depend a lot on the actual objects being stored inside.

So in conclusion: it depends and it's somewhat opinion based. Once again we have a software development question that doesn't have an absolute answer, even though people love to think that we're dealing with an exact science.

score 1 · Answer 2 · answered Jan 25 '16 at 11:51

In general, I would use

ThreadLocal - if that object belongs to that thread only but can't be private and need to be accessed across layers. It could be context related to the current thread.

ThreadPool - when I need to share limited resources or need to synchronize communication between multiple threads.

score 1 · Answer 3 · answered Aug 08 '17 at 13:24

A rough rule of thumb may be how "long" of a lease each thread would generally have on those objects. If threads should hold onto these objects for (close to) the whole time they're actively running anyway, a ThreadLocal<> may be the way to go. On the other hand, if these objects are to be used only briefly or intermittently compared to the whole thread's lifetime, then object pooling may be the way to go.

Java - ThreadLocal or Concurrent Object Pool?

3 Answers3