应该是布鲁诺
每一种技术 比方说 singleton 都会有这样那样的局限性，也有这样那样的技术贡献，关键是如何在具体项目中应用正确，我觉得这才是正道。我是一个实际的人，觉得没有实际工作价值的东西，或者不能在实际工作中产生实际工作效率的东西，必然要被淘汰，或者进行进化，以适应市场的需要。singleton可能就是这样的一个例子，在某些场合中，随着系统的复杂化以及发展，可能不是太适合，需要使用其他的手段予以解决新暴露出来的问题。也有可能在一些项目中，确实产生的比较好的效果，但将来也有可能出现问题，但是任何技术总是会不断使用，然后问题暴露，变得不适应需求，而后改变，或者淘汰，这是一个规律。
不过对于gigix的论证我个人觉得有一些问题，比如说在J2EE范围下，许多模式就淘汰了。我不太理解这句话是什么意思。确切地说，不是这些模式被淘汰了，只是容器代替了这些工作而已，如果不用容器，不用IOC，难道就不是J2EE，或者还是说，容器实现的本身就没有用到过那些模式么？
模式，本身只是解决问题的一个固定的思路或者思维，滥用它自然是错误的，但是，说被淘汰就不太能理解了。我们只能说，在IOC容器的存在下，这些模式没有使用的必要而已。
>什么叫专业？作为职业软件开发者（而不是编程爱好者），满足用户的需>求就是最大的专业。人家Azure_2003的application在那边run了几个月，>用户100多天每天在那边用都没有抱怨，我们这些空口说白话的人倒在这
>里凭空抱怨，这难道是专业的态度吗？
呵呵 我觉得这个说得挺好
static methodA(){}
static methodB(){}
static methodC(){ X x = new X(); }
}
在Spring中生成这样一个Singleton的类会引起死锁么？会有性能问题么？
这正是Spring所建议使用单例的地方吧？
class SingletonClass{
methodA(){}
methodB(){}
}
这个类在Spring中配置成 singleton= true 会有什么性能问题么？那些不存在读写互斥的类都可以配置成singleton吧？
如果提供service的Bean中不保存状态，只是提供方法调用。那么这些方法都改成static的有什么不妥呢？那么Spring提供的单例也是多余的了么？
jdon上说Spring的singleton会有性能损失，是指的是生成singleton的lazy方式么？
――――――――――――――――――――――――――――――
最近和以前的同事，在MSN上也争论了Singleton的问题，不过他不用JAVA，用C#，做NET。呵呵，不也一样。C#,有Singleton关键字，用了一个Lock来锁定，是比较保险的Singleton,Java中很少有这么用，至少在我看到的Singleton实现中很少用到Lock的，那么是否是伪Singleton了？实际上简单pravate,能保证Singleton了？求证中.....
_______________
“除非是无状态的可以用单列,省下的就不要用了”
VO，BO的问题，是VO,Singleton了还是BO了？场景了？Struts的Actionform 是VO，还是BO了？写如逻辑了？呵呵，一连串的思索！
――――――――――――――――――――――――――――――
如果照gigix所说，只是借用Singlonton之名，在DI一个VO或BO的时候？
――――――――――――――――――――――――――――――――
EJB3，不支持Singlonton，用对象池？可否讲的更深入了？
――――――――――――――――――――――――――――――――
不知banq哥有否解决
无限的可能性 -- 语冰夏虫
在应用程序放在双机上时，使用静态的全局变量引发的问题: