[表示怀疑]什么样的优化能让Java程序性能提高2.5倍？

咱们别扯得那么远好吗？我就想知道，你那个系统原来是个什么样，优化完了又是个什么样，性能都是从哪儿节省出来的。要是有商业秘密不方便说，你就拿robbin那个程序做个示范给大家看看也成。你做过的东西也不给看，做个示范也不肯做，你说叫我怎么相信你那个神奇的“2.5倍优化”呢？

我不抬杠了，我向你道歉。

我的原意是指不熟悉底层机制未必就写不出来高效的Java代码。实际上Java这种基于虚拟机的语言本身就是通过层层类调用来完成操作的，因此应用层代码本身多几个new，少几个new，多用几个Exception，少用几个Exception，多几层少几层，并不会对性能造成什么影响。我们可以通过很简单的使用java -verbose参数来观察Java的运行信息，即使最简单的Hello World也要经过非常多层类堆栈调用，那么应用层代码往往不会成为瓶颈。

所以我的观点是：

Java应用程序的性能不取决于你多用了一些分层设计，多用了new，多用了Exception层次；如果你的Java应用程序有性能问题，那么问题的根源也不在你多用了一些分层设计，多用了new，多用了Exception层次

CheckedException绝对是有必要的
举个例子,某个服务程序需要起一个线程不定时的完成某项操作,其实就是调用某个接口的方法,这个方法有异常,这个时候用RuntimeException根本就不合适,而是必须用CheckedException,调用者必须对此异常捕获处理

你说在 循环中new对象 能不出现巨大的性能问题么？？

很多时候 是很小一些地方导致整个系统运行缓慢。

记得有个系统,要实现一个对外xml数据报文的转换，由于这个系统高峰期的数据量是十分十分大，我们开始的时候用的xslt,性能远远达不到要求，怎么说呢？也就是说就算你再加几倍的机器性能，都达不到要求。后来我自己写了xml解析转换器，效果好了些，但还是达不到要求，后来甚至根据这个格式写了个专门的转换程序，也就是说按照字节位来取值（还好这个东东十分规范啊）！才勉强达到了要求..

CheckedException当然重要！
但用Exception来当流程处理，就是不正确的！

还有CheckedException实际上并没带来实际的约束，还是要靠程序员自己去约束自己。不知道有多少程序就是直接抛Exception！

robbin：用Exception来处理流程，辟开编程的不方便和让人误解不谈，光从效率上来说，就是不太合适的。
throw catch等的效率 并不是光throw catch那么一下所耗费的时间，给jvm堆栈快照，填充stacktrace很费时间，而且现在的处理器都是很长的流水线，你throw一把，会导致流水线失效.

Exception之所以叫Exception，不叫SuperIf是有它的道理的！！
robbin:我只是针对你所说的用Exception来判断流程这点十分不同意。 也可能我对你的理解有误吧。其实 你的那个login的例子 并不能很好的说明问题和你的观点。

流程处理怎么不对了？异常事件流用Exception没什么问题，就像我上面说的那个操作，抛出的那个异常是什么，就是一个异常事件流。

baichenhong：
异常处理流是可以的， 但要看清擦：是 异常！
而不是业务处理流，如果是业务中，本来的一个处理流程，就不要用Exception来控制。

你说是把！异常嘛， 至少应该是1/10一下的发生几率才能算异常吧！

恐怕事情和你的想象恰恰相反。我前面已经说过了，现在的JVM都采用了分代式的垃圾收集，如果你创建大量的对象，用完之后立即抛弃，GC的范围将被局限在“新一代”。而且这些对象的引用非常简单，单凭对代码的静态分析就可以找到它的存活域，不需要更多的运行时动态侦测。这样一来，GC的范围更小，执行速度更快，当然效率更高。如果你pool大量的对象，很可能导致它们进入“老一代”，导致的直接后果就是扩大GC的范围，而这种“大GC”（相对于只收集“新一代”的“小GC”而言）对性能的损害是相当严重的。所以对于大多数的业务对象，你就应该需要用的时候再创建，用完就丢弃，不应该去pool它，这才是性能最高的做法。如果业务对象的初始化时间很长，你通常应该把需要初始化的部分移到对象之外，以共享资源的形式来保存它们。

robbin给的资料链接你有没有好好看过那?
http://www-900.ibm.com/developerWorks/cn/java/j-jtp05254/index.shtml
Rod Johnson 是 J2EE Design and Development （请参阅 参考资料） 的作者，这是我所读过的关于 Java 开发，J2EE 等方面的最好的书籍之一。他采取一个不太激进的方法。他列举了异常的多个类别，并且为每个类别确定一个策略。一些异常本质上是次要的返回代码（它通常指示违反业务规则），而一些异常则是“发生某种可怕错误”（例如数据库连接失败）的变种。Johnson 提倡对于第一种类别的异常（可选的返回代码）使用检查型异常，而对于后者使用运行时异常。在“发生某种可怕错误”的类别中，其动机是简单地认识到没有调用者能够有效地处理该异常，因此它也可能以各种方式沿着栈向上扩散而对于中间代码的影响保持最小（并且最小化异常淹没的可能性）。