Q:

Is it safe to access an object X within a synchronized block defined on object Y?

There are answers to the question if accessing the state of the object is safe within the synchronized method or block. My question : Is it safe to access an object X within a synchronized block, where synchronized block is on another object Y and  there are multiple writers Threads present for X ?
public class X{
    private int value = 0;
    /** set method will be invoked by multiple threads**/
    public void set(int v){
       this.value = v;
   }
   public int value(){
       return value;
   }
}

public class Tester{
    private final Object Y = new Object();
    public void test(X x){
        synchronized(Y){
            System.out.println(x.value()); // is it guaranteed that x.value will be read from memory and not from the current thread's cache ?
        }
    }
}      

I know state of the object on which synchronized block is defined is safe to access without a need for volatile, but what if the synchronized block is defined on another object ?

A:

IMO you are asking the wrong question. The Java Memory Model doesn't concern itself with objects and classes. It only talks about the visibility of variables.
The visibility rule for synchronized(o) blocks is pretty simple: Whatever one thread does to any variable before it leaves a synchronized(o) block is guaranteed to be visible to any other thread after the other thread subsequently enters a block that is synchronized on the same instance, o.
So, in your example, if you have some X my_x, and some thread A does this:
synchronized(Y) {
    my_x.set(55);
}

Then when some other thread B subsequently calls tester.test(my_x), thread B will see the value that was stored by thread A.
On the other hand, if thread A calls my_x.set(...) without synchronizing on Y, then Java does not promise when, if ever, the thread B will see the change.

Note: Your program openly invites failure by making the lock object, Y, a private member of the Tester class, while making the test(X) function public. That practically begs you (or some other programmer) to make the mistake of calling tester.test(some_random_X) where the some_random_X was set by another thread that did not lock Y.

