java - Runnable 中的 ThreadLocal 与局部变量

Question

其中哪一个ThreadLocal或局部变量Runnable将是首选？出于性能原因。我希望使用局部变量会给 cpu 缓存等提供更多机会。

Answer 1

优先选择 ThreadLocal 或 Runnable 中的局部变量中的哪一个。

如果您有一个在线程类（或Runnable）中声明的变量，则局部变量将起作用，您不需要ThreadLocal.

new Thread(new Runnable() {
    // no need to make this a thread local because each thread already
    // has their own copy of it
    private SimpleDateFormat format = new SimpleDateFormat(...);
    public void run() {
       ...
       // this is allocated per thread so no thread-local
       format.parse(...);
       ...
    }
}).start();

另一方面，ThreadLocal当您执行公共代码时，s 用于在每个线程的基础上保存状态。例如，SimpleDateFormat（不幸的是）不是线程安全的，因此如果您想在由多个线程执行的代码中使用它，您需要将一个存储在 a 中ThreadLocal，以便每个线程都有自己的格式版本。

private final ThreadLocal<SimpleDateFormat> localFormat =
    new ThreadLocal<SimpleDateFormat>() {
        @Override
        protected SimpleDateFormat initialValue() {
            return new SimpleDateFormat(...);
        }
     };
...
// if a number of threads run this common code
SimpleDateFormat format = localFormat.get();
// now we are using the per-thread format (but we should be using Joda Time :-)
format.parse(...);

An example of when this is necessary is a web request handler. The threads are allocated up in Jetty land (for example) in some sort of pool that is outside of our control. A web request comes in which matches your path so Jetty calls your handler. You need to have a SimpleDateFormat object but because of its limitations, you have to create one per thread. That's when you need a ThreadLocal. When you are writing reentrant code that may be called by multiple threads and you want to store something per-thread.

Instead, if you want pass in arguments to your Runnable then you should create your own class and then you can access the constructor and pass in arguments.

new Thread(new MyRunnable("some important string")).start();
...
private static class MyRunnable implements {
    private final String someImportantString;
    public MyRunnable(String someImportantString) {
        this.someImportantString = someImportantString;
    }
    // run by the thread
    public void run() {
       // use the someImportantString string here
       ...
    }
}

Answer 2

Whenever your program could correctly use either of the two (ThreadLocal or local variable), choose the local variable: it will be more performant.

ThreadLocal is for storing per-thread state past the execution scope of a method. Obviously local variables can't persist past the scope of their declaration. If you needed them to, that's when you might start using a ThreadLocal.

Another option is using synchronized to manage access to a shared member variable. This is a complicated topic and I won't bother to go into it here as it's been explained and documented by more articulate people than me in other places. Obviously this is not a variant of "local" storage -- you'd be sharing access to a single resource in a thread-safe way.

Answer 3

I was also confused why i need ThreadLocal when i can just use local variables, since they both maintain their state inside a thread. But after a lot of searching and experimenting i see why is ThreadLocal needed.

I found two uses so far -

1. Saving thread specific values inside the same shared object
2. Alternative to passing variables as parameters through N-layers of code

1:

If you have two threads operating on the same object and both threads modify this object - then both threads keep losing their modifications to each other.

To make this object have two separate states for each thread, we declare this object or part of it ThreadLocal.

Of course, ThreadLocal is only beneficial here because both threads are sharing the same object. If they are using different objects, there's no need for the objects to be ThreadLocal.

2:

The second benefit of ThreadLocal, seems to be a side effect of how its implemented.

A ThreadLocal variable can be .set() by a thread, and then be .get() anywhere else. .get() will retrieve the same value that this thread had set anywhere else. We'll need a globally available wrapper to do a .get() and .set(), to actually write down the code.

When we do a threadLocalVar.set() - its as if its put inside some global "map", where this current thread is the key.

As if - someGlobalMap.put(Thread.currentThread(),threadLocalVar);

So ten layers down, when we do threadLocalVar.get() - we get the value that this thread had set ten layers up.

threadLocalVar = someGlobalMap.get(Thread.currentThread());

So the function at tenth level does not have to lug around this variable as parameter, and can access it with a .get() without worrying about if it is from the right thread.

Lastly, since a ThreadLocal variable is a copy to each thread, of course, it does not need synchronization. I misunderstood ThreadLocal earlier as an alternative to synchronization, that it is not. It is just a side effect of it, that we dont need to synchronize the activity of this variable now.

Hope this has helped.

Answer 4

This question is answered by the simple rule that a variable should be declared in the smallest possible enclosing scope. A ThreadLocal is the largest possible enclosing scope so you should only use it for data that is needed across many lexical scopes. If it can be a local variable, it should be.