thread-local

How much is read from ThreadLocal variable slower than from regular field? More concretely is simple object creation faster or slower than access to ThreadLocal variable? I assume that it is fast enough so that having ThreadLocal<MessageDigest> instance is much faster then creating instance of MessageDigest every time. But does that also apply for byte[10] or byte[1000] for example? Edit: Question is what is really going on when calling ThreadLocal 's get? If that is just a field, like any other, then answer would be "it's always fastest", right? Running unpublished benchmarks, ThreadLocal.get

I'm having an issue where I'm creating a ThreadLocal and initializing it with new ThreadLocal . The problem is, I really conceptually just want a persistent list that lasts the life of the thread, but I don't know if there's a way to initialize something per-thread in Java. E.g. what I want is something like: ThreadLocal static { myThreadLocalVariable.set(new ArrayList<Whatever>()); } So that it initializes it for every thread. I know I can do this: private static Whatever getMyVariable() { Whatever w = myThreadLocalVariable.get(); if(w == null) { w = new ArrayList<Whatever>();

Once I have came across a pattern, where ServletRequest and response objects are put to servlet's local ThreadLocal variables. The servlet class has also methods to get current request and response objects. So in order to get these objects you still need to operate with servlet object. What is the point of having these ThrealLocal local variables? The point is to have the request and response objects in classes that would otherwise would not have them (for example they are not servlets). One example are JSF managed beans - their methods do not take HttpServletRequest parameters, and so you can

I'm running a process in a separate thread with a timeout, using an ExecutorService and a Future (example code here ) (the thread "spawning" takes place in a AOP Aspect). Now, the main thread is a Resteasy request. Resteasy uses one ore more ThreadLocal variables to store some context information that I need to retrieve at some point in my Rest method call. Problem is, since the Resteasy thread is running in a new thread, the ThreadLocal variables are lost. What would be the best way to "propagate" whatever ThreadLocal variable is used by Resteasy to the new thread? It seems that Resteasy uses

This question already has an answer here: When and how should I use a ThreadLocal variable? 24 answers The purpose of ThreadLocal as given here states that the variable is local to any Thread accessing an object containing the ThreadLocal variable. What difference does it make, in having a ThreadLocal variable as a member of a class and then making it local to a Thread, rather than having a local variable to the Thread itself? leonm A thread is a unit of execution and so multiple thread can execute the same code at the same time. If multiple threads execute on an object/instance at the same

[ThreadStatic] is defined using attribute while ThreadLocal<T> uses generic. Why different design solutions were chosen? What are the advantages and disadvantages of using generic over attributes in this case? Jim Mischel Something the blog post noted in the comments doesn't make explicit, but I find to be very important, is that [ThreadStatic] doesn't automatically initialize things for every thread. For example, say you have this: [ThreadStatic] private static int Foo = 42; The first thread that uses this will see Foo initialized to 42 . But subsequent threads will not. The initializer works