I've learned that every class byte code is been loaded to the memory once for each class loader, thus when a thread is executing the byte code of some method, and another thread comes along?
1 thread -> 1 instance - of class Foo == no problem.
X threads -> 1 instance - of class Foo == need to be handled this is clear.
X threads -> X respective instances - of class Foo == ????
should I make sure nothing is messed up in the method? if the method uses a instance level variables, can I be sure it will use the right ones?
Update:
I see my question was not clear to some, here is an example with numbers
I have an object of class type Foo which has no synchronization!!
I have 5 instances of that Foo with 5 threads running for/in each of them, and accessing instance level parameters for example:
class FOO {
private SomeObject someObject=new SomeObject();
private void problematicMethod(Data data) {
someObject.doSomethingWithTheData(data);
data.doSomethingWithSomeObject(someObject);
// any way you want it use the data or export the data
}
}
I'm asking is there a problem here, since there is only 1 byte code of this class and 5 instances of this object that access this byte code, so if I want to prevent them from overlapping on the same byte code, what should I do?
Thanks, Adam.
I've learned that every class byte code is been loaded to the memory once for each class loader, thus when a thread is executing the byte code of some method, and another thread comes along?
Class loading and byte code is irrelevant here. Byte code is a set of assembly-like instructions which the JVM interprets and compiles into native machine code. More than one thread can safely follow the instruction sets encoded into the byte code.
1 thread -> 1 instance - of class Test, no problem
Mostly correct. If there is only a single Thread, then there is not any immediate need to make anything thread safe. However, ignoring thread safety would limit growth and re-usability.
X threads -> 1 instance - of class Test, need to be handled this is clear.
Well, yes, for thread visibility reasons and to ensure that critical regions are executed atomically, using synchronization or locking techniques is fairly important. Of course, it all depends right?! If your class doesn't have state (instance or class variables), then you don't really need to make it thread-safe (think utility class like Java's Executors
, Arrays
, Collections
classes).
X threads -> X respective instances - of class Test, ????
If each thread has its own instance of class Test, and no single instance is shared amongst more than one thread, then this is the same as your first example. If an instance of Test is referenced by two or more threads, then this is the same as your second example.
if the method uses a class level variables, can I be sure it will use the right ones?
Class variables ARE static
variables in Java. There are already two answers posted which emphasize the importance of using synchronized
to prevent more than one thread from modifying a class variable at the same time. Not mentioned is the importance of using synchronized
or volatile
to make sure you don't see a stale version of the class variable.