CODEWITHSUNDEEP
javamultithreadingstaticthread-safetymultiple-instances
Gemei
Gemei

Reputation: 15

Thread-Safety and Instances in java

I have been reading quite a bit about thread safety, and am confused about if have multiple instance of an object would affect the thread safety or not. Here is an example to elaborate:
Say we have a class called RGBColor that the user would set the values of the Red, Green and Blue and then return the color.

Public Class RGBColor {
    private int red;
    private int green;
    private int blue;
    Public RGBColor(int red, int green, int blue){
       this.red = red;
       this.green = green;
       this.blue = blue;
    }
    Public void setColor(int red, int green, int blue){
       this.red = red;
       this.green = green;
       this.blue = blue;
    }
    Public RGBColor getColor(){
       return this;
    }
}

Now if the the program has created multiple instances of that class for example:

RGBColor red = new RGBcolor(255,0,0);
RGBColor blue = new RGBcolor(0,0,255);

Now here is the question. Are these instances of the class are totally independent? I mean would thread safety would be an issue? After all as i understand they should be completely different objects that have different allocations in RAM.

Another question is if the variables and the methods are static eg.

Public Class RGBColor {
    private static int RED;
    private static int GREEN;
    private static int BLUE;

    Public static void setColor(int red, int green, int blue){
       RED = red;
       GREEN = green;
       BLUE = blue;
    }
}

How are the static variables and methods would be handled when it comes to thread safety?

ps: i have updated the second example as it was flawed.

Upvotes: 1

Views: 1031

Answers (4)

davidxxx
davidxxx

Reputation: 131346

Are these instances of the class are totally independent? I mean would thread safety would be an issue?

Instances are independent between them, yes.
Thread safety concern is as multiple threads may access in a concurrent way to one instance and which one of them or both make some modifications on the instance state.

For example suppose you create an instance of RGBColor and multiple threads can manipulate this instance.
Now, we ask you as requirement that the setColor() invocation should not interleave with other invocation of itself.
There, you have a race condition and you should handle this.
To handle it, you could for example use a synchronized statement that surrounds setColor() statements and make the field volatile to ensure that the memory of each thread be always updated :

private volatile int red;
private volatile int green;
private volatile int blue;
...
public void setColor(int red, int green, int blue){
   synchronized (this){
     this.red = red;
     this.green = green;
     this.blue = blue;
   }
}

How are the static variables and methods would be handled when it comes to thread safety?

For static variables, in the same way as for instance variables.

For instance methods, thread safety can be achieved on a lock on the instance.
For static methods, it should be achieved on a lock on the class itself.

Upvotes: 2

Nipun Alahakoon
Nipun Alahakoon

Reputation: 2862

Answer to your first question. YES the different objects will have separate hashcodes in JVM. But when you considering a transaction where same object access at the same time you will have to use thread safety over the objects (if there is object modifications) you can use

synchronized

modifiers in methods.to ensure thread safety. if and only if the same object access at the same time by different systems.

Answer to your second question. static or non static objects in java will be thread safe only when the modifiers of that object will be synchronized. Apart from that you can use a thread pool and countdownlatches to efficiently handle objects with many threads

Upvotes: 1

Nathan Hughes
Nathan Hughes

Reputation: 96385

In the first case where the objects have instance variables, the objects exist independently of each other. Modifying one doesn’t affect the others.

In the second case, static fields belong to the class, not to any one object. Constructors are for creating instances? Not for populating static variables, having a constructor for this case is confusing and unnecessary. Also using this in getColor doesn’t work, there is no instance of RGBColor in a static method.

For the first case, if you take away the setters and make the instance variables final then your objects will be immutable, making them safe to use in multiple threads.

For the second case, multiple threads can overwrite each other’s work and there is nothing to make the changes visible to other threads. (Just because a thread changes a value doesn’t mean it’s visible to other threads immediately.)

If you really want one set of values in this class scope, you could make an immutable object and assign it to a static volatile variable so that the updates would be atomic and visible to other threads.

Upvotes: 1

GhostCat
GhostCat

Reputation: 140427

You shouldn't worry about "thread safety" here. Because you are getting even more basic stuff wrong. There is no point in having multiple instances of one class - when the corresponding fields are all static.

In other words: in your second example, there is no sense in having a red and a blue RGBColor object - because all objects that you instantiate would be overwriting each other! Last one wins ...

Beyond that, in your first example: the method setColor() gives potential to thread safety issues. Because that method makes it possible that you end up in an inconsistent state (when two threads invoke the setter on the same object at the "same" time - but with different arguments).

In other words:

  • first spend some time learning what static is about, and why your second code input is so grossly "bad"
  • then understand: thread safety matters as soon as "shared" data is accessible to more than one thread. Because then you have to make sure that read/write operations on that "shared" data all always well-defined.

Upvotes: 1

Related Questions