title: Is there any point in using a volatile long?
body: <p>I occasionally use a <code>volatile</code> instance variable in cases where I have two threads reading from / writing to it and don't want the overhead (or potential deadlock risk) of taking out a lock; for example a timer thread periodically updating an int ID that is exposed as a getter on some class:</p>
  
  <pre><code>public class MyClass {
    private volatile int id;
  
    public MyClass() {
      ScheduledExecutorService execService = Executors.newScheduledThreadPool(1);
      execService.scheduleAtFixedRate(new Runnable() {
        public void run() {
          ++id;
        }
      }, 0L, 30L, TimeUnit.SECONDS);
    }
  
    public int getId() {
      return id;
    }
  }
  </code></pre>
  
  <p>My question: Given that the JLS only guarantees that 32-bit reads will be atomic is there any point in <strong>ever</strong> using a volatile long? (i.e. 64-bit).</p>
  
  <p><strong>Caveat</strong>: Please do not reply saying that using <code>volatile</code> over <code>synchronized</code> is a case of pre-optimisation; I am well aware of how / when to use <code>synchronized</code> but there are cases where <code>volatile</code> is preferable.  For example, when defining a Spring bean for use in a single-threaded application I tend to favour <code>volatile</code> instance variables, as there is no guarantee that the Spring context will initialise each bean's properties in the main thread.</p>