过时的Java优化提示

Question

Java编译器已经淘汰了许多性能提示，特别是Profile-guided optimization。例如，这些平台提供的优化可以极大地（根据来源）降低虚拟函数调用的成本。 VM还能够进行方法内联，循环展开等。

您现在使用的其他性能优化技术有哪些，但实际上已经被更现代的JVM中的优化机制淘汰了？

Answer 1

方法和方法参数的最终修饰符对性能没有任何帮助。

此外，Java HotSpot wiki概述了HotSpot使用的优化以及如何在Java代码中有效地使用它们。

Answer 2

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

Answer 3

在开始性能优化之前，有必要定义时间/内存权衡。这就是我如何为我的记忆/时间关键应用程序（重复上面的一些答案，完成）：

1. 规则＃1永远不要在开发的早期阶段进行性能优化。如果您真的不需要，请不要这样做。如果决定这样做，那么：
2. 使用分析器查找瓶颈，查看源代码以找出瓶颈的原因;
3. 选择适当的数据结构，最适合定义的时间/内存权衡;
4. 选择合适的算法（例如迭代与递归等）;
5. 如果你真的不需要，请避免使用java库中的同步对象;
6. 避免显式/隐式地创建新对象;
7. 覆盖/重新实现java附带的数据类型/算法，当且仅当您确定它们不符合您的要求时。
8. 使用小型独立测试来测试所选算法/数据结构的性能。

Answer 4

2001年，我为J2ME手机制作了应用程序。这是砖的大小。并且非常接近砖块的计算能力。

让Java应用程序在其上运行可接受，需要尽可能以程序方式编写它们。此外，非常大的性能改进是捕获ArrayIndexOutOfBoundsException以退出向量中的所有项目的for循环。想一想！

即使在Android上，阵列中的所有项目都会有“快速”循环，而“dalvik VM内部的Google IO视频中提到的”慢速“写入相同的东西。

然而，在回答你的问题时，我会说最近必须对这种事情进行微观优化是非常不寻常的，而且我还希望在JIT VM上（甚至是新的Android 2.2 VM） ，这增加了JIT）这些优化是没有实际意义的。 2001年，这款手机以33MHz的速度运行KVM解释器。现在它运行dalvik--一个比KVM快得多的VM - 在500MHz到1500MHz之间，具有更快的ARM架构（更好的处理器甚至允许时钟速度增益）和L1 e.t.c.和JIT到了。

我还不熟悉在Java中进行直接像素操作的情况 - 无论是在手机上还是在带有i7的桌面上 - 所以Java仍然没有正常的日常代码够了。声称专家的Here's an interesting blog表示，对于某些繁重的CPU任务，Java是C ++速度的80％;我持怀疑态度，我编写了图像处理代码，我看到Java和native之间的数量级，用于像素循环。也许我错过了一些技巧......？ ：d

Answer 5

1. 不要手动调用垃圾收集器，这会影响现代JVM实现的性能。
2. Integer而不是Long不会节省太多空间，但会限制数字的范围。
3. 避免手工生成的Enum类，而是使用内置的Enum。 Java 1.5引入了真正的Enums，使用它们。

Answer 6

使用RAM小于32GB的x64 JVM ：

64bit JVM与32位JVM相比，使用了30％-50％的内存，因为普通对象指针更大。您可以使用JDK6 +来大幅减少此因素。

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

-XX:+UseCompressedOops 

从JDK6u23（也是JDK7）它默认启用。更多信息here。

Answer 7

1. “过早优化是万恶之源”（Donald Knuth）
2. 仅优化瓶颈非常有用。
3. 您应该分析每种情况下的代码。也许你可以用快速的HashSet替换TreeSet，因为你不需要排序功能，或者你可以使用float而不是double（看看Android SDK）。
4. 如果没有技巧可以帮助您尝试重写一段代码并通过JNI调用它，那么本机代码就可以正常工作。

Answer 8

我发现上面的链接过时了。这是一个关于Java优化的新方法：http://www.appperfect.com/support/java-coding-rules/optimization.html