关于 Java 性能方面的 9 个谬论 - 技术翻译 - 开源中国社区
关于 Java 性能方面的 9 个谬论
【已翻译100%】
英文原文：
推荐于 4年前 (共 11 段, 翻译完成于 04-27)
参与翻译&(6人)&: ,
Java性能问题被冠以某种黑暗魔法的称谓。一部分是因为其平台的复杂性，在很多情况下，无法定位其性能问题根源。然而，在以前对于Java性能的技巧，有一种趋向：认为其由人们的智慧，经验构成，而不是应用统计和实证推理。在这篇文章中，我希望去验证一些最荒谬的技术神话。
1. Java运行慢
在所有最过时的Java性能谬论当中，这可能是最明显的言论。
是的，在90年代和20年代初期，Java确实有点慢。
然而，在那之后，我们有超过10年的时间来改进虚拟机和JIT技术，现在Java整个体系的性能已经快的令人惊讶。
在6个单独的web性能测试基准中，Java框架占据了24个当中的22个前四的位置。
JVM性能分析组件的使用不仅优化了通用的代码路径，而且在优化那些严重领域也很有成效。JIT编译代码的速度在大多数情况下跟C++一样快了。
尽管这样，关于Java运行慢的言论还是存在，估计是由于历史原因造成的偏见，这个偏见来自当时那些使用Java早期版本的人们。
我们建议，在匆忙下结论之前先保留意见和评估一下最新的性能结果。
&翻译得不错哦！
2. 单行java代码意味着任何事都是孤立的
考虑以下一小段代码：
MyObject obj = new MyObject();
对一个Java开发者而言，很明显能看出这行代码需要分配一个对象和运行一个对应的构造方法。
从这来看，我们可以开始推出性能边界。我们知道有一些精确数量的工作必须继续，因此基于我们的推测，我们可以计算出性能影响。
这儿有个认知偏见，那就是根据以往的经验，任何工作都需要被做。
实际上，javac和JIT编译器都可以优化无效代码。就拿JIT编译器来说，代码甚至可以基于数据分析而被优化掉，在这种情况下，该行代码将不会被运行，因此它就不会有什么性能方面的影响。
而且，在一些Java虚拟机(JVM)中，例如JRockit中,即使代码路径没有完全失效，JIT编译器为了避免分配对象甚至可以执行分解对象操作。
这段文字在这里的意义就是当处理Java性能方面的问题时，上下文很重要。而且过早的优化可能会产生意料之外的结果。所以为了获得最好的结果，不要试图过早的优化。与其不断构建你的代码不如用性能调整技术去定位并且改正代码性能的潜在危险区。
&翻译得不错哦！
3.你以为一个微基准测试代表了一切
正如前面所说，探讨一小段代码性能所得出的结果要比分析应用全局性能的结果要粗略的多。
虽说如此，但开发者们仍然喜欢写一些微基准测试。一些人追求通过改良平台底层某些方面而获得性能提升所带给他们的内在快乐，并乐此不疲。
Richard Feynman曾说过“第一原则就是不要自欺欺人，你就是那个最容易被糊弄的人”。现在，当你编写java微基准测试的时候，你真得好好想想这句话。
要想写出良好的微基准测试是很困难的。以深奥、复杂著称的Java平台为例，许多微基准测试仅能胜任测量瞬时效应或者一些平台无关的方面。
例如，一个未经过良好设计的微基准测试通常只注重测量耗时的子系统或垃圾回收的性能而忽略了在捕捉这些变化过程中所产生的开销。
&翻译得不错哦！
只有当开发者和团队有真正基准需求的时候才需要写微基准测试。这些基准测试应该打包到项目（包括源代码）随项目一起发布，并且这些基准测试应该是可重现的并可提供给他人审阅和进一步的审查。
Java平台的许多优化结果都指的是只运行单一基准测试用例时所得到的统计结果。一个单独的基准测试必须要多次运行才能得到一个比较趋近于真实答案的结果。
如果你认为到了必须要写微基准测试的时候，首先请读一下Georges, Buytaert, Eeckhout所著的"Statistically Rigorous Java Performance Evaluation"。如果没有统计学的知识，你会很容易误入歧途的。
网上有很多好的工具和社区来帮助你进行基准测试，例如Google的Caliper。如果你不得不写基准测试时，不要埋头苦干，你需要从他人那里汲取意见和经验。
&翻译得不错哦！
4.算法慢是性能问题的最普遍原因
在程序员（和普通大众）中普遍存在一个错误观点就是他们总是理所当然地认为自己所负责的那部分系统才是最重要的。
就Java性能这个问题来说，Java开发者认为算法的质量是性能问题的主要原因。开发者会考虑如何编码，因此他们本性上就会潜意识地去考虑算法。
实际上，当处理现实中的性能问题时，算法设计占用了解决基本问题不到10%的时间。
相反，相对于算法，垃圾回收，数据库访问和配置错误会更可能造成程序缓慢。
大多数应用程序处理相对少量的数据，因此即使主算法有缺陷也不会导致严重的性能问题。因此，我们得承认算法对于性能问题来说是次要的;因为算法带来的低效相对于其他部分造成的影响来说是相对较小的，大多的性能问题来自于应用程序栈的其他部分。
因此我们的最佳建议就是依靠经验和产品数据来找到引起性能问题的真正原因。要动手采集数据而不是凭空猜测。
&翻译得不错哦！
缓存能解决一切问题
“关于计算机科学的每一个问题都可以通过附加另外一个层面间接的方式被解决”
这句程序员的格言，来至于David Wheeler（幸亏有因特网，至少有另外两位计算机科学家），是惊人的相似，特别是在web开发者中。
通常出现这种谬论是因为当面对一个现有的，理解不够透彻的架构时出现的分析瘫痪。
与其处理一个令人生畏的现存系统，开发者经常会选择躲避它通过添加一个缓存并且抱着最大的希望。当然，这个方法仅仅使整个架构变的更复杂，并且对试图理解产品架构现状的下一位开发者而言是一件很糟糕的事情。
夸大的说，不规则架构每次被写入一行和一个子系统。然而，在许多情况下，更简单的重构架构会有更好的性能，而且它们几乎也更易于被理解。
因此当你评估是不是需要缓存时，计划去收集基本用法统计（缺失率，命中率等）去证明实际上缓存层是个附加值。
&翻译得不错哦！
6. 所有应用都要考虑到STW
(译注：“stop-the-world” 机制简称STW,即,在执行垃圾收集算法时,Java应用程序的其他所有除了垃圾收集帮助器线程之外的线程都被挂起)
Java平台的一个存在事实是，所有应用线程必须周期性的停止以便让垃圾搜集器GC运行。这有时被夸大为严重的弱点，即使是在缺少真实证据的情况下。
实证研究已经说明，人类通常无法察觉到频率超过每200毫秒一次的数字数据的变化（例如价格变动）。
因此对以人类作为首要用户的应用，一条有用的经验就是200毫秒或低于200毫秒的 Stop-The-World (STW)停顿通常无需考虑。有些应用（例如视频流）需要比这个更低的GC波动，但是很多GUI应用不是的。
有少数应用（比如低延迟交易，或者机械控制系统）对200毫秒停顿是不可接受的。除非你的应用属于那个少数，否则你的用户察觉到任何由垃圾回收带来的影响是不太可能的。
值得注意的是，在具有比物理内核更多应用线程的系统中，操作系统任务计划将会干涉对CPU的时间分片访问。Stop-The-World听起来吓人，但实际上，每个应用（无论是不是JVM）都必须处理对稀缺计算资源的内容访问。
如果不做测量，JVM的方法对应用性能带来的额外影响具有何等意义将无法看清。
总体来说，判断停顿的次数实际对应用的影响是通过打开GC日志的办法。分析此日志（或者手工，或者用脚本或工具）来确定停顿的次数。然后再判定这些是否确实给你的应用域带来问题。最重要的是，问自己一个最尖锐的问题：有用户确实抱怨了吗？
&翻译得不错哦！
7. 手工处理的对象池对很大范围内的应用都是合适的
对Stop-The-World停顿的坏感觉引起一个常见的应对，即在java堆的范围内，为应用程序组发明它们自己的内存管理技术。经常这会归结为实现一个对象池（或甚至是全面引用计数）的方法，并且需要让任何使用了领域对象的代码参与进来。
这种技术几乎总是被误导。它通常具有自身久远以前的根源，那时对象定位代价昂贵，突然的变化被认为是不重要的。但现在的世界已经非常不同。
现代的硬件具有难以想象的定位效率；近来桌面或服务器硬件的内存容量至少达到了2到3GB。这是一个很大的数字；除了专业的使用情形，让实际的应用充满那么大的容量不是很容易。
对象池一般很难正确的实现（特别是有多个线程在工作的时候），并且有几个消极的要求使得把它作为一般场景使用成为一个艰难选择：
所有接触到代码的开发者都必须清楚对象池并正确的处理它
“对池清醒”代码与“对池不清醒”代码之间的界限必须要通晓并明文规定
所有这些附加的复杂性必须保持最新，并定期评估
如果这里任何地方失败了，无声损坏的风险（类似C中的指针重用）将被再次引入
总之，只有在GC停顿不能被接受，而且在调试与重构过程中聪明的尝试也不能缩减停顿到可接受水平的时候，对象池才可以使用。
&翻译得不错哦！
8. 在GC中CMS总是比Parallel Old更好
Oracle JDK默认使用一个并行的，全部停止（stop-the-world STW)垃圾收集器来收集老年代的垃圾。
另外一个选择是并发标记清除（CMS）收集器。这个收集器允许程序线程在大部分的GC周期中仍然继续工作，但它需要付出一些代价和带来一些警告。
允许程序线程和GC线程一起运行不可避免地导致对象表的变异同时又影响到对象的活跃性。这不得不在发生后进行清楚，所以CMS实际上有两个STW阶段（通常非常短）。
这会带来一些后果：
所有程序线程不得不放进一个安全点并且在每次完全收集时停止两次；
在收集并发运行地同时，程序吞吐量会减少（通常是50%）
在JVM从事通过CMS来收集垃圾的总体数据上（包括CPU周期）比并行收集更加高的。
依据程序的情况这些成本或者是值得的或者又不是。但并没有免费的午餐。CMS收集器是一个卓越的工程品，但它不是万能药。
所以在介绍前，CMS是你正确的GC策略，你得首先考虑Parallel Old的STW是不可接收的和不能调和的。最后，（我不能足够地强调），确定所有的指标都从相当的生产系统上得到。
&翻译得不错哦！
9. 增加堆内存会解决你内存溢出的问题
当一个应用程序崩溃，GC中止运行时，许多应用组会通过增加堆内存来解决问题。在许多情况下，这可以很快解决问题，并争取时间来考虑出一个更深的解决方案。然而，在没有真正理解性能产生的根源时，这种解决策略实际上会使情况更糟糕。
试想一下，一个编码很烂的应用构造了非常多的领域对象（生命周期大概维持2，3秒）。如果内存分配率足够高，垃圾回收就会很快地执行，并把这些领域对象放到年老代。一旦进入了老年代，对象就会立即死去，但直到下一次完全回收才会被垃圾回收器回收。
如果这个应用增加其堆内存，那么我们能做的是增加空间，为了存放那些相对短期存在，然后消逝的领域对象。这会使得&Stop-The-World 的时间更长，对应用毫无益处。
在改变堆内存和或其他参数之前，理解一下对象的动态分配和生命周期是很有必要的。没做调查就行动，只会使事情更糟。在这里，垃圾回收器的老年分布信息是非常重要的。
&翻译得不错哦！
我们的翻译工作遵照 ，如果我们的工作有侵犯到您的权益，请及时联系我们
为什么各个地方的人还在骑自行车呢？为什么还有人在看中医呢？为什么还有企业在用Windows2000呢？为什么还有那么多人用IE6呢？
重型大卡如果跟小轿车比的话，司机再牛X也无济于事，慢还是慢！
IT界的跟风、宣传、造势不亚于娱乐界啊本文就是一例不过，看评论，才觉得也不都是跟风者，有点欣慰
“C写的如果不用-O3优化，速度比java慢多了”——你这话的意思好比说，练过10的Java运动员比脚跟受伤的C运动员跑得快多了！别激动。你的比喻也不恰当，-O3并不常用。我无意比较语言的优劣，只是陈述一个事实，让别人有更全面的认识
重型大卡如果跟小轿车比的话，司机再牛X也无济于事，慢还是慢！是这个道理. 不过呢,为啥这个世界上还存在重型大卡这种车型呢? 呵呵
盛大已经在用了!在魔都, 盛大其实是个不靠谱的公司.
“C写的如果不用-O3优化，速度比java慢多了”——你这话的意思好比说，练过10的Java运动员比脚跟受伤的C运动员跑得快多了！别激动。你的比喻也不恰当，-O3并不常用。我无意比较语言的优劣，只是陈述一个事实，让别人有更全面的认识我还真的很少见到在相同环境下C慢于Java的情况，当然在开发效率上，Java一般占有优势！如果要更全面比较的话，应该在对比测试的时候，除了测试执行时间，还应该比较内存占用和CPU使用。
重型大卡如果跟小轿车比的话，司机再牛X也无济于事，慢还是慢！是这个道理. 不过呢,为啥这个世界上还存在重型大卡这种车型呢? 呵呵不是讨论Java应不应该存在的问题，只是描述对这种事物的主观感受——慢！就像没人怀疑重型大卡会继续存在，它的优点和缺点都一样深入人心，如果有人说一辆重型大卡跑得跟法拉利一样快，就有点让人好奇了。
盛大已经在用了!在魔都, 盛大其实是个不靠谱的公司.里面的一些技术人员还是很靠谱的！
。。。。面向用户的桌面应用，别这么搞笑 成吗
你去看看前面，没有讨论哪个语言好，也没说Java差，只是对Java的一个方面的主观感受！就好比讨论刘翔和C罗哪个人的乒乓球打得好一样，可以拿来比较，但它们的侧重点都不同。
。。。。面向用户的桌面应用，别这么搞笑 成吗如果你开心，就尽情笑吧！
真是浅见我有论点有论据，你只有论点没有论据哦
为什么各个地方的人还在骑自行车呢？为什么还有人在看中医呢？为什么还有企业在用Windows2000呢？为什么还有那么多人用IE6呢？你说的这些不是主流了，你要说一个和java一样是主流的
盛大已经在用了!在魔都, 盛大其实是个不靠谱的公司.里面的一些技术人员还是很靠谱的！也就那样,魔都的经济结构在变化, 慢慢的,呆头呆脑的技术男已经不适合这个城市了关于 Java 性能方面的 9 个谬论 - 技术翻译 - 开源中国社区
关于 Java 性能方面的 9 个谬论
【已翻译100%】
英文原文：
推荐于 4年前 (共 11 段, 翻译完成于 04-27)
参与翻译&(6人)&: ,
Java性能问题被冠以某种黑暗魔法的称谓。一部分是因为其平台的复杂性，在很多情况下，无法定位其性能问题根源。然而，在以前对于Java性能的技巧，有一种趋向：认为其由人们的智慧，经验构成，而不是应用统计和实证推理。在这篇文章中，我希望去验证一些最荒谬的技术神话。
1. Java运行慢
在所有最过时的Java性能谬论当中，这可能是最明显的言论。
是的，在90年代和20年代初期，Java确实有点慢。
然而，在那之后，我们有超过10年的时间来改进虚拟机和JIT技术，现在Java整个体系的性能已经快的令人惊讶。
在6个单独的web性能测试基准中，Java框架占据了24个当中的22个前四的位置。
JVM性能分析组件的使用不仅优化了通用的代码路径，而且在优化那些严重领域也很有成效。JIT编译代码的速度在大多数情况下跟C++一样快了。
尽管这样，关于Java运行慢的言论还是存在，估计是由于历史原因造成的偏见，这个偏见来自当时那些使用Java早期版本的人们。
我们建议，在匆忙下结论之前先保留意见和评估一下最新的性能结果。
&翻译得不错哦！
2. 单行java代码意味着任何事都是孤立的
考虑以下一小段代码：
MyObject obj = new MyObject();
对一个Java开发者而言，很明显能看出这行代码需要分配一个对象和运行一个对应的构造方法。
从这来看，我们可以开始推出性能边界。我们知道有一些精确数量的工作必须继续，因此基于我们的推测，我们可以计算出性能影响。
这儿有个认知偏见，那就是根据以往的经验，任何工作都需要被做。
实际上，javac和JIT编译器都可以优化无效代码。就拿JIT编译器来说，代码甚至可以基于数据分析而被优化掉，在这种情况下，该行代码将不会被运行，因此它就不会有什么性能方面的影响。
而且，在一些Java虚拟机(JVM)中，例如JRockit中,即使代码路径没有完全失效，JIT编译器为了避免分配对象甚至可以执行分解对象操作。
这段文字在这里的意义就是当处理Java性能方面的问题时，上下文很重要。而且过早的优化可能会产生意料之外的结果。所以为了获得最好的结果，不要试图过早的优化。与其不断构建你的代码不如用性能调整技术去定位并且改正代码性能的潜在危险区。
&翻译得不错哦！
3.你以为一个微基准测试代表了一切
正如前面所说，探讨一小段代码性能所得出的结果要比分析应用全局性能的结果要粗略的多。
虽说如此，但开发者们仍然喜欢写一些微基准测试。一些人追求通过改良平台底层某些方面而获得性能提升所带给他们的内在快乐，并乐此不疲。
Richard Feynman曾说过“第一原则就是不要自欺欺人，你就是那个最容易被糊弄的人”。现在，当你编写java微基准测试的时候，你真得好好想想这句话。
要想写出良好的微基准测试是很困难的。以深奥、复杂著称的Java平台为例，许多微基准测试仅能胜任测量瞬时效应或者一些平台无关的方面。
例如，一个未经过良好设计的微基准测试通常只注重测量耗时的子系统或垃圾回收的性能而忽略了在捕捉这些变化过程中所产生的开销。
&翻译得不错哦！
只有当开发者和团队有真正基准需求的时候才需要写微基准测试。这些基准测试应该打包到项目（包括源代码）随项目一起发布，并且这些基准测试应该是可重现的并可提供给他人审阅和进一步的审查。
Java平台的许多优化结果都指的是只运行单一基准测试用例时所得到的统计结果。一个单独的基准测试必须要多次运行才能得到一个比较趋近于真实答案的结果。
如果你认为到了必须要写微基准测试的时候，首先请读一下Georges, Buytaert, Eeckhout所著的"Statistically Rigorous Java Performance Evaluation"。如果没有统计学的知识，你会很容易误入歧途的。
网上有很多好的工具和社区来帮助你进行基准测试，例如Google的Caliper。如果你不得不写基准测试时，不要埋头苦干，你需要从他人那里汲取意见和经验。
&翻译得不错哦！
4.算法慢是性能问题的最普遍原因
在程序员（和普通大众）中普遍存在一个错误观点就是他们总是理所当然地认为自己所负责的那部分系统才是最重要的。
就Java性能这个问题来说，Java开发者认为算法的质量是性能问题的主要原因。开发者会考虑如何编码，因此他们本性上就会潜意识地去考虑算法。
实际上，当处理现实中的性能问题时，算法设计占用了解决基本问题不到10%的时间。
相反，相对于算法，垃圾回收，数据库访问和配置错误会更可能造成程序缓慢。
大多数应用程序处理相对少量的数据，因此即使主算法有缺陷也不会导致严重的性能问题。因此，我们得承认算法对于性能问题来说是次要的;因为算法带来的低效相对于其他部分造成的影响来说是相对较小的，大多的性能问题来自于应用程序栈的其他部分。
因此我们的最佳建议就是依靠经验和产品数据来找到引起性能问题的真正原因。要动手采集数据而不是凭空猜测。
&翻译得不错哦！
缓存能解决一切问题
“关于计算机科学的每一个问题都可以通过附加另外一个层面间接的方式被解决”
这句程序员的格言，来至于David Wheeler（幸亏有因特网，至少有另外两位计算机科学家），是惊人的相似，特别是在web开发者中。
通常出现这种谬论是因为当面对一个现有的，理解不够透彻的架构时出现的分析瘫痪。
与其处理一个令人生畏的现存系统，开发者经常会选择躲避它通过添加一个缓存并且抱着最大的希望。当然，这个方法仅仅使整个架构变的更复杂，并且对试图理解产品架构现状的下一位开发者而言是一件很糟糕的事情。
夸大的说，不规则架构每次被写入一行和一个子系统。然而，在许多情况下，更简单的重构架构会有更好的性能，而且它们几乎也更易于被理解。
因此当你评估是不是需要缓存时，计划去收集基本用法统计（缺失率，命中率等）去证明实际上缓存层是个附加值。
&翻译得不错哦！
6. 所有应用都要考虑到STW
(译注：“stop-the-world” 机制简称STW,即,在执行垃圾收集算法时,Java应用程序的其他所有除了垃圾收集帮助器线程之外的线程都被挂起)
Java平台的一个存在事实是，所有应用线程必须周期性的停止以便让垃圾搜集器GC运行。这有时被夸大为严重的弱点，即使是在缺少真实证据的情况下。
实证研究已经说明，人类通常无法察觉到频率超过每200毫秒一次的数字数据的变化（例如价格变动）。
因此对以人类作为首要用户的应用，一条有用的经验就是200毫秒或低于200毫秒的 Stop-The-World (STW)停顿通常无需考虑。有些应用（例如视频流）需要比这个更低的GC波动，但是很多GUI应用不是的。
有少数应用（比如低延迟交易，或者机械控制系统）对200毫秒停顿是不可接受的。除非你的应用属于那个少数，否则你的用户察觉到任何由垃圾回收带来的影响是不太可能的。
值得注意的是，在具有比物理内核更多应用线程的系统中，操作系统任务计划将会干涉对CPU的时间分片访问。Stop-The-World听起来吓人，但实际上，每个应用（无论是不是JVM）都必须处理对稀缺计算资源的内容访问。
如果不做测量，JVM的方法对应用性能带来的额外影响具有何等意义将无法看清。
总体来说，判断停顿的次数实际对应用的影响是通过打开GC日志的办法。分析此日志（或者手工，或者用脚本或工具）来确定停顿的次数。然后再判定这些是否确实给你的应用域带来问题。最重要的是，问自己一个最尖锐的问题：有用户确实抱怨了吗？
&翻译得不错哦！
7. 手工处理的对象池对很大范围内的应用都是合适的
对Stop-The-World停顿的坏感觉引起一个常见的应对，即在java堆的范围内，为应用程序组发明它们自己的内存管理技术。经常这会归结为实现一个对象池（或甚至是全面引用计数）的方法，并且需要让任何使用了领域对象的代码参与进来。
这种技术几乎总是被误导。它通常具有自身久远以前的根源，那时对象定位代价昂贵，突然的变化被认为是不重要的。但现在的世界已经非常不同。
现代的硬件具有难以想象的定位效率；近来桌面或服务器硬件的内存容量至少达到了2到3GB。这是一个很大的数字；除了专业的使用情形，让实际的应用充满那么大的容量不是很容易。
对象池一般很难正确的实现（特别是有多个线程在工作的时候），并且有几个消极的要求使得把它作为一般场景使用成为一个艰难选择：
所有接触到代码的开发者都必须清楚对象池并正确的处理它
“对池清醒”代码与“对池不清醒”代码之间的界限必须要通晓并明文规定
所有这些附加的复杂性必须保持最新，并定期评估
如果这里任何地方失败了，无声损坏的风险（类似C中的指针重用）将被再次引入
总之，只有在GC停顿不能被接受，而且在调试与重构过程中聪明的尝试也不能缩减停顿到可接受水平的时候，对象池才可以使用。
&翻译得不错哦！
8. 在GC中CMS总是比Parallel Old更好
Oracle JDK默认使用一个并行的，全部停止（stop-the-world STW)垃圾收集器来收集老年代的垃圾。
另外一个选择是并发标记清除（CMS）收集器。这个收集器允许程序线程在大部分的GC周期中仍然继续工作，但它需要付出一些代价和带来一些警告。
允许程序线程和GC线程一起运行不可避免地导致对象表的变异同时又影响到对象的活跃性。这不得不在发生后进行清楚，所以CMS实际上有两个STW阶段（通常非常短）。
这会带来一些后果：
所有程序线程不得不放进一个安全点并且在每次完全收集时停止两次；
在收集并发运行地同时，程序吞吐量会减少（通常是50%）
在JVM从事通过CMS来收集垃圾的总体数据上（包括CPU周期）比并行收集更加高的。
依据程序的情况这些成本或者是值得的或者又不是。但并没有免费的午餐。CMS收集器是一个卓越的工程品，但它不是万能药。
所以在介绍前，CMS是你正确的GC策略，你得首先考虑Parallel Old的STW是不可接收的和不能调和的。最后，（我不能足够地强调），确定所有的指标都从相当的生产系统上得到。
&翻译得不错哦！
9. 增加堆内存会解决你内存溢出的问题
当一个应用程序崩溃，GC中止运行时，许多应用组会通过增加堆内存来解决问题。在许多情况下，这可以很快解决问题，并争取时间来考虑出一个更深的解决方案。然而，在没有真正理解性能产生的根源时，这种解决策略实际上会使情况更糟糕。
试想一下，一个编码很烂的应用构造了非常多的领域对象（生命周期大概维持2，3秒）。如果内存分配率足够高，垃圾回收就会很快地执行，并把这些领域对象放到年老代。一旦进入了老年代，对象就会立即死去，但直到下一次完全回收才会被垃圾回收器回收。
如果这个应用增加其堆内存，那么我们能做的是增加空间，为了存放那些相对短期存在，然后消逝的领域对象。这会使得&Stop-The-World 的时间更长，对应用毫无益处。
在改变堆内存和或其他参数之前，理解一下对象的动态分配和生命周期是很有必要的。没做调查就行动，只会使事情更糟。在这里，垃圾回收器的老年分布信息是非常重要的。
&翻译得不错哦！
我们的翻译工作遵照 ，如果我们的工作有侵犯到您的权益，请及时联系我们
之前有关注过一下，一点都不觉得Go有宣传的那样简洁啊……我个人是觉得学过的语言里面C和python从语言上说算很简洁和简单的了。不过可能是我已经习惯了C语系然后比较难接受Go的语法吧，最喜欢的还是Go的错误处理情况和多返回值- -
IT界的跟风、宣传、造势不亚于娱乐界啊本文就是一例不过，看评论，才觉得也不都是跟风者，有点欣慰的确啊，虽然没有经历过sun对java宣传过剩的那个时代，但是看过一些书上面提到过，而且现在还有些老书在提及到，再对比现在自己执导的一点点现状就已经感觉sun当时是宣传过度了
“C写的如果不用-O3优化，速度比java慢多了”——你这话的意思好比说，练过10的Java运动员比脚跟受伤的C运动员跑得快多了！别激动。你的比喻也不恰当，-O3并不常用。我无意比较语言的优劣，只是陈述一个事实，让别人有更全面的认识我还真的很少见到在相同环境下C慢于Java的情况，当然在开发效率上，Java一般占有优势！如果要更全面比较的话，应该在对比测试的时候，除了测试执行时间，还应该比较内存占用和CPU使用。稍微看过了一下你给的三个测试，第一个不是很能说明问题啊。另外，java官方给的java比C要快的场景肯定是做过优化的，java可优化的地方除了代码之外还有jvm的调优。java一般来说比C慢那是公认了的，现在只是说慢多少罢了。另外相同的环境是指相同的算法实现相同的操作系统吗？jvm是否经过了调优优化？
OTL，C++学了一阵子就让我感觉好烦，各种的编译错误各种编译错误，我想死……最后始终没有深入，感觉还是C和java还有python之类的比较好一点。
真是浅见我有论点有论据，你只有论点没有论据哦eclipse打开的过程中做了很多事的，不过在我的机子里面打开eclipse也不是很快呢，如果你觉得eclipse开的太慢的话可以尝试卸载一些插件，应该会快一点。另外，启动的速度不能代表java的运行速度啊，jit本身就是在运行的过程中生成本地代码的，所以java的启动速度跟运行速度是两个概念啊。
为什么各个地方的人还在骑自行车呢？为什么还有人在看中医呢？为什么还有企业在用Windows2000呢？为什么还有那么多人用IE6呢？你说的这些不是主流了，你要说一个和java一样是主流的1、单单一个慢并不会导致一门语言死掉，Java其他方面的优势会让它继续生存下去；2、就像改革开放前的主流交通工具是自行车一样，现在还是吗？难保明天的Java不是昨日的自行车，今日的IE6；3、因为Java的一些缺点和缺陷，其他相应的语言也慢慢兴起。不然Java这么牛X，全用Java算了，还有必要搞其他语言么？即使是在服务器这一Java的传统领域，也被其他语言慢慢侵占。4、不是说哪门语言好，哪门语言坏，而是对Java某一方面的主观感受。正是因为有很多人感觉Java慢，才有这篇文章。秃子最怕人说亮！如果从业5年以上,还在说语言的事儿..那估计月薪一般都少于20K1、别说5年，即使是十多年还在拿语言说事的也不少见啊，不信去翻翻那些牛人的博客嘛，新闻也经常有。2、在二三线城市，特别是在某些家乡小县城，20K已经算比较高了；3、月薪并不能衡量技术水平高低，尽管大部分时候两者之间成正比；4、为什么从业5年以上了就不能拿语言说事呢？为什么就不能说某个秃子头顶亮呢？为什么不能说那个游行的皇帝没穿衣服呢？1. 你和我对牛人的定义是不同的, 你眼中的牛人,也许是很多人眼里的卢瑟2. 月薪能衡量你的屌丝程度, 薪水越低,越屌丝,这年头,是金子早就被人抢了. 薪水不高,说明很大程度上不是金子3. 可以说啊, 你哪怕说个20年,30年,40年都没问题. 你如果把这当爱好,倒也无妨. 但是如果认为这些是你职业发展的关键,那么很遗憾,你要重新定义价值观了1、比我水平高的，我都会向他学习，我会经常去翻很多人的博客学习，甚至是看他们的评论；2、/developer/rubyphp/ 这里面的某些人算是牛人了吧？我只是举个例子，像一些被称为大师的也经常“还在说语言的事儿”；3、如果你非要用月薪来衡量的话，我也无法可说，只能说价值观不一样而已。我认为技术很不错的一些朋友在创业公司，一个月才几K而已。有的干脆自己在创业。不是所有人都会像你这么看重月薪——天天惦记着月薪能涨多少，永远都是给别人打工；4、“你如果把这当爱好,倒也无妨”——这个算什么爱好呢？说自己心里想说的话何错之有呢？“但是如果认为这些是你职业发展的关键”——我没想过什么职业发展，我只想过人生发展。“你要重新定义价值观了”——我只能定义自己的价值观！很多技术很好的人也会说语言也会批评语言我认同，但是好像关注点很多情况下都跟你不一样。他们关注的更多的是一个语言本身语法上是否有缺陷，使用起来怎么样，就算是关注到性能的话也是更多的关注到底层的东西，更根源的东西。
为什么各个地方的人还在骑自行车呢？为什么还有人在看中医呢？为什么还有企业在用Windows2000呢？为什么还有那么多人用IE6呢？你说的这些不是主流了，你要说一个和java一样是主流的1、单单一个慢并不会导致一门语言死掉，Java其他方面的优势会让它继续生存下去；2、就像改革开放前的主流交通工具是自行车一样，现在还是吗？难保明天的Java不是昨日的自行车，今日的IE6；3、因为Java的一些缺点和缺陷，其他相应的语言也慢慢兴起。不然Java这么牛X，全用Java算了，还有必要搞其他语言么？即使是在服务器这一Java的传统领域，也被其他语言慢慢侵占。4、不是说哪门语言好，哪门语言坏，而是对Java某一方面的主观感受。正是因为有很多人感觉Java慢，才有这篇文章。秃子最怕人说亮！其他相应的语言是指啥？既我所知，主流语言除了Net比java年轻外，PHP/Python/Ruby/Perl/VB....都不比Java年轻，但死的死（VB和死了差不多），软的软。。这就说明了原因。另外京东的NET转Java了，淘宝之前的PHP转Java了咋把VB也扯进去了呢？难道要跟VB比桌面应用？那更慢！要比也是delphi跟VB比吧？你可能是想说ASP？这玩意从鼎盛时期慢慢到被淘汰是理所当然的事情，尽管还有些网站在用。除了你说的那些，还有Node.js。如果我没记错的话，PHP/Python/Ruby/Perl这些最初都是个人弄出来的，貌似都只是玩一玩的性质，当时离成熟更是差很远。只有Java一开始就是Sun这样的大公司倾力推出，无论人力财力推广能力都不是前者能比的。尽管Java推出的时候并不仅限于服务器和web，但到鼎盛时期几乎成了服务器必备语言和做网站的代名词，即使如此，其他如PHP/Python/Ruby等等在这个头巨兽的阴影下面生存了下来，而且现在也活得还不错！至少在web方面，PHP/Python/Ruby/C#都从Java那里抢到了一些地盘。淘宝从PHP转到Java大概是七八年前的事情了吧？提这个是想说明什么呢？说明Java不慢？你了解当时为什么要转吗？淘宝除了在用Java外，还有C/C++吧？而且淘宝有些地方也还在用PHP、百度、新浪、facebook、twitter等等也在用。这样的大公司很少只用一种语言的，但一般在涉及性能方面的时候都是用C/C++，至少我知道的就是这样。京东这样公司从.NET转到Java是非常明智的选择，没什么好说的。你举再多的例子，秃子的头顶还是亮，改变不了什么。不然Java也不会老是优化什么虚拟机搞什么JIT！而且JIT只能起到优化部分的作用，用不好也许会更慢！抱怨Java慢的声音也还将会继续存在！什么叫在“涉及性能方面的时候”用C/C++呢？你们都搞不清楚状况，大多时候是习惯问题，假如你先前用Apache或者Ngix用的好好，为啥不继续呢，各种程序也是C/C++的，为什么要大费周章换一套呢？这个不能说明Java慢。JAVA编写的程序比C++编写的块是常有的事情，现在通C＋＋ 和JAVA的程序员其实挺多的，拿快速排序、素数斐波那契数列这类小程序试了下，Java比C++块并不奇怪，而且这类小程序用C＋＋/JAVA都写一遍，也不会有什么算法问题。至于大一点 的程序，我举个列子，NASA World Wind是一个类似Google earth的程序，有Java和C#. NET两个版本，我试过Java版本，比Google Earth块多了。“JAVA编写的程序比C++编写的块是常有的事情”——我有时候也跑得比刘翔快！“是常有的事情”——如果你愿意继续在这个梦里，别人也没必要叫醒你！【什么叫在“涉及性能方面的时候”用C/C++呢？】——举个例子，在用PHP做web方面的应用时，有些地方直接用PHP来处理有点慢、内存占用也不小，这时候就只好用C来写一个PHP扩展。再比如做桌面客户端，企业里面有很多还是512M、甚至256M内存的老机器，CPU也还是P4的，Java写出来的东西启动慢也就算了，还特别占内存，用一会就更慢了，只好用VC++重做。这种个例只有我碰到过，还是非常常见？自己去问问！再举个例子，如果Nginx是用Java写的，你觉得会不会这么快流行开来？像web server这种对性能要求非常苛刻的应用，你觉得用Java合不合适？恕在下见识浅薄，在流行的web server里面还没看到用Java写的。【至于大一点 的程序，我举个列子，NASA World Wind是一个类似Google earth的程序，有Java和C#. NET两个版本，我试过Java版本，比Google Earth块多了。】—— 我对C#的认识浅薄，在语法上跟Java有点类似，而且最后打包的程序要带上.net framework（貌似有的不需要），让我不是太喜欢。在桌面应用方面，你用自己的眼睛看看就知道是什么情况了，大部分都是VC++/C#/VB/delphi之类的，平常人根本都没接触过Java写的软件，只有我们这种码农偶尔用一下Java写的IDE，但用过的很多人都会抱怨启动慢、占内存大之类的！如果只是我一个或少数几个人在抱怨，估计也就不会有楼主的这篇文章！
哈哈,工资就是重点,鳄鱼先生高明,高级黑啊.我是想说：大部分企业雇佣C++程序员绝对是脑残。一门没落的语言真不值得再讨论了！简单的例子。有本事你java虚拟机不要用c++写啊！用java写啊！可以说java就是寄生在c++上面的一种半残废语言！可以说没有java世界照样转，唯一多出来的只是那些不懂指针不懂内存的人的蛋蛋的忧伤吧！不懂内存管理...呵呵！谁说Java是C++的，里面压根就没有一行C++程序。
内存便宜还是一个合格的C++程序员便宜？手机的内存可以随便添加？你会用C++去开发手机应用？实话讲到现在还想不通还有那么多人追捧C++。
哈哈,工资就是重点,鳄鱼先生高明,高级黑啊.我是想说：大部分企业雇佣C++程序员绝对是脑残。一门没落的语言真不值得再讨论了！简单的例子。有本事你java虚拟机不要用c++写啊！用java写啊！可以说java就是寄生在c++上面的一种半残废语言！可以说没有java世界照样转，唯一多出来的只是那些不懂指针不懂内存的人的蛋蛋的忧伤吧！不懂内存管理...呵呵！第一版本的C++编译器是由C开发的，C编译器是汇编和机器码实现的，你干脆学机器码吧！ 内存，寄存器都任你控制。
欢迎贴出比较数据你第一天用Java，还是一直只用Java？还是从来不上技术性的网站，还是从来不看其他程序员的博客？欢迎贴出数据/blog/1055377/art/089.htmhttp://www.keakon.net//Java%E3%80%81PHP%E3%80%81Python%E4%B8%8EMySQL%E4%BA%A4%E4%BA%92%E7%9A%84%E6%80%A7%E8%83%BD%E6%B5%8B%E8%AF%95跟Java做性能对比测试的，这么多年我都不知道看过多少了，有国外国内，有的测试设计很好，有的设计欠周全，stackoverflow也经常有这方面的讨论，但总体上来说，Java一般都不占什么优势！如果你开始就从java入手的话，你一定认为内存可以无限大！额……我应该可以认为你是完全不懂java，但是了解java比C/C++慢，并且内存占用大。是这样吧- -的确不懂！第一眼见到这个语言就觉得是个拯救不懂内存的人的救命稻草！
欢迎贴出比较数据你第一天用Java，还是一直只用Java？还是从来不上技术性的网站，还是从来不看其他程序员的博客？欢迎贴出数据/blog/1055377/art/089.htmhttp://www.keakon.net//Java%E3%80%81PHP%E3%80%81Python%E4%B8%8EMySQL%E4%BA%A4%E4%BA%92%E7%9A%84%E6%80%A7%E8%83%BD%E6%B5%8B%E8%AF%95跟Java做性能对比测试的，这么多年我都不知道看过多少了，有国外国内，有的测试设计很好，有的设计欠周全，stackoverflow也经常有这方面的讨论，但总体上来说，Java一般都不占什么优势！如果你开始就从java入手的话，你一定认为内存可以无限大！额……我应该可以认为你是完全不懂java，但是了解java比C/C++慢，并且内存占用大。是这样吧- -不多就java的内涵和c++相比幼稚到不好意思
内存便宜还是一个合格的C++程序员便宜？手机的内存可以随便添加？你会用C++去开发手机应用？实话讲到现在还想不通还有那么多人追捧C++。我说的是应用方面， 没说在什么机器上做开发， 你开发出来的东西是要用的-- ，不是只放在一台很牛X 的机器能运行的很爽就行--
哈哈,工资就是重点,鳄鱼先生高明,高级黑啊.我是想说：大部分企业雇佣C++程序员绝对是脑残。一门没落的语言真不值得再讨论了！简单的例子。有本事你java虚拟机不要用c++写啊！用java写啊！可以说java就是寄生在c++上面的一种半残废语言！可以说没有java世界照样转，唯一多出来的只是那些不懂指针不懂内存的人的蛋蛋的忧伤吧！不懂内存管理...呵呵！第一版本的C++编译器是由C开发的，C编译器是汇编和机器码实现的，你干脆学机器码吧！ 内存，寄存器都任你控制。java 还要弄个jvm , 还要弄个Native
你该换电脑了。。Java总是觉得硬件能解决速度，理论上是可以无限提升，只要硬件都是可以无限提升的，这句话说了多少年了，我酷睿I7，16G内存，做为一个个人电脑还不够吗，可并没有明显的提升
顶一个，java就是烂}