In Java, do I need to synchronize methods that do not use static or class variables?

Question

Do methods that use only local variables inside have problems with threads? Somewhere it was mentioned that a method with local variables is copied to each frame of the thread stack to work and does not need synchronization for a multi-threaded implementation if it does not use a class or static references / variables?

Answer 1

If your method works only with parameters and locally defined (as opposed to class members), then there are synchronization problems that you need to worry about.

But...

This means that any mutable link types you use must live and die only within your method. (Optional reference types are not a problem here). For example, this is not a problem:

int doSomething(int myParameter) { MyObject working_set = new MyObject(); interim = working_set.doSomethingElse(myParameter); return working_set.doSomethingElseAgain(interim); } 

A MyObject instance is created inside your method, does all its work in your method, and coughs up blood, expecting the GC to be disconnected when you exit your method.

This, on the other hand, can be a problem:

 int doSomething(int myParameter) { MyObject working_set = new MyObject(); interim = working_set.doSomethingElse(myParameter); another_interim = doSomethingSneaky(working_set); return working_set.doSomethingElseAgain(another_interim); } 

If you don’t know exactly what is going on in doSomethingSneaky() , you may need synchronization. In particular, you may need to synchronize the working_set operations, since doSomethingSneaky() can store a reference to your local working_set object and pass it to another thread while you are still doing stuff in your method or in working_set . Here you need to be more protective.

Unless, of course, you only work with primitive types, even calling other methods, passing these values ​​together, this is not a problem.

Answer 2

Are there methods that use only local variables inside that don't suffer from any threading issues?

Truth in a very simplified sense, but makes it clear - I think this is true only if:

• such a method uses only local variables that are primitives or references to mutable instances that otherwise could not be accessed outside the method in any other way.

• this method calls only those methods that are thread safe.

Some methods may be violated:

• A local variable can be initialized to point to an object that is also accessible outside the method. For example, a local variable may point to a singleton ( Foo bar = Foo.getSingleton() ).

• A local instance containing a local variable can "leak out" if the instance is passed as an argument to an external method that stores a reference to the instance.

• A class without instance variables and only with a single method without local variables can still invoke the static method of another class that is not thread safe.

Answer 3

The question is very general, so please do not expect any specifics from my answer.

1_ We need to be more careful about static methods than using instance methods.

2_ @Justmycorrectopinion is correct, but some of the terms he described need to be more developed to be perfect. (Even if the static method only works with a local variable, there is still a chance of a race condition.)

3_ There are simple rules for me that have helped me analyze thread safety.

Understand if all the components encapsulated inside it are common or not. Thus, the simplest solution is to reduce the volume of the entire variable and increase the volume, if absolutely necessary, and if the component performs a mutation on the object, it is usually not thread safe.

4_ Use instrumental support to perform static thread safety code analysis. (The idea has a checkthread plugin).

5_ Never use a static method to mutate an object. If calling a static variable causes a mutation of the object, the developer simply bypasses OOPS.

6_ Always document thread safety. Remember that some method may not need to be synchronized during development, but it can be easily done without streaming.

7_ Last, but probably most important, make sure most of your objects are immutable. In my experience, most of the time I never had to change many of my objects. (In rare cases when it is necessary to change the state of an object, protective copying / creating a new object is almost always better.)

Answer 4

You do not need to worry about local variables. However, instance variables are something to take care of.