[concurrency-interest] Race condition on singleton

David Holmes davidcholmes at aapt.net.au
Mon Dec 13 00:18:43 EST 2010

I'm assuming from the way Guy stated it that it was the map.put that caused
the NPE, not some internal action within the put() code.

Of course stacktraces would make it clearer.

David Holmes
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Justin T.
  Sent: Monday, 13 December 2010 3:10 PM
  To: Guy Korland
  Cc: concurrency-interest
  Subject: Re: [concurrency-interest] Race condition on singleton

  I'm surprised with all the replies that no one commented on the lack of
synchronization on accessing the contents of the map. That can easily cause
NPEs from within map.put(k, v), or almost any other arbitrary behavior for
that matter.


  On Thu, Dec 9, 2010 at 4:44 AM, Guy Korland <gkorland at gmail.com> wrote:


    We found a very strange pattern that seems like contradicting the Java
Memory Model.
    It seems like a class that is maintained as singleton doesn't have its
constructor fully initialized!
    See the code example bellow.

    public class MyClass{

      private static final MyClass = new MyClass();

      private final HashMap map;

      private MyClass(){
          map = new HashMap();

      public void put(Object k, Object v){

      static public getMyClass(){
        return myClass;

    And when we invoke the following:


    We get a NullPointerException on the "map.put(k,v);", meaning the
map==null !?!?

    Any ideas?

    Guy Korland

    Concurrency-interest mailing list
    Concurrency-interest at cs.oswego.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20101213/2365c47a/attachment.html>

More information about the Concurrency-interest mailing list