>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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
