我非常同意你的观点，我在实现一个绝对是超多线程，实时要求性非常高的调度系统时，大量使用静态方法，目的只有一个－》速度。事实证明效果非常好。
其实，静态函数，新建对象，等个有个的适用范围，充分了解它们，扬长避短才是道
用静态方法并不一定提高了你的效率,除非你的方法都是线程安全的,那这样又和采用singleton之类的有多少区别呢?
如果不是线程安全,EJB式的对象池也许更有效率,因为对象是被反复复用的,没有创建对象和GC的开销,这样显然比你在每次方法调用里面初始化非线程安全的对象或者采用同步锁定的方式效率好.
何况大量用静态方法显然不是好的OO设计,为什么需要singleton,为什么需要工厂类(比如EJB home),为什么需要组件接口...
用静态方法并不一定提高了你的效率,除非你的方法都是线程安全的,那这样又和采用singleton之类的有多少区别呢?
如果不是线程安全,EJB式的对象池也许更有效率,因为对象是被反复复用的,没有创建对象和GC的开销,这样显然比你在每次方法调用里面初始化非线程安全的对象或者采用同步锁定的方式效率好.
何况大量用静态方法显然不是好的OO设计,为什么需要singleton,为什么需要工厂类(比如EJB home),为什么需要组件接口...
singleton就一定性能低么？thinkhard
如果一个需要初始化的非线程安全的对象静态方法，在换成用对象池来实现的话，池化对象在调用方法的时候就是不是就不需要重新初始化非线程安全的对象呢？如果不是的话，上一次的方法调用会不会影响到下一次调用。
对象池没有创建对象和GC的开销吗？当并发调用数量大于对象池上限的时候呢？另外，还有池化对象的开销以及对象钝化时的开销呢，虽然这些不是影响调用效率的东西。显然对象池只适用于一些重量级对象。
静态方法和singleton的确很类似，完全可以用singleton替代。
我不认为轻量级对象有必要为了线程安全而用到对象池，宁可每次new一个对象来保证线程安全，因为轻量级对象的创建和销毁的开销是很小的，滥用对象池只会把系统结构复杂化。
A stateless session bean is a bean that holds conversations that span a single
method call. They are stateless because they do not hold multimethod conversations
with their clients. After each method call, the container may choose to
destroy a stateless session bean, or recreate it, clearing itself out of all information
pertaining to past invocations.
不是说有实例变量的SB都是状态会话bean，SLSB也可以有实例变量，只是SLSB每次调用后，容器都会销毁或者重建，而状态会话bean则保留。
就你这段代码来说，非线程安全的是XMLParser
public class Foo
{
private static Foo foo = new Foo();
private Foo(){}
public Foo getInstance()
{
return foo;
}
public void bar()
{
XMLParser xmlp = new XMLParser();
xmlp.parse(...);
}
}
这样Singleton实现会有问题吗？如果你说XMLParser开销太大，那是另外一回事，那应该对XMLParser进行池化处理，而不要怪到Singleton实现上。
EJB的好处就是不用你自己去对每个非线程安全的对象进行池化...
我不继续说了...