Spring Request scope vs java thread-local

Question

In high volume (~50,000 requests per second) java web-app I'm using ThreadLocal to execute a task which should be executed per request scope.

I could achieve the same effect using Spring request scope and I wondered which is better performance wise?

In code, using ThreadLocal:

private static final ThreadLocal<SomeClass> myThreadLocal = new ThreadLocal<SomeClass>();

And for each http request setting:

myThreadLocal.set(new SomeClass());

Using Spring request scope:

@Component
@Scope("request")
public class SomeClass{
...
}

Now, what will cost more:

myThreadLocal.get();

OR

SpringContext.getBean(SomeClass.class);

I wonder if anyone has already tried such a benchmark?

Answer 1

If we consider the traditional Java approach the answer can be deducted from the quote bellow as being much slower:

Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.

Quoted from the JavaDoc about reflection - http://java.sun.com/docs/books/tutorial/reflect/index.html

So since Spring uses Reflection with the getBean() method the SpringContext.getBean(SomeClass.class); approach should be slower.

EDIT :

Also note that the ThreadLocal also has caching embedded so as long as you reuse information in those threads it's for sure faster.

Answer 2

Regarding the ThreadLocal solution I would like to add that there is probably a thread pool in your web server (for ex: Tomcat) and your thread local variable won't actually be cleared upon completion of each request as processing threads don't die with a thread pool enabled.

You need to clear the thread-local variable ( threadLocal.remove() ) manually upon complection of each request. For that you can use, for example, some kind of afterCompletion() of some of those Spring request/response interceptors.

Answer 3

The Spring solution will cost more but will make for cleaner code IMO. There are a lot of steps involved in fetching, creating, initializing, and storing a bean. However you won't have to think about clearing the request scoped bean as you would the ThreadLocal . It will be collected when the corresponding ServletRequest is cleaned up.