Menu
I've read some posts and articles saying that we shouldn't declare java objects as volatile, because as a result, only the reference becomes volatile. Here are some examples:
link-1 link-2 link-3
What Sonar suggests is 'Non-primitive fields should not be "volatile"', however, it also suggests that the problem described refers to mutable objects 'Similarly, marking a mutable object field volatile means the object reference is volatile but the object itself is not'.
My question is: is it safe to declare java String as volatile?
891
Volatile variables have the visibility features of synchronized but not the atomicity features. The values of the volatile variable will never be cached and all writes and reads will be done to and from the main memory.
Unlike synchronized methods or blocks, it does not make other threads wait while one thread is working on a critical section. Therefore, the volatile keyword does not provide thread safety when non-atomic operations or composite operations are performed on shared variables.
When to use it? You can use a volatile variable if you want to read and write long and double variable automatically. It can be used as an alternative way of achieving synchronization in Java. All reader threads will see the updated value of the volatile variable after completing the write operation.
The volatile keyword is intended to prevent the compiler from applying any optimizations on objects that can change in ways that cannot be determined by the compiler. Objects declared as volatile are omitted from optimization because their values can be changed by code outside the scope of current code at any time.
Because String objects are immutable, only the reference is modified by operators like = and +=. Therefore, volatile is safe for String, as it applies to the reference itself. This applies to other immutable objects as well, just as it does to primitives.
Clarification:
+= itself is not thread-safe even on a volatile String, as it is not atomic and consists of a read followed by a write. If something affects the String object between the read and write, it may lead to unexpected results. While the resulting String will still be valid, it may have an unexpected value. In particular, some changes may "overwrite" other changes. For instance, if you have a String with the value "Stack " and one thread tries to append "Overflow" while the other tries to append "Exchange", there is a possibility that only one change will be applied. This applies to primitives as well. If you are interested, more details about this particular issue (mostly in the context of primitives) can be found here.
196
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
