原文 http://www.infoq.com/articles/9_Fallacies_Java_Performance

翻译 http://www.oschina.net/translate/9_fallacies_java_performance  [凑合]

看这篇文章，原文要看，评论也要看。文章总结了9点谬误：

1: Java运行慢

提到了对比测试 web performance benchmarks ，

头两个都是netty相关，netty是基于java的，去看了一下，基于nio,与mina是同一个作者(韩国李)。

这里也扯一下netty和mina, http://stackoverflow.com/questions/1637752/netty-vs-apache-mina

上面链接看看韩国李的评论，netty就是为了解决mina开发中出现的问题而重新设计的，它的文档更好，构建速度更快，去掉了可能不是用的很多的东西从而简单化，提高性能。mina3将会是完全的重构，意味着api兼容性将会破坏（说到这你也懂韩国李自己都在黑mina了。） 只是对于UDP,mina提供更高层的抽象（稳定连接），而netty更接近UDP本意。

里面还有人拿netty和ngix做测试对比，竟然etty表现和ngix不相上下甚至更好……

之所以说是框架而不是服务器，是因为它是嵌入到程序里面作为服务端框架，就像嵌入的tomcat或jetty,而不是一个web容器。

回到上面提到的性能比较表，php竟然比spring还慢。php完全排在java平台之后了。nodejs还在tapestry之后。

这个结果与直觉相比，似乎不是很靠谱得呢。

2. A single line of Java means anything in isolation 一行代码是孤立处理的

意思是说，其实java 虚拟机和即时编译器是有上下文来优化的，所以不要试图过早的优化。

3. A microbenchmark means what you think it does

意思是说没必要一开始就设计微基准测试（小范围基准测试？），当确实发现需要基准测试时，应该从系统整体和最关键部分考虑。

4.算法慢是性能问题的最普遍原因

应该依靠经验和产品数据来找到引起性能问题的真正原因。要动手采集数据而不是凭空猜测。--算法往往不是问题

5.缓存能解决一切问题

意思是说,往往重构更能简化系统提高性能,缓存作用有时不是很大.--作者认为重构比利用缓存更简单.

6. All apps need to be concerned about Stop-The-World 所有的程序都要注意jvm的Stop-The-World问题

意思是说虽然STW问题确实存在，但是对于大部分程序来说，这个问题的影响可以忽略或忍受。

在决定是否需要考虑这个问题之前，首先利用GC日志分析，到底是否STW是根本原因。

7. Hand-rolled Object Pooling is appropriate for a wide range of apps

意思是说对象池并不能很好地解决STW问题，它起作用，但是起不了很大的作用。反而使代码更复杂。

8. CMS is always a better choice of GC than Parallel Old -- CMS机制总是比Parallel Old机制好

意思是说CMS也有弊端，只在Parallel Old机制确实无法忍受的情况下再来考虑CMS

9. 增加堆内存会解决你内存溢出的问题

这个是老生长谈，如果是程序问题，再大的内存也不管用

评论中还是有相当怀疑意见的：

有人认为C++还是比java要性能高，作者解释说从内联(intrinsics)和单态区分(monomorphic dispatch) 这两点上,JIT要比C++编译器强很多。

还有人需要作者指明很多java程序与c++一样快这句话缺少例子，我也这么认为，因为java里面太多这样类似的暗示却没有实证。

文章看过，没什么比较震撼的信息，仍不能解决我对java性能的保留意见，从实际来看，无论知名大应用还是商业小应用，例证最多的还是php。

而且，相比php,java出现性能问题的几率是多了无数倍，你需要花时间解决这个问题的花费也是无数倍,因为php是外面的框子限制了性能问题（启动->运行->终止）,而java则留了许多坑让你踩，一个不留神你就中招了。

不好意思，又这里黑java了，但是我用的最多的还是java,lol.