过时的Java优化技巧

Java编译器已经淘汰了大量性能技巧,特别是Profile-guided优化 。 例如,这些平台提供的优化可以大幅(根据来源)降低虚函数调用的成本。 虚拟机也可以方法内联,循环展开等

还有哪些其他的性能优化技术还在应用中,但实际上已经被更现代的JVM中的优化机制所淘汰了?

方法和方法参数的最后一个修饰符根本无助于性能。

此外, Java HotSpot wiki对HotSpot使用的优化以及如何在Java代码中有效使用它们提供了一个很好的概述。

replaceString a = "this" + var1 + " is " + var2; 多次调用StringBuilder或StringBuffer。 它实际上已经在幕后使用了StringBuilder。

在开始性能优化之前,有必要定义时间/内存的权衡。 这是我如何做我的记忆/时间关键的应用程序(重复上面的一些答案,是完整的):

  1. 规则#1不要在开发的早期阶段进行性能优化。 千万不要这样做,如果你真的不需要它。 如果决定这样做,那么:
  2. 使用分析器来查找瓶颈,查看源代码找出瓶颈的原因;
  3. select最适合所定义的时间/存储器权衡的适当的数据结构;
  4. select适当的algorithm(例如迭代vsrecursion等);
  5. 避免使用来自Java库的同步对象,如果你真的不需要它;
  6. 避免显式/隐式地创build新对象;
  7. 当且仅当你确定它们不符合你的要求时,覆盖/重新实现java中的数据types/algorithm。
  8. 使用小型的独立testing来testingselect的algorithm/数据结构的性能。

在2001年,我为J2ME手机开发了应用程序。 这是一个砖的大小。 而且非常接近砖块的计算能力。

让Java应用程序可以正常运行需要尽可能以程序化的方式编写它们。 此外,性能的巨大提高是捕获ArrayIndexOutOfBoundsException以退出向量中所有项目的for-loops。 考虑一下!

即使在Android上,数组中的所有项目都有“快速”循环,写入相同内容的“缓慢”方式,正如在dalvik VM内部的Google IOvideo中提到的。

不过,在回答你的问题时,我想说现在微型优化这种事情是非常不寻常的,我还希望在JIT虚拟机(即使是新的Android 2.2 VM, JIT)这些优化是没有意义的。 2001年,这款手机以33MHz运行KVM解释器。 现在它运行dalvik – 一个比KVM更快的虚拟机 – 在500MHz到1500MHz之间,使用L1等更快的ARM架构(更好的处理器,甚至允许时钟速度增益)和JIT到达。

我们还没有在Java中直接进行像素处理的领域 – 无论是在电话上,还是在桌面上使用i7–所以仍然存在着Java不够快的每天都有的正常代码。 这里有一个有趣的博客 ,声称专家曾经说过,对于一些繁重的CPU任务,Java是C ++速度的80% 我很怀疑,我写image processing代码,我看到Java和本机之间的一个数量级的像素循环。 也许我错过了一些技巧…? :d

  1. 不要手动调用垃圾回收器,这会影响现代JVM实现的性能。
  2. 整数代替Long将不会节省太多空间,但会限制数字的范围。
  3. 避免手工生成的枚举类,并使用内置的枚举。 Java 1.5引入了真正的枚举,使用它们。

当使用RAM小于32GB的x64 JVM时

由于较大的普通对象指针,64位JVM与32位JVM相比使用了30%-50%的内存。 您可以通过使用JDK6 +大大减less这个因素。

从JDK6u6p到JDK6u22它是可选的,可以通过添加JVM参数来启用:

 -XX:+UseCompressedOops 

从JDK6u23(也是JDK7)它默认启用。 更多信息在这里 。

  1. “不成熟的优化是万恶之源”(Donald Knuth)
  2. 只优化瓶颈是有用的。
  3. 你应该在每种情况下分析代码。 也许你可以用一个快速的HashSetreplaceTreeSet,因为你不需要sortingfunction,或者你可以使用float而不是double(看看Android SDK)。
  4. 如果没有技术可以帮助您尝试重写一段代码并通过JNI调用,那么本机代码就可以工作。

我发现上面的链接过时了。 以下是关于Java优化的新内容: http : //www.appperfect.com/support/java-coding-rules/optimization.html