Hi,
I saw an interesting variation in
http://www.deelin.com/downloads/books/java_concurrency_in_practice.pdf
on Page 213 -
Listing 16.6. Lazy Initialization Holder Class Idiom.
@ThreadSafe
public class ResourceFactory {
private static class ResourceHolder {
public static Resource resource = new Resource();
}
public static Resource getResource() {
return ResourceHolder.resource ;
}
}
' The lazy initialization
holder class idiom [EJ Item 48] in Listing 16.6 uses a class whose
only purpose is to initialize the Resource. The JVM
defers initializing the ResourceHolder class until it is actually used
[JLS 12.4.1], and because the Resource is initialized
with a static initializer, no additional synchronization is needed.
The first call to getresource by any thread causes
ResourceHolder to be loaded and initialized, at which time the
initialization of the Resource happens through the static
initialize.'
The book is well worth reading btw.
Regards
On Jun 7, 10:57 am, Chris <[email protected]> wrote:
> >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
