1

Does JVM guarantee to cache not volatile variable ?

Can a programer depend upon on JVM to always cache non-volatile variables locally for each thread.

Or JVM may or may not do this, thus a programer should not depend upon JVM for this.

Thanks for the answers in advance.

Amar Jaiswal
  • 23
  • 3
  • There is no way a programmer *can* depend on it. There is no correct code you can write that would operate differently if it was and wasn't the case, – user207421 May 15 '17 at 07:12
  • http://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.4.1. –  May 15 '17 at 07:17
  • Plus: consider giving some feedback to the people who spend their time answering your question; either by accepting one of the answers, or leaving a comment here or there in case you have further questions. – GhostCat May 16 '17 at 07:36

3 Answers3

4

No. The JVM doesn't guarantee "caching" of non-volatile fields. What implementations of JVM guarantee is how volatile fields should behave. Caching of fields is non-standard (unspecified) and can vary from JVM to JVM implementation. So, you shouldn't really rely on it (even if find out, by some way that some data is being cached by a thread)

TheLostMind
  • 35,966
  • 12
  • 68
  • 104
1

The java language spec is pretty clear about volatile:

The Java programming language provides a second mechanism, volatile fields, that is more convenient than locking for some purposes.

A field may be declared volatile, in which case the Java Memory Model ensures that all threads see a consistent value for the variable (§17.4).

That's it. You got a special keyword defining this special semantic. So, when you think the other way round: without that special keyword, you can't rely on any special semantics. Then you get what the Java Memory Model has to offer; but nothing more.

And to be fully correct - there is of course Unsafe, allowing you to tamper with memory in unsafe ways with very special semantics.

Community
  • 1
  • 1
GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • True. I don't think that is relevant in the context of the question; but to have a complete answer I added that part. Just wondering: is there anything else missing that would help making the answer upvote-worthy? – GhostCat May 16 '17 at 07:35
1

The recommended pattern if you need a snapshot of a field is to copy it to a local variable. This is commonly used when writing code that makes heavy use of atomics and read-modify-conditional-write loops.

the8472
  • 40,999
  • 5
  • 70
  • 122
  • if it were a primitive - yes. but for a reference this is `extreme bytecode optimization`. http://stackoverflow.com/questions/2785964/in-arrayblockingqueue-why-copy-final-member-field-into-local-final-variable In some cases (not sure here) it is a `volatile read` that will have memory barriers. – Eugene May 16 '17 at 07:26
  • Well, a non-volatile field still may or may not change under your nose if it's accessed in a concurrent manner. Copying it to a local var will guarantee that it does not. Of course OP would already be doing something wrong if a non-volatile variable gets modified concurrently. – the8472 May 16 '17 at 07:49
  • well yes, but I've never seen a case where you might actually want that in practice. Because the object that you are pointing to in the local method might be already `stale` by the time you want to use it. The example that you provided does that: it checks that between the time it has copied the reference and actual usage, `tail` has not change. – Eugene May 16 '17 at 18:54