I had an interview few weeks back, and I was asked to write a code with Setters and Getters. I had written the following code;

// Just an example

Class ABC{
    private int num;

    public void setNum(int givenNum){
        this.num = givenNum;

    public int getNum(){
        return num;

    public ABC(){
        num = 0;

    public static void main(String [] args){
        ABC object1 = new ABC();
        ABC object2 = new ABC();



Now I was told, that "object1" can change the value for "object2.Num". But I was not in agreement with this, I believe another thread which has access to object2 can change the value of object2.Num but not object1.

In the above case, I would have synchronized the setter method, or use the synchronized block inside the setter method while setting/changing the value, but I could not understand the concept of object1 changing the value of object2.Num.

I was just curious if I was missing on something. If so I would really appreciate any help regarding the same.

  • 1
    Sounds to me that you might be better off not working for them... Jul 5, 2013 at 14:49
  • @DrakeClarris Yeah, that was a surprise for me, when the question was asked that way. I just wanted to confirm if I was thinking in the right direction, or was I missing something. Thanks.
    – JNL
    Jul 5, 2013 at 16:08

4 Answers 4


If class ABC can be accessed from more than one thread, you will need to synchronize both setNum and getNum. Until you leave a synch block, the new value of num need not be available to any other thread. Until you enter a synch block, changes so made in another thread will not be visible in this one. And in Java (but not C#), both both blocks must (according to the rules, the JLS) be synched on the same object. (Of course, if you make the methods synchronized, they'll synch nicely on this instance of ABC.)

This might have been the point your interviewer was making.

(And making 'num' volatile (private volatile int num) would do much the same thing.)

  • I agree to your point that synchronizing the method would be thread safe. But little confused on synchronizing the getter? Do you mean the getNum() method should be synchronized so that say if thread A accesses "Num" thread B should not be able to change the value of "Num"?
    – JNL
    Jul 5, 2013 at 19:19
  • @JNL: No. If thread B changes the value of num and getNum() isn't synchronized, thread A might not see the change when it calls getNum. To put it crudely, leaving a synch block forces changes out of registers and caches and into main memory. Entering a synch block forces the thread to refresh all its caches and registers. Leave out either step and one thread's changes may not be be seen by the other thread. Personal experience suggests there's a rather variable delay (nothing to hours) between B making a change and the change being seen by A. Jul 5, 2013 at 19:32
  • Appreciate you sharing the experience. But now coming back to the question, how would "object1" change "object2.Num". I believe it still cannot be done, correct?
    – JNL
    Jul 5, 2013 at 19:36
  • 1
    @JNL: Correct. Joachim Sauer says it best. I do wonder if there isn't a misunderstanding somewhere. People sometimes confuse objects and threads. They may have been trying to talk about two threads accessing the same object. (Indeed, without synchronization, as I've explained, the two threads might see completely different objects--or at least different sets of data. Rather hard to say. Jul 5, 2013 at 19:48

If all you have is a reference to object1, then no, you can't change object2.num.

The only thing that comes somewhat close to what you describe would be things like this:

public void swap(ABC other) {
  int num = this.num;
  this.num = other.num;
  other.num = num

Suche a code could modify two ABC objects: this (i.e. the object on which it's called) and other (the parameter). But this doesn't have anything to do with multithreading either.

  • Agree, that only if "object1" was referenced to "object2", then object1 would change object2.Num. Also the above is just a simple example, say if the above Num implies "Balance" of a bank account, so multithreading would come into picture. At that point synchronizing the setter or adding a synchronized block to {this.num = givenNum; } would sove the issue? Thats correct right?
    – JNL
    Jul 5, 2013 at 14:19
  • 1
    synchronizing a setter alone rarely solves any issues. Because the setter call alone is usually not what you want to happen atomically. What you want (in the case of a balance) is that two modifications of separate bank accounts are atomical, which means you need a single synchronized block about both setter calls. Jul 5, 2013 at 14:21
  • So do you recommend Synchronized block for those lines of code who would be changing/setting the balance value?
    – JNL
    Jul 5, 2013 at 14:29

Synchronization is not the relevant concept here. You synchronize things to prevent errors caused by the unforeseen order of actions caused by interleaving different threads. The classical example is decreasing the balance of one bank account and increasing another by the same amount, which can lose information (money) if not done atomically. But this code merely assigns an integer, which is already atomic, so the point is not inconsistency.

They were probably talking about access control and the somewhat surprising fact that private means "private to all instances of the class" and not "private to to the owning instance only" in java. object2 can change the value of a field in object1 if it has a reference to object1. But this has nothing to do with synchronization.

  • I agree with your point. I gave the interviewer the same explanation, but then the Interviewer said, how about "Synchronization", So I believed he wanted to move into that direction just to see if I knew that concept. But I once again told him, that I still don't think "object1" can change "object2.Num" unless we do object1=object2 and then go ahead.
    – JNL
    Jul 5, 2013 at 14:08

that "object1" can change the value for "object2.Num"

That's impossible, what is possible though is one thread to set a value on either of the instances (object1 or object2) and before using it another thread to set a different value on the same instance.

If each thread has to work with its own values then change the num type from int to ThreadLocal<Integer> without changing the getter and setter signature.

If each thread has to work with same value then change the num type from int to AtomicReference<Integer> and the getter and setter signature.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.