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?

But my gut instinct says `ThreadLocal` is faster, if implemented correctly. — biziclop, Aug 20 '14 at 13:37
benchmarks give the definitive answer, but even after you may not know the *why* .. — harschware, Jun 08 '17 at 17:56

Bogdan Emil Mariesan · Accepted Answer · 2015-07-30T12:42:12.810

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.

score 19 · Answer 2 · answered Apr 29 '16 at 17:01

19

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.

answered Apr 29 '16 at 17:01

Artem Novikov

4,087
1
27
33

Could you be more precisely ? I mean my problem: http://stackoverflow.com/questions/43181576/threadlocal-using-as-context-information-for-rest-api-with-spring-boot. Particulary, If we can assume that `afterCompletion` will be executed by the same thread which executed `preHandle` and executes body of controller, calling to dao ? – Apr 03 '17 at 18:22
If you have a filter (e.g., `@WebFilter`) and you set your thread local value in the pre-processing of the filter, then you should not need to worry about clearing the thread local value afterwards. – Paulo Merson Jun 12 '18 at 12:00
Removing the thread local variable is so important!! You might see really weird results if it's not done. – Saurabh Gour Feb 06 '19 at 13:58
What about the performance cost of calling remove after every once of these requests? – Adrian M. Mar 17 '20 at 22:57
Instead of using an afterCompletion() I would clean the threadLocal at the beginning. In most of the cases the execution of your logic starts from the same point, in case of exceptions, it can be stopped in different places. – Marco Altieri Sep 30 '20 at 12:44

score 10 · Answer 3 · answered Aug 20 '14 at 13:38

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.

Spring Request scope vs java thread-local

3 Answers3

Linked