title: Memory effects of synchronization in Java
body: <p><a href="http://www.cs.umd.edu/users/pugh/java/memoryModel/jsr-133-faq.html#synchronization" rel="noreferrer">JSR-133 FAQ</a> says:</p>
  
  <blockquote>
    <p>But there is more to synchronization
    than mutual exclusion. Synchronization
    ensures that memory writes by a thread
    before or during a synchronized block
    are made visible in a predictable
    manner to other threads which
    synchronize on the same monitor. After
    we exit a synchronized block, we
    release the monitor, which has the
    effect of flushing the cache to main
    memory, so that writes made by this
    thread can be visible to other
    threads. Before we can enter a
    synchronized block, we acquire the
    monitor, which has the effect of
    invalidating the local processor cache
    so that variables will be reloaded
    from main memory. We will then be able
    to see all of the writes made visible
    by the previous release.</p>
  </blockquote>
  
  <p>I also remember reading that on modern Sun VMs uncontended synchronizations are cheap. I am a little confused by this claim. Consider code like:</p>
  
  <pre><code>class Foo {
      int x = 1;
      int y = 1;
      ..
      synchronized (aLock) {
          x = x + 1;
      }
  }
  </code></pre>
  
  <p>Updates to x need the synchronization, but does the acquisition of the lock clear the value of y also from the cache? I can't imagine that to be the case, because if it were true,   techniques like lock striping might not help. Alternatively can the JVM reliably analyze the code to ensure that y is not modified in another synchronized block using the same lock and hence not dump the value of y in cache when entering the synchronized block?</p>