Re: [android-developers] Re: Android LifeCycle and Singleton Instances

>public class MySingleton {

>  private static mySingleton = null;

>

>  public static synchronized getMySingleton() {

>    if (mySingleton == null) {

>      mySingleton = new MySingleton();

>    }

>    return mySingleton;

>  }

To be absurdly pedantic, this is indeed thread-safe but overwhelmingly so.  There's no need to enter a synchronized block if you know you're don't have to.  The pattern you used, 'checked locking,' gave rise to double-checked locking (check first if mySingleton is null, and if so then pay the price for synchronization).  But the <1.5 JVMs optimized this check out, so DCL in Java <1.5 was ineffective.

The correct way to do DCL in JVM 1.5 and after was to make mySingleton volatile (as Mark noted before).  But relying on a fixed JVM is no way to fix a development anti-pattern.

Initialization on-demand holder got rid of the synchronization requirements entirely, but you pay if initialization is operation-intensive.  For Android, proper DCL (with volatile singleton) works great, but still requires thread synchronization.  I'd argue that on a modern processor this would be ok, but mobile processors shouldn't rely on tons of processing power.  On the flip side, they also shouldn't rely on tons of heap space either but I think I'm getting too pedantic for my own good here.

tl;dr:

Pay basic attention to thread synchronization when trying to use standard patterns for common pitfalls.  Don't design for every possible scenario, but when you're debugging threading code keep these types of gotchas in mind.

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en