From 649b14adf69f322ef203195dc03b7632c6c76772 Mon Sep 17 00:00:00 2001 From: mbirkenkamp Date: Sat, 14 Mar 2015 16:59:02 +0100 Subject: [PATCH] Update App.java additional explanation about the risks of using the singleton pattern, as requested by @iluwatar --- singleton/src/main/java/com/iluwatar/App.java | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/singleton/src/main/java/com/iluwatar/App.java b/singleton/src/main/java/com/iluwatar/App.java index ec3f0ab7e..557820048 100644 --- a/singleton/src/main/java/com/iluwatar/App.java +++ b/singleton/src/main/java/com/iluwatar/App.java @@ -3,10 +3,16 @@ package com.iluwatar; /** * * Singleton pattern ensures that the class (IvoryTower) can have only one - * existing instance per java vm instance and provides global access to that it. - * + * existing instance per java classloader instance and provides global access to it. + * * http://stackoverflow.com/questions/70689/what-is-an-efficient-way-to-implement-a-singleton-pattern-in-java * + * The risk of this pattern is that bugs resulting from setting a singleton up in a distributed environment can + * be tricky to debug, since it will work fine if you debug with a single classloader. Additionally, these + * problems can crop up a while after the implementation of a singleton, since they may start out synchronous and + * only become async with time, so you it may not be clear why you are seeing certain changes in behaviour. + * + * http://stackoverflow.com/questions/17721263/singleton-across-jvm-or-application-instance-or-tomcat-instance */ public class App {