there have been already similar questions, but it doesn't answer the following problem. It's well known that values of fields are not necessarily immediately synchronized between threads. But is this also the case with local variables? Can the IllegalStateException be thrown?
public static void main(String[] args) {
final Thread mainThread = Thread.currentThread();
final Integer[] shared = new Integer[1];
new Thread(new Runnable() {
#Override
public void run() {
shared[0] = 1;
mainThread.interrupt();
}
}).start();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
if (shared[0] == null) throw new IllegalStateException("Is this possible?");
}
}
Indeed, the value of shared will be the same for all threads. But the value of shared[0] also involves reading an array element, and that array element, like a field, may be subject to a data race.
Are you sure about shared being safe?
Yes, the Java Language Specification writes:
Local variables (§14.4), formal method parameters (§8.4.1), and exception handler parameters (§14.20) are never shared between threads and are unaffected by the memory model.
At the JVM level, each thread has its own local variables. If an anonymous class accesses a local variable of an enclosing method, the compiler rewrites this code to pass the value of the variable as a constructor parameter to the inner class, which will store it in a final field (this rewriting is why the compiler requires such a variable to be effectively final and definitely assigned), and replaces all accesses to this variable by an access to the final field. Due to the special guarantees the Java Memory Model gives for final fields, this access is safe even if it the object reference is published through a data race, provided that such publication only occurs after the object has completed construction.
Local variables are perfectly thread safe, because there is no way to share them with another thread in the first place.
Your example code is a wholly different beast, because you are actually asking about the value of a shared array referred to by a local variable. Thats two different things. The variable is perfectly safe (cannot change anyway, since its final), the contents of the array it refers to is not synchronized in any way, so its also not safe.
Edit: To elaborate a bit about your variable named "shared"
When you declare a local variable as final, java allows you to refer to that variable in the scope of an anonymous class defined within the visibility scope of said variable (Put simpler: from within the block where the variable was defined).
What looks like one variable, are actually two variables. The one you declared exists in the main thread. The moment the anonymous "new Runnable()" is created, a copy of the variable contents is made (it actually becomes a hidden final field in the anonymous class). So when you refer to "shared" within the run()-method you do not access the local variable "shared" in the main thread.
You can verify this by looking at the class files your example creates (there are two, one for the class, and one for the anonymous class) and use javap -v for both to have a look at the byte code generated.
Local variables that are visible to more than one thread are not thread safe. They have to be accessed through the regular mechanisms (synchronized, volatile, immutable, etc.).
Normally, you create a local variable and use it within one thread. When you are ready, you must Safely Publish that variable. After that point, all the normal thread safe mechanisms must apply.
Yes, local variables are thread safe because the are allocated in the stack. Threads, however, don't share the stack. They are unique for each variable.
shared is thread safe, its the state of the object it refers to thats not safe.
It's possible your main thread could throw that exception but highly unlikely.
Telling the anonymous thread start() does not necessarily mean the VM/OS will actually start your thread before the next part of the program executes. So your main thread could enter the sleep before the other thread even starts. If it got interrupted from an external event inside that sleep before the thread set the value you could end up with null.
The sleep on the main thread almost positively ensures the anon thread will run before the test of shared.
Think about what would happen if you removed the sleep and checked for null immediately after starting the new thread. On my system shared[0] was null about 50% of the times I ran your program modified to have the sleep removed.
public static void main(String[] args) {
final Thread mainThread = Thread.currentThread();
final Integer[] shared = new Integer[1];
new Thread(new Runnable() {
public void run() {
shared[0] = 1;
mainThread.interrupt();
}
}).start();
if (shared[0] == null)
System.out.println("ouch");
}
The local variables are stored in the stack and not in the heap, so they are thread safe
Related
ThreadLocal in Java says that:
The ThreadLocal class in Java enables you to create variables that can only be read and written by the same thread. Thus, even if two threads are executing the same code, and the code has a reference to a ThreadLocal variable, then the two threads cannot see each other's ThreadLocal variables.
My question is: When we need to get a variable specific to a thread, can't we just declare that variable as a local variable inside a method? Because every thread has its own stack and thus it gets its own copy of variables. Am I missing something here?
ThreadLocal is is not an alternative to local variables. You use ThreadLocal for data that have to be static, but which must not be shared between threads.
static final ThreadLocal<MyFoo> myFoo =
ThreadLocal.withInitial(() -> new MyFoo());
If you have a ThreadLocal variable that is not static, then you're either doing something that's overly complicated, or you're doing something that's just plain wrong.
On the other hand, if you have any variable that is static (whether it is ThreadLocal or not), then you should be aware that that's a design choice that will limit your ability to test and grow the program.
ThreadLocal was meant for different purpose as per oracle documentation.
Have a look at intent of this class:
This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its get or set method) has its own, independently initialized copy of the variable. ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).
Below code block generates unique identifiers local to each thread. A thread's id is assigned the first time it invokes ThreadId.get() and remains unchanged on subsequent calls.
import java.util.concurrent.atomic.AtomicInteger;
public class ThreadId {
// Atomic integer containing the next thread ID to be assigned
private static final AtomicInteger nextId = new AtomicInteger(0);
// Thread local variable containing each thread's ID
private static final ThreadLocal<Integer> threadId =
new ThreadLocal<Integer>() {
#Override protected Integer initialValue() {
return nextId.getAndIncrement();
}
};
// Returns the current thread's unique ID, assigning it if necessary
public static int get() {
return threadId.get();
}
}
Coming back to your query:
When we need to get a variable specific to a thread, can't we just declare that variable as a local variable inside a method? Because every thread has its own stack and thus it gets its own copy of variables. Am I missing something here?
Yes. You are missing something here.
The scope of variable , which was declared inside a method ends with the method life cycle.
In case of ThreadLocal varaibles, each thread holds an implicit reference to its copy of a thread-local variable as long as the thread is alive and the ThreadLocal instance is accessible. You can re-enter the thread multiple times in it's life cycle and still you can retain the variable.
ThreadLocal could be best choice in scenarios when state needs to be
associated with thread e.g. for global variables (if semantic permits)
because ThreadLocal keeps values of variables confined to a thread; so
when a thread T runs get on it, thread T gets the value which was set
by itself not by any other threads.
from this article.
Local variable can be utilized when variable is inside thread's class itself and scope is local to each thread. Contrary to this, when variable is outside local scope and exists as part of shared code and semantic permits to keep copy of this variable per thread and not single copy for all threads then ThreadLocal is utilized.
Are multiple threads guaranteed to see the same version of a shared object to which they have a reference? Here is a code sample:
public static void main(String[] args) {
final AtomicBoolean flag = new AtomicBoolean(false);
new Thread(){
public void run() { possibly read and mutate flag }
}.start();
new Thread(){
public void run() { possibly read and mutate flag }
}.start();
while (!flag.get()) {
Thread.yield();
}
}
To be clear, I am wondering whether writes by the child threads to the shared object are seen by the parent and sibling threads.
Are multiple threads guaranteed to see the same version of a shared local variable in their scope.
In general, it depends on what you mean by "the same version". It also depends on the nature of the variable (e.g. how it is declared and initialized) ... and on how the threads use it.
(In general, Java doesn't do "versions" of variables. A thread accessing a shared variable or object will either see the latest state, or it won't. If it sees a state that isn't the latest state, then there are no guarantees as to what it will see. In particular, it may see something that doesn't directly correspond to any notional version of the object ... due to word-tearing and other cache-related memory artefacts.)
In your example you are using a final local variable within an inner class (in this case you have two anonymous inner classes). When you do that, the compiler creates a corresponding synthetic variable in the inner class that is initialized with the value of the variable in the method scope. The compiled inner class then refers to the value of the synthetic variable instead of the original variable.
In your example, it is guaranteed that the inner classes (e.g. your threads) will see the same (reference) value as in the original variable. Furthermore, it is guaranteed that they will (at least initially) see a consistent snapshot of whatever object it is that it references. (And since it is an AtomicXxxx class, it will always be consistent for all threads that can access it. Guaranteed.)
OK, so what about other cases:
If flag was a static or instance field that was also final, then we wouldn't have synthetic variables, and each nested class would be referencing the same shared variable. But it would all still work.
If flag was a static or instance field and it wasn't final, but nothing changed the field (after creating of the threads) then it would still be OK. (Though you could argue that this is fragile ... because something could change the field.)
If flag was a static or instance field and it wasn't final or volatile, then the threads would initially see the same state as the parent thread. But if either the original thread or any of the other threads changed the variable (etcetera), then the others are not guaranteed to see the new state ... unless they respective threads synchronize properly.
I would like to know if changes to flag made in one thread are seen immediately by the other two threads.
As I said above, it depends ...
In your example, the answer is "yes", because you use a final reference to AtomicBoolean.
If you had declared flag as a boolean and marked it as volatile, then the answer would be "yes".
If you had declared flag as a boolean and non-volatile, then the answer would be "no".
If flag was a final reference to an ordinary object with a mutable non-volatile boolean field, then the answer would also be "no". (The threads would all see the same object, but they wouldn't consistently see the latest state. The solution would be to use synchronized getters and setters, or equivalent.)
Yes, the two threads share the same final AtomicBoolean which is a class used to set the truth value. The variable flag itself can't be recreated because it is final. But you can perform actions on it to set value. Just like a final int[] can't be assigned to different size but you can change the value of what's inside.
final AtomicBoolean flag = new AtomicBoolean(false);
new Thread(){
public void run(){
try {
Thread.sleep(100);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
flag.set(true);
}
}.start();
new Thread(){
public void run(){
flag.set(false);
}
}.start();
Thread.sleep(200);// comment this line, you see different results
System.out.println(flag);
In this case, yes. The Java Language Specification says that calling Thread.start() synchronizes-with all previous actions on the calling thread:
An action that starts a thread synchronizes-with the first action in the thread it starts.
This creates a happens-before relationship between all writes on your main thread (including any writes the constructor of the AtomicBoolean made to initialize itself) are made visible to the thread your main thread started.
A call to start() on a thread happens-before any actions in the started thread.
So basically you are good to go. Your AtomicBoolean object is visible to both threads, and they both see the same object.
This pattern is called Safe Publication, btw. You use it to safely publish an object you create (like your AtomicBoolean) so that other threads can see it. (And yes, Thread.start() isn't on the list there of ways to safely publish an object because Thread.start() isn't general enough. But it's the same idea, and works the same way.)
The local variable is not shared1, and being final means that there would be no worry of it changing even if it was the case. (A question about member variables would result in a different response although, excluding constructor leakage, a final member would provide the same guarantees.)
The same object is shared across threads; it will be the same object and will adhere to the defined AtomicBoolean contract.
A boolean value that may be updated atomically. See the java.util.concurrent.atomic package specification for description of the properties of atomic variables.
In short the package documentation specifies the following which in turn guarantees happens-before relationships.
get has the memory effects of reading a volatile variable.
set has the memory effects of writing (assigning) a volatile variable.
There are many questions relating to the thread-safey of volatile (and AtomicXYZ objects), eg. see Is a volatile int in Java thread-safe? and Is AtomicBoolean needed to create a cancellable thread?
1 Anonymous types, including Java 8 lambdas, do not create closures/lexical bindings to variables in scope and as such are not capable of sharing local variables; rather variables are synthesized with the value of the final (or effectively final) variable from the enclosing scope which is bound when the anonymous type is instantiated.
If I have one instance of an object A and it has an instance method foo() with only variables created and used in that method is that method thread safe even if the same instance is accessed by many threads?
If yes, does this still apply if instance method bar() on object A creates many threads and calls method foo() in the text described above?
Does it mean that every thread gets a "copy" of the method even if it belongs to the same instance?
I have deliberately not used the synchronized keyword.
Thanks
Yes. All local variables (variables defined within a method) will be on their own Stack frame. So, they will be thread safe, provided a reference is not escaping the scope (method)
Note : If a local reference escapes the method (as an argument to another method) or a method works on some class level or instance level fields, then it is not thread-safe.
Does it mean that every thread gets a "copy" of the method even if it belongs to the same instance
No, there will be only one method. every thread shares the same method. But each Thread will have its own Stack Frame and local variables will be on that thread's Stack frame. Even if you use synchronize on local Objects, Escape Analysis proves that the JVM will optimize your code and remove all kinds of synchronization.
example :
public static void main(String[] args) {
Object lock = new Object();
synchronized (lock) {
System.out.println("hello");
}
}
will be effectively converted to :
public static void main(String[] args) {
Object lock = new Object(); // JVm might as well remove this line as unused Object or instantiate this on the stack
System.out.println("hello");
}
You have to separate the code being run, and the data being worked on.
The method is code, executed by each of the threads. If that code contains a statement such as int i=5 which defines a new variable i, and sets its value to 5, then each thread will create that variable.
The problem with multi-threading is not with common code, but with common data (and other common resources). If the common code accesses some variable j that was created elsewhere, then all threads will access the same variable j, i.e. the same data. If one of these threads modifies the shared data while the others are reading, all kinds of errors might occur.
Now, regarding your question, your code should be thread safe as long as your variables are defined within bar(), and bar() doesn't access some common resource such as a file.
You should post some example code to make sure we understand the use case.
For this example:
public class Test {
private String varA;
public void doSomething() {
String varB;
}
}
If you don't do anything to modify varA in this example and only modify varB, this example is Thread Safe.
If, however, you create or modify varA and depend on it's state, then the method is NOT Thread Safe.
As I understand it, Java does not have true closures. You can pass a function by chaperoning them with a class; however, not only is it verbose but also (because of Java's memory model) any references in the anonymous class to variables defined in the environment where it was constructed are passed as copies. The language encourages us to remember this by only allowing anonymous classes to refer to final variables.
Which brings me to this code snippet I found in Bloch's Effective Java:
import java.util.concurrent.*;
public class StopThread {
private static boolean stopRequested;
public static void main(String[] args)
throws InterruptedException {
Thread backgroundThread = new Thread(new Runnable() {
public void run() {
int i = 0;
while (!stopRequested)
i++;
}
});
backgroundThread.start();
TimeUnit.SECONDS.sleep(1);
stopRequested = true;
}
}
First, I expected the compiler to complain because stopRequested is nonfinal and I refer to it inside the anonymous class. My compiler didn't complain.
Second, I expected the program to loop forever since, well, Java doesn't support closures and if the anonymous class really is referring to the actual stopRequested variable from the environment it was constructed (and not a simple copy) then it seems like we have a closure here. Joshua Bloch also said the program loops forever on his computer. But mine runs for about a second and exits.
What part of the memory model am I misunderstanding?
The key thing you're missing is that the anonymous class is a nested class. As such, it has an implicit reference to the instance of the containing class, and therefore members of the class.
It is only local variables which are required to be final for use by anonymous classes.
It loops for me and the reason is to do with CPU cache, not anonymous methods.
With this it always exits:
private volatile static boolean stopRequested;
First, I expected the compiler to complain because stopRequested is
nonfinal and I refer to it inside the anonymous class. My compiler
didn't complain.
stopRequested is a static variable.
Second, I expected the program to loop forever since, well, Java
doesn't support closures and if the anonymous class really is
referring to the actual stopRequested variable from the environment it
was constructed (and not a simple copy) then it seems like we have a
closure here. Joshua Bloch also said the program loops forever on his
computer. But mine runs for about a second and exits
stopRequested is not a volatile variable. Therefore, it may run forever(flag hoisting optimization. (run with -server mode) ).
Therefore, the below code
while (!stopRequested)
i++;
can be reordered as
boolean status = !stopRequested;
while(status)
i++;
What you're misunderstanding is that only local variables are passed as copies to an inner class, because those exist on the stack and thus will be gone when the method call returns.
True closures "magically" provide a context for all captured variables to survive. But for non-local variables, this is not really necessary; they exist on the heap as part of their object or class, so Java permits them to be non-final and still used in an inner class.
What I think Bloch's code example is supposed to demonstrate is a completely different thing: different threads may have local copies of any variable (local, instance, or static) in their CPU's cache, and changes one thread makes may not be visible to other threads for an arbitrarily long time. To ensure that local copies are synced, the change either has to happen in a synchronized block/method, or the variable has to be declared volatile.
You can access fields via a reference (implicitly to OuterClass.this) or static field by class. It is only non-final variables you cannot reference. Note: If this final reference points to something mutable you can change it.
final int[] i = { 0 };
new Thread(new Runnable() {
public void run() {
i[0] = 1;
}
}).start();
while(i[0] == 0);
System.out.println("i= " + i[0]);
stopRequested is not a local variable it is a static variable so it need not be final. The program may loop forever because stopRequested is not declared volatile and thus it is not guaranteed that changes to stopRequested made by one thread will ever be seen in another thread. If you declare stopRequested volatile the program will not run forever.
Expecting the compiler to complain in this example is unusual. Usual expectation is that the program will terminate soon after start. Bloch shows that it may not be the case (which usually astonishes the reader) and then explains why. Bloch is a fairly advanced reading, you may want to try other books on Java first.
Classic example of a simple server:
class ThreadPerTaskSocketServer {
public static void main(String[] args) throws IOException {
ServerSocket socket = new ServerSocket(80);
while (true) {
final Socket connection = socket.accept();
Runnable task = new Runnable() {
public void run() {
handleRequest(connection);
}
};
new Thread(task).start();
}
}
}
Why should the Socket be declared as final? Is it because the new Thread that handles the request could refer back to the socket variable in the method and cause some sort of ConcurrentModificationException?
In this case, the variable must be final to be used inside the anonymous Runnable implmentation.
This is because that object will exist when the variable has already gone out of scope and has thus disappeared. The object gets a copy of the variable. In order to hide this, the variable must be final so that nobody can expect changes in one copy to be visible to the other.
Consider this example:
class A {
B foo() {
final C c;
return new B() {
void goo() {
// do something with c
}
}
}
}
// somewhere else in the code
A a = new A();
B b = a.foo();
b.goo();
If c was not final, when you reach b.goo(), it would point to junk, since that c would be garbage-collected - A local variable after the end of a method call.
You need to declare it final, not only should. Without that, the compiler cannot use it in the anonymous Runnable class implementation.
declaring a method variable final means that it's value can't change; that it can only be set once. how does that apply in this context?
i have known about this restriction with anonymous classes for some time, but i never quite understood why. i see that no one else really does either from the responses so far. some googling turned up the below which i think does a good job of explaining it.
An anonymous local class can use local
variables because the compiler
automatically gives the class a
private instance field to hold a copy
of each local variable the class uses.
The compiler also adds hidden
parameters to each constructor to
initialize these automatically created
private fields. Thus, a local class
does not actually access local
variables, but merely its own private
copies of them. The only way this can
work correctly is if the local
variables are declared final, so that
they are guaranteed not to change.
With this guarantee in place, the
local class is assured that its
internal copies of the variables
accurately reflect the actual local
variables.
credit to:
http://renaud.waldura.com/doc/java/final-keyword.shtml#vars
certainly not obvious and something that i think the compiler really should be hiding from developers.
Local variables are not shared between threads. (A local variable is a part of the activation record, and each thread has its own activation record).
Since connection is a local variable, it's not possible to share it between threads. Since its not shared between threads, you need to make it final, so it doesn't matter that it's a local variable (it can be seen more like a constant value).
It is not intended to solve ConcurrentModificationException. Any local variable used inside a method-nested-class (such as an anonymous inner class) must be declared as final. See a similar discussion from the last week here:
method local innerclasses accessing the local variables of the method
Actually in case of threads there is a minor contribution here for thread safety; there will be no visibility issues on the final variable between the threads. However, this does not guarantee thread safety at all.