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.
No. They all use the same object. However, the memory system design of a typical modern computer means that some of the state of an object may be held in machine registers and memory caches associated with more than one processor in a multi-processor system.
We can create multiple threads in java, even if we don't create any Thread, one Thread at least do exist i.e. main thread.
Multiple threads accessing shared data simultaneously may lead to a timing dependent error known as data race condition. Data races may be hidden in the code without interfering or harming the program execution until the moment when threads are scheduled in a scenario (the condition) that break the program execution.
Multiple threads can also read data from the same FITS file simultaneously, as long as the file was opened independently by each thread. This relies on the operating system to correctly deal with reading the same file by multiple processes.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With