Re: Local variables in Java
ankur wrote:
So I was wondering how local variables are handled in Java. If the
same method is called upon many objects ( of same type) I guess the
method calls happen one after the another so that for each method call
new local variables get defined , but at any point in time there is
only one copy of all local variables defined ( while method calls are
happening). Correct ???
Not correct. Each invocation of the method, even if through the same object,
gets its own "stack frame". "Automatic variables", or "method-local
variables", the ones declared with method scope, are created specifically
within a particular stack frame. If objects are created for those variables
entirely within the method they will not collide.
If the method variables point to "wider" objects, such as those shared by the
class or between threads, there are issues of shared data.
Instance variables, the ones that belong to the whole object, are another
matter. As long as different objects are running their methods there is no
collision. In other words:
Foo a = new Foo();
Foo b = new Foo();
new Thread( a ).start();
new Thread( b ).start();
Even though both Foo objects are running their run() methods at the same time,
there is no collision between instance variables, because separate instances
are running.
However, if the /same/ instance is shared between threads, than any state
(values of its attributes) could collide.
Class variables, those declared 'static', have tremendous risk of collision,
because they are shared amongst all instances across all threads (within a
single ClassLoader context).
public class Foo implements Runnable
{
private static volatile Foo latestFoo;
public void run()
{
latestFoo = this;
doMore();
latestFoo.doEvenMore();
}
....
}
But then how would this work in a multicore system ( more than one
processor, same harddrive,same RAM) system if same method call is
executed by same JVM in parallel on the two cores for two different
objects ( of same class) ?
No problem unless both objects access shared data, as above. Shared data must
be protected by appropriate concurrency constructs.
--
Lew