Thread basics

Question

This may seem like a very simple question -
The JVM spec suggests that threads have their own local copy of variables, which is copied between the main memory.
In terms of variables that are local to a method, do these variables reside locally within the context of each thread.
As an example :
public class A
  public void methodA(SomeObject so)
    int i = so.getMethodResult();
}The question is - if two methods were accessing the method concurrently, would any operation on the local variable i require synchronizing, of if all of the operations within methodA are purely local, would multiple threads interfere with each thread's local copy of those variables?
Thank You
Jim

Answer 1

No. There is a dual dichotomy here.
Variables local to the method are allocated at the beginning of the method, deallocated at the end, and belong to the specific invocation of the method. Two threads calling the same method will get independent copies of the method-local variables and no synchronization of any kind is needed. This is perhaps clearer if you consider a local variableString s = new String("Some dynamically created string" + hashCode());The string is separately allocated as part of execution of the new method anytime the object or class method is called. If the object or class method is called four times, four separate String references will be allocated (and eventually garbage-collected). It doesn't matter if two of the invocations happened concurrently in two different threads.
The other side of the dual dichotomy is itself a dichotomy (that's what makes it "dual"). Consider the following variation on your classpublic class A
  int i = 12; // Here we have an instance variable
  public void methodA(SomeObject so)
    // Set an object instance variable rather than a local variable
    i = so.getMethodResult(); // Now the implications are broader
}Suppose this class is used in two different threadsA a = new a();
// The same instance a of object A is passed to two different threads...
// Thread 1 code
// Invoke methodA on our reference to the object of class A created in the parent code
thread1sa.methodA(new SomeObject(17); // thread1sa refers to the same object as thread2sa
// Thread 2 code
// Invoke methodA on our reference to the object of class A created in the parent code
thread2sa.methodA(new SomeObject(23); // thread1sa refers to the same object as thread2saNow i might need to be protected by a synchronize block because it could be an index into a shared array that could be corrupted by unprotected concurrent access. This is simply a coding consideration inherent with any multithreaded code
But, in addition, there are also JVM/underlying-hardware-implementation considerations to deal with, even if no modifications are made to shared data. This is the other half of the second dichotomy and is, I think, the implication that prompted your original question. Consider the following codepublic class A
  int i = 12; // The shared instance variable
  public void methodA(SomeObject so)
    // Set an object instance variable rather than a local variable
    i = so.getMethodResult();
  public int sayHowBigIsi()
    // Return where we are
    if (i < 7)
      Thread.Sleep(3000); // This raises the possibility that instance variable i will change while we're not looking
      System.out.println("i is" + i);
    else
      System.out.println("i is greater than 7");
}The original intent of methodB is to print the value of i if it is less than 7, but there is a possibility that between the time i is tested and the time it is printed, another thread could change it to something else, causing the println to print out an incorrect value of i. This is because the generated bytecode keeps local copies of variables for performance (and in fact some values could on the bare metal level be kept in even more volatile storage, such as registers) and these local copies aren't guaranteed to be kept updated at all times. That is, the value of i printed by the println could be an old copy of i that is now wrong.
One solution would be to enclose the code that uses i in a synchronize block. This would alleviate the problem, but would inevitably incur a thread bottleneck at that point, and since no data is actually modified, control as strict as is provided by synchronize is not necessary. Instead, Java provides the volatile keyword, which signals to the Java compiler and JVM that a variable may be updated asynchronously and that implementation-local copies should either not be kept, or always be refreshed before use. This also incurs a performance cost, but does not result in a thread bottleneck.public class A
  volatile int i = 12; // The shared instance variable now made volatile
  public void methodA(SomeObject so)
    // Set an object instance variable rather than a local variable
    i = so.getMethodResult();
  public int sayHowBigIsi()
    // Return where we are
    if (i < 7)
      Thread.Sleep(3000); // This raises the possibility that instance variable i will change while we're not looking
      // ...but now there's no problem because i is volatile.
      System.out.println("i is" + i);
    else
      System.out.println("i is greater than 7");
}