specific question on java threading + synchronization

I know this question sounds crazy, but consider the following java snippets:

Part - I:

 class Consumer implements Runnable{
      private boolean shouldTermin开发者_StackOverflow社区ate = false
      public void run() {
          while( !shouldTerminate ){
               //consume and perform some operation.
          }
      }

      public void terminate(){
        this.shouldTerminate = true;
      }
    }

So, the first question is, should I ever need to synchronize on shouldTerminate boolean? If so why? I don't mind missing the flag set to true for one or two cycles(cycle = 1 loop execution). And second, can a boolean variable ever be in a inconsistent state?(anything other than true or false)

Part - II of the question:

class Cache<K,V> {

  private Map<K, V> cache = new HashMap<K, V>();

  public V getValue(K key) {
     if ( !cache.containsKey(key) ) {
       synchronized(this.cache){
          V value = loadValue(key)
          cache.put(key, value);
       }  
      } 
     return cache.get(key);
  }
}

Should access to the whole map be synchronized? Is there any possibility where two threads try to run this method, with one "writer thread" halfway through the process of storing value into the map and simultaneously, a "reader thread" invoking the "contains" method. Will this cause the JVM to blow up? (I don't mind overwriting values in the map -- if two writer threads try to load at the same time)

---

Both of the code examples have broken concurrency.

The first one requires at least the field marked volatile or else the other thread might never see the variable being changed (it may store its value in CPU cache or a register, and not check whether the value in memory has changed).

The second one is even more broken, because the internals of HashMap are no thread-safe and it's not just a single value but a complex data structure - using it from many threads produces completely unpredictable results. The general rule is that both reading and writing the shared state must be synchronized. You may also use ConcurrentHashMap for better performance.

---

Unless you either synchronize on the variable, or mark the variable as volatile, there is no guarantee that separate threads' view of the object ever get reconciled. To quote the Wikipedia artible on the Java Memory Model

The major caveat of this is that as-if-serial semantics do not prevent different threads from having different views of the data.

Realistically, so long as the two threads synchronize on some lock at some time, the update to the variable will be seen.

I am wondering why you wouldn't want to mark the variable volatile?

---

It's not that the JVM will "blow up" as such. But both cases are incorrectly synchronised, and so the results will be unpredictable. The bottom line is that JVMs are designed to behave in a particular way if you synchronise in a particular way; if you don't synchronise correctly, you lose that guarantee.

It's not uncommon for people to think they've found a reason why certain synchronisation can be omitted, or to unknowingly omit necessary synchronisation but with no immediately obvious problem. But with inadequate synchronisation, there is a danger that your program could appear to work fine in one environment, only for an issue to appear later when a particular factor is changed (e.g. moving to a machine with more CPUs, or an update to the JVM that adds a particular optimisation).

---

1. Synchronizing shouldTerminate: See Dilum's answer
2. Your bool value will never be inconsistent state.
3. If one thread is calling cache.containsKey(key) while another thread is calling cache.put(key, value) the JVM will blow up (by throwing ConcurrentModificationException) something bad might happen if that put call caused the map the grow, but will usually mostly work (worse than failure).