Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should getters and setters be synchronized?

private double value;  public synchronized void setValue(double value) {     this.value = value; } public double getValue() {     return this.value; } 

In the above example is there any point in making the getter synchronized?

like image 367
DD. Avatar asked Jul 12 '12 19:07

DD.


People also ask

Do getters () or setters () require synchronization?

To elaborate, if one wants to obtain the most recent version of value in a multi-threaded application, both the getter and setter should be synchronized.

Why are getters and setters bad?

Getter and setter methods (also known as accessors) are dangerous for the same reason that public fields are dangerous: They provide external access to implementation details. What if you need to change the accessed field's type? You also have to change the accessor's return type.

Do getters and setters need to be static?

Yes, getters/setters can be made static based on your need.

Should you always use getters and setters?

Using getters and setters, is always, in my opinion good practice. One thing you should avoid is to have external entities mess with the internal structure of your class at will. Typical example, consider having a dateOfBirth parameter.


Video Answer


1 Answers

I think its best to cite Java Concurrency in Practice here:

It is a common mistake to assume that synchronization needs to be used only when writing to shared variables; this is simply not true.

For each mutable state variable that may be accessed by more than one thread, all accesses to that variable must be performed with the same lock held. In this case, we say that the variable is guarded by that lock.

In the absence of synchronization, the compiler, processor, and runtime can do some downright weird things to the order in which operations appear to execute. Attempts to reason about the order in which memory actions "must" happen in insufflciently synchronized multithreaded programs will almost certainly be incorrect.

Normally, you don't have to be so careful with primitives, so if this would be an int or a boolean it might be that:

When a thread reads a variable without synchronization, it may see a stale value, but at least it sees a value that was actually placed there by some thread rather than some random value.

This, however, is not true for 64-bit operations, for instance on long or double if they are not declared volatile:

The Java Memory Model requires fetch and store operations to be atomic, but for nonvolatile long and double variables, the JVM is permitted to treat a 64-bit read or write as two separate 32-bit operations. If the reads and writes occur in different threads, it is therefore possible to read a nonvolatile long and get back the high 32 bits of one value and the low 32 bits of another.

Thus, even if you don't care about stale values, it is not safe to use shared mutable long and double variables in multithreaded programs unless they are declared volatile or guarded by a lock.

like image 197
Konrad Reiche Avatar answered Sep 27 '22 19:09

Konrad Reiche