Are local objects thread-safe?

I am working on a multi-threaded application where we have ensured that we avoid any static or instance variables (wherever possible) so that we do not need to synchronize (to improve performance).

I was under the impression that local variables are always thread-safe (because these variables are created on the stack), but now I realize that only the object references created locally will be thread-safe, but the object itself which is on the heap is not thread-safe.

As mentioned before we avoided creating any instance/class variables, but have instead created a lot of local objects. So does that mean that my application is still not actually thread-safe?

If yes, do I need to synchronize all the code which is multithreaded and where I am doing any operations on these objects? I have thousands of line of multi-threaded code in my application...putting all of it in synchronized blocks will impact my application's performance drastically...how should I go about this?

Appreciate any help/tips on doing this....

Regards,
Talib J

If an instance variable or static variable will only be accessed from a single thread, then it's intrinsically thread safe. If it will be accessed by multiple threads, then you have to synchronize access to it. It's that simple. The "local object" concept you've invented isn't really useful. It can be useful to speak of objects that are only accessed by one thread; but where they're created, and whether local or instance variables refer to them, doesn't really matter.

I don't think you have a thread-safty issue here. Local references are accessible only via one thread.

Where possible stay away from instance & static variables and use local variables or ThreadLocal objects.

If you really have to use instance or static varibales, then you can improve performance by having a block level synchronization as opposed to a method level.

[Talib]: we have ensured that we avoid any static or instance variables (wherever possible)

Hmmm... "ensure" sounds fairly absolute, but "wherever possible" sounds kind of vague. If there are places where your objects are accessible through anything other than local variables, then that's a possible concern for thread safety.

As you correctly note, local variables are themselves inherently thread-safe, but the objects they refer to are not necessarily thread-safe, if they are referenced by other threads in any way.

[Talib]: so that we do not need to synchronize (to improve performance).

I've seen a lot of poorly-written, unsafe code committed in the name of "improving performance". And in many cases, synchronization is not a big problem. Sometimes it is, true, but please don't assume that's the case without specific reason. Synchronization can be extremely useful; please don't avoid it entirely just because you've heard that it can be a performance problem.

Also, you say you "avoid" static or instance variables. Does this include the various objects whose safety you're now worrying about? If you have no static or instance variables, then I would say you are completely thread-safe. If the objects have class or instance variables (as most do), then you may have a problem. But from your description, it's hard to tell if this is the case or not.

[Talib]: If yes, do I need to synchronize all the code which is multithreaded and where I am doing any operations on these objects? I have thousands of line of multi-threaded code in my application...putting all of it in synchronized blocks will impact my application's performance drastically...how should I go about this?

There are a variety of possible answers to this, and in general it requires careful analysis of the code you're dealing with. Synchronization is one possible answer, but not the only one. Often the simplest way to make a class thread-safe is to make it immutable. If that doesn't work, then the second-simplest is to make all the methods synchronized. But that doesn't always work, e.g. if you mix mutable static and mutable instance data, or if you give your classes a crappy overly-find-grained API like those of Vector or StringBuffer (where the synchronization provided by Sun is next to useless). Other solutions possible in JDK 5 and later include volatile, atomic classes, and java.util.concurrent locks. If you can't isolate the data in each thread, then I recommend Java Concurrency in Practice as an excellent way to learn more about this topic.

Thank You for the replies so far...

So I understand that as far as I do not use static/instance variables in my multi-threaded code, my application is thread-safe. As I have not used any static variables or instance variables I should be all set!

But, I guess I did not explain my issue correctly...let me attempt to explain this one more time (I really want to understand how this works internally) -

- Method local Object references are created on the stack...but the actual objects are created on the heap.

- Each thread has its own stack, while the heap is shared between threads.

My question is -

e.g.

class ThreadedLocalMethods{

void process(){
int i=0;
Object obj = new Object();
}

}
In the above code snippet, my objects reference and object are defined at method level,
a. will each thread create a new object on the heap for this method local object or
b. it will only create new reference (Object obj) and share the same object (new Object()) on the heap amongst the threads?

If the answer is (b), how will this be thread-safe?

Appreciate your help with this!

Regards,
Talib J.

It's A. Actually, since JDK 6 the JVM sometimes creates objects on the stack rather than the heap. This only happens in cases where the JVM can determine that an object is only ever accessible from one thread - in this case, allocating it on the stack is very quick, and when the method completes, the object is promptly deallocated. This can give very fast GC.

Thanks Mike...that makes things crystal clear....

Regards,
Talib J

Ill take it a step further. Even if you call that method recursively, each call of the method will create a new reference to a new object. So its not that each thread will create new objects per method, but its each invocation of that method (even if by the same thread) will create new objects.

Except class variables, all the variables are thread safe. But if you defined the local variables that's very good. All local variables are thread safe. All local variables are created at the stack, for each thread there are separate stacks created. So thread cannt interfere with each other.