|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-11-26
按照你的说法，对于login事件来说，什么是正常事件流，什么是异常事件流那？难道还有第二种划分方法吗？
|
| 返回顶楼 | |
|
发表时间：2004-11-26
gigix 写道 flyingbugs 写道 你说在 循环中new对象 能不出现巨大的性能问题么？？
恐怕事情和你的想象恰恰相反。我前面已经说过了，现在的JVM都采用了分代式的垃圾收集，如果你创建大量的对象，用完之后立即抛弃，GC的范围将被局限在“新一代”。而且这些对象的引用非常简单，单凭对代码的静态分析就可以找到它的存活域，不需要更多的运行时动态侦测。这样一来，GC的范围更小，执行速度更快，当然效率更高。如果你pool大量的对象，很可能导致它们进入“老一代”，导致的直接后果就是扩大GC的范围，而这种“大GC”（相对于只收集“新一代”的“小GC”而言）对性能的损害是相当严重的。所以对于大多数的业务对象，你就应该需要用的时候再创建，用完就丢弃，不应该去pool它，这才是性能最高的做法。如果业务对象的初始化时间很长，你通常应该把需要初始化的部分移到对象之外，以共享资源的形式来保存它们。 插一句，现在流行的架构中action(struts or webwork)---->service------->DAO----->>.....这种分层调用中，service及DAO 的生命期由spring管理，出于性能考虑，要不要采用单例？？？？？？ |
| 返回顶楼 | |
|
发表时间：2004-11-26
ruby 写道 插一句，现在流行的架构中action(struts or webwork)---->service------->DAO----->>.....这种分层调用中，service及DAO 的生命期由spring管理，出于性能考虑，要不要采用单例？？？？？？ 这不应该从性能角度考虑，应该考虑的是功能。一个组件应该是singleton还是prototype，完全取决于它有怎样的功能，性能是最不重要的考虑。 |
| 返回顶楼 | |
|
发表时间：2004-11-26
gigix：
你根本没有明白我的意思。 呵呵 很多情况下 在循环中new出来的对象往往可以通过单列或者static来代替。 建议你去看看Rotor，看看vm到底是怎么实现的。 |
| 返回顶楼 | |
|
发表时间：2004-11-26
gigix：
你就应该需要用的时候再创建，用完就丢弃，不应该去pool它，这才是性能最高的做法。 哈 太好了，这样我们再也不需要容器啦，webcontainer，ejbcontainer都见鬼去吧。 |
| 返回顶楼 | |
|
发表时间：2004-11-26
flyingbugs 写道 gigix：
你根本没有明白我的意思。 呵呵 很多情况下 在循环中new出来的对象往往可以通过单列或者static来代替。 建议你去看看Rotor，看看vm到底是怎么实现的。 我想到底应该new一个对象还是应该singleton，这应该由程序的语意来决定，而不是由尚未可知的性能因素来决定。举个例子，如果是无状态的业务对象，想都不用想就知道应该在循环之外创建一个实例，每次循环都使用同一个。但凡是在循环内部new对象，必定是因为这个对象有状态，而且对象状态跟循环的局部状态有关。当然你可以想办法把这个状态抽取出来，然后减少new对象的次数，但这样一来你将得到一个不贴切的对象，能节约多少性能却只能说是尚未可知。在我看来这是得不偿失的。 至于static，那就更不是一回事了。如果你认为对象还可以用static代替，我们的讨论可以到此为止了。如果你不愿意承认你不懂Java，那我承认我不懂Java好了。 |
| 返回顶楼 | |
|
发表时间：2004-11-26
baichenhong 写道 robbin给的资料链接你有没有好好看过那?
http://www-900.ibm.com/developerWorks/cn/java/j-jtp05254/index.shtml Rod Johnson 是 J2EE Design and Development （请参阅 参考资料） 的作者，这是我所读过的关于 Java 开发，J2EE 等方面的最好的书籍之一。他采取一个不太激进的方法。他列举了异常的多个类别，并且为每个类别确定一个策略。一些异常本质上是次要的返回代码（它通常指示违反业务规则），而一些异常则是“发生某种可怕错误”（例如数据库连接失败）的变种。Johnson 提倡对于第一种类别的异常（可选的返回代码）使用检查型异常，而对于后者使用运行时异常。在“发生某种可怕错误”的类别中，其动机是简单地认识到没有调用者能够有效地处理该异常，因此它也可能以各种方式沿着栈向上扩散而对于中间代码的影响保持最小（并且最小化异常淹没的可能性）。 第 39 条：只为异常条件使用异常。也就是说，不要为控制流使用异常，比如，在调用 Iterator.next() 时而不是在第一次检查 Iterator.hasNext() 时捕获 NoSuchElementException。 第 40 条：为可恢复的条件使用检查型异常，为编程错误使用运行时异常。这里，Bloch 回应传统的 Sun 观点 —— 运行时异常应该只是用于指示编程错误，例如违反前置条件。 第 41 条：避免不必要的使用检查型异常。换句话说，对于调用者不可能从其中恢复的情形，或者惟一可以预见的响应将是程序退出，则不要使用检查型异常。 第 43 条：抛出与抽象相适应的异常。换句话说，一个方法所抛出的异常应该在一个抽象层次上定义，该抽象层次与该方法做什么相一致，而不一定与方法的底层实现细节相一致。例如，一个从文件、数据库或者 JNDI 装载资源的方法在不能找到资源时，应该抛出某种 ResourceNotFound 异常（通常使用异常链来保存隐含的原因），而不是更底层的 IOException、SQLException 或者 NamingException。 |
| 返回顶楼 | |
|
发表时间：2004-11-26
flyingbugs 写道 gigix：
你就应该需要用的时候再创建，用完就丢弃，不应该去pool它，这才是性能最高的做法。 哈 太好了，这样我们再也不需要容器啦，webcontainer，ejbcontainer都见鬼去吧。 容器从来就不是为了pool而存在的。容器存在的理由有两个：1，提供统一的对象创建机制，使client和component仅仅通过接口耦合；2，为component提供infrastructures。EJB容器提供pool，仅仅是因为从前的JVM GC效率太低，不得不采用的权宜之计。在Java 1.3之后的VM里面，GC效率的提升已经使EJB容器的instance pooling变成了一个反模式。详情请参见J2EE without EJB第12章，或请教dlee同志。 |
| 返回顶楼 | |
|
发表时间：2004-11-26
gigix 写道 flyingbugs 写道 gigix：
你根本没有明白我的意思。 呵呵 很多情况下 在循环中new出来的对象往往可以通过单列或者static来代替。 建议你去看看Rotor，看看vm到底是怎么实现的。 我想到底应该new一个对象还是应该singleton，这应该由程序的语意来决定，而不是由尚未可知的性能因素来决定。举个例子，如果是无状态的业务对象，想都不用想就知道应该在循环之外创建一个实例，每次循环都使用同一个。但凡是在循环内部new对象，必定是因为这个对象有状态，而且对象状态跟循环的局部状态有关。当然你可以想办法把这个状态抽取出来，然后减少new对象的次数，但这样一来你将得到一个不贴切的对象，能节约多少性能却只能说是尚未可知。在我看来这是得不偿失的。 至于static，那就更不是一回事了。如果你认为对象还可以用static代替，我们的讨论可以到此为止了。如果你不愿意承认你不懂Java，那我承认我不懂Java好了。 你不是不懂java啊 你怎么会不懂java呢？？^&^... 不过你可能书看到多一点， 代码写得少一点， 发表观点多一点， 仔细考虑少一点。 |
| 返回顶楼 | |
|
发表时间：2004-11-26
目前容器最主要得功能 说得面向过程一点：提供一个多线程得控制框架。 在之上实现 pool对象，事务管理。
cics/tuxdo 等都是差不多得， 实现原理也是换汤不换药。 |
| 返回顶楼 | |
