|
锁定老帖子 主题：如此使用单例模式！
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-01-27
楼主的根本谈不上单例，楼上的是正解。
|
| 返回顶楼 | |
|
发表时间：2009-01-27
最后修改：2009-01-27
单例的意思就是说在应用程序中只存在一个此类的实例，不管使用什么方法，能保证这个条件就是单例，没必要非得按照什么格式来写。一个单例中只要没有全局变量，那么在业务处理时也就没什么线程不安全的问题，问题只是存在第一次调用getInstance()方法时，大不了在系统加载时就调用此类的getInstance()方法，就自然不会产生线程安全的问题。JAVA程序的性能瓶颈大多在数据库，我想我不会在乎使用synchronized这0.1秒的性能损失的，而且这0.1秒不知道可以创建一个多么大的对象了。
这个单例在使用上的问题在于楼主说的“贫血设计”上。UserRule这个类看起来应该是个session类，不同于一般“util”类，它是负责业务操作的。如果程序很简单、规则是单一的这么写也无可厚非。一旦碰到稍微复杂的业务逻辑，不能使用多态那么对依赖于此类的其他类维护起来就是灾难性的，所谓的发散式修改会一直伴随在这个类的生命周期中。以上只是在假定此类是业务处理类而非工具类的基础上做出，要从设计的角度来评价这个类的好坏还得看他在应用中所处的位置和所起的作用，这是楼主没有给的。 从这个类中我并没看出什么性能问题来，这样设计会让此类在应用生命周期中只创建一次，能提升性能。真正的性能问题要综合全局来看才能有结论。 |
| 返回顶楼 | |
|
发表时间：2009-01-29
精神可嘉!
|
| 返回顶楼 | |
|
发表时间：2009-01-30
zozoh 写道 # public static UserRule getInstance() {
# if (instance == null) { # instance = new UserRule(); # } # return instance; # } 应该写成 public static UserRule getInstance() { if (instance == null) { synchronized(UserRule.class){ if (instance == null){ instance = new UserRule(); } } } return instance; } 以保证多个线程访问的安全 Java中使用单例模式中必须像这样进行双重检查，否则会出现多线程问题 |
| 返回顶楼 | |
|
发表时间：2009-01-31
看来你对单例的认识太简单了.
|
| 返回顶楼 | |
|
发表时间：2009-01-31
vampire423 写道 zozoh 写道 # public static UserRule getInstance() {
# if (instance == null) { # instance = new UserRule(); # } # return instance; # } 应该写成 public static UserRule getInstance() { if (instance == null) { synchronized(UserRule.class){ if (instance == null){ instance = new UserRule(); } } } return instance; } 以保证多个线程访问的安全 Java中使用单例模式中必须像这样进行双重检查，否则会出现多线程问题 太扯了。 双重检查只是为了避免以后访问此方法时的性能问题——因为只有第一次创建实例时，才需要同步锁。 自己看看去吧：http://www.ibm.com/developerworks/cn/java/j-dcl.html |
| 返回顶楼 | |
|
发表时间：2009-02-02
好像不是单例吧， 你再理解理解？
|
| 返回顶楼 | |
|
发表时间：2009-02-02
ych516 写道 kimmking 写道 引用 性能是测试出来的 不是你想出来的
赞这句 同意哈～ 继续支持 |
| 返回顶楼 | |
|
发表时间：2009-02-03
ferry2174 写道 单例的意思就是说在应用程序中只存在一个此类的实例，不管使用什么方法，能保证这个条件就是单例，没必要非得按照什么格式来写。一个单例中只要没有全局变量，那么在业务处理时也就没什么线程不安全的问题，问题只是存在第一次调用getInstance()方法时，大不了在系统加载时就调用此类的getInstance()方法，就自然不会产生线程安全的问题。JAVA程序的性能瓶颈大多在数据库，我想我不会在乎使用synchronized这0.1秒的性能损失的，而且这0.1秒不知道可以创建一个多么大的对象了。
这个单例在使用上的问题在于楼主说的“贫血设计”上。UserRule这个类看起来应该是个session类，不同于一般“util”类，它是负责业务操作的。如果程序很简单、规则是单一的这么写也无可厚非。一旦碰到稍微复杂的业务逻辑，不能使用多态那么对依赖于此类的其他类维护起来就是灾难性的，所谓的发散式修改会一直伴随在这个类的生命周期中。以上只是在假定此类是业务处理类而非工具类的基础上做出，要从设计的角度来评价这个类的好坏还得看他在应用中所处的位置和所起的作用，这是楼主没有给的。 从这个类中我并没看出什么性能问题来，这样设计会让此类在应用生命周期中只创建一次，能提升性能。真正的性能问题要综合全局来看才能有结论。 看到说到点子上的了 另外在这个例子里面贫血也没有什么不好的 |
| 返回顶楼 | |
|
发表时间：2009-02-04
我刚开始学设计模式，但是觉得更像是简单工厂，最起码UserRule的Constructor没有私有化。
|
| 返回顶楼 | |
