Singleton 是邪恶的

http://c2.com/cgi/wiki?SingletonsAreEvil

http://weblogs.asp.net/scottdensmore/archive/2004/05/25/140827.aspx

反方观点：
http://www.mattberther.com/2004/05/000481.html

javaWorld导航虚伪迷惑的Singletion单态（单例）模式:
http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html#resources

Picocontainer作者宣称Singleton是反模式，根本不是模式见：
http://www.picocontainer.org/Singleton+antipattern

本站关于使用Singleton在多线程场合下可能出现死锁的讨论见
http://www.jdon.com/jive/thread.jsp?forum=121&thread=17133

以上资料整理在这个帖子中，供大家学习参考用。

如果在J2EE的范围内做一次正式的投票，我敢打赌Factory Method、Prototype、Singleton和Bridge绝对是在被淘汰之列，因为它们做的事情已经完全被支持Dependency Injection的容器包办了，程序员再也不需要知道这些模式。所以说呢，“Singleton是邪恶”的或者是一个非伪命题，不过更可能是一个伪问题，因为……谁还需要Singleton呢？你只需要PicoContainer或者Spring Core。

应该说singleton在多线程下会存在问题比较准确。spring在创建对象的时候还是有两种模式，这似乎是无法回避的。

这跟Spring有什么关系呢？如果说有的话，恰好是Spring的“singleton=true”的配置让我们再也不必自己实现Singleton，再也不必面对Singleton的种种evil。毕竟你终归是要使用全局唯一实例的对象的。

不能说是上当，那是自己使用的问题，我使用了这么久、这么多次的Singleton，有台多处使用Singleton服务器（不是b/s,是c/s的）已经自己运行了很久了，从来没有碰到什么陷阱之类的问题，Singleton有很多使用方式，看你怎么用，不要把某些责任推给一个设计模式。

说到陷阱，程序处处都是陷阱，如果你使用的不当的话

对于Martin Fowler的贫血模型我是不敢苟同的，我们一直使用实体Bean作为Domain Model的实现方式之一；Session Bean作为Transaction Script实现，设计模式、可复用的以POJO嵌入Transaction Script使用，这样实践起来至少我觉得不错。这篇文章的观点和实践与我非常符合：http://personal.inet.fi/koti/jukka.tamminen/objects/extreme%20OO.htm
当然，本贴不是讨论这个问题的，以后再辟新贴讨论，Martin提出贫血模型会让很多人疑惑和彷徨。

我同意Spring提供的Singleton模式之选，实际是提供全局唯一变量，但是这种情况下，也要注意在多线程情况下的死锁（条件：在Web层中使用+写操作+synchronized）。

服务器已经使用几个月了没有重启过，用户虽然不是很多，但是也不少

唔，人家的程序跑了N年还不算实践经验，非得拿loadrunner测过才算实践经验，这是哪门子的道理？这话听起来有点这味道：有人骑电动车上班，你说“电动车不安全，不信你到沪杭高速上跑个时速150，看它掉不掉链子。”

那好，我就发表点专业观点。我现在批评Azure_2003了：你的application不能在0.5秒内响应请求，所以它实时性不强。你压根就不该用什么J2EE做什么web application，你应该用VC来做，才能保证实时性呢。Azure_2003笑了：拜托，我的用户根本就不需要那么高的实时性啊。

什么叫专业？作为职业软件开发者（而不是编程爱好者），满足用户的需求就是最大的专业。人家Azure_2003的application在那边run了几个月，用户100多天每天在那边用都没有抱怨，我们这些空口说白话的人倒在这里凭空抱怨，这难道是专业的态度吗？

就象Singleton模式，我掌握Piocontainer之前，项目很着急，没有时间研究Ioc容器怎么替代Singleton模式，还不是使用SIngleton模式上阵抗着，等以后重整，所以，还有网友问我，JiveJdon里为什么图片上传使用Singleton呢。