过时的Java优化技巧

方法和方法参数的最后一个修饰符对性能毫无帮助。

而且 Java HotSpot wiki 对HotSpot使用的优化以及如何在Java代码中有效地使用它们进行了很好的概述。

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

在开始性能优化之前,必须定义时间/内存权衡。对于内存/时间关键型应用程序,我就是这样做的(重复上面的一些答案,以便完成):

1. 规则1从不在开发的早期阶段进行性能优化。
2. 使用profiler查找瓶颈,查看源代码以查找瓶颈的原因;
3. 选择适当的数据结构,使其最适合定义的时间/内存权衡;
4. 选择适当的算法(例如迭代与递归等);
5. 避免使用java库中的同步对象,如果您不需要它的话;
7. 重写/重新实现java附带的数据类型/算法,前提是并且仅当您确定它们不符合您的需求时。
8. 使用小型独立测试来测试所选算法/数据结构的性能。

2001年,我为一款J2ME手机开发了应用程序。它有砖头那么大。几乎是砖块的计算能力。

要使Java应用程序在it上运行得可接受,需要以尽可能过程化的方式编写它们。此外,非常大的性能改进是 ArrayIndexOutOfBoundsException 在向量中的所有项上退出for循环。想想看!

然而,在回答您的问题时,我想说,现在必须对这种事情进行微观优化是非常不寻常的,而且我还希望在JIT虚拟机(甚至是添加了JIT的新Android 2.2vm)上,这些优化是没有意义的。

我们还没有进入在Java中直接操作像素的领域——无论是在手机上还是在i7桌面上——所以仍然有正常的日常代码,而Java的速度还不够快。 Here's an interesting blog 专家声称Java是80%的C++速度,对于一些重CPU任务,我怀疑,我写图像处理代码,我看到java和java之间的一个数量级,用于像素上的循环。也许我错过了什么把戏。。。?:天

1. 不要手动调用垃圾收集器,这会损害现代JVM实现的性能。
2. 整数代替Long不会节省太多空间,但会限制数字的范围。
3. 避免手动生成枚举类,而是使用内置枚举。Java1.5引入了真正的枚举,使用它们。

:

与32位JVM相比,64位JVM使用的内存多30%-50%,因为普通对象指针更大。使用JDK6+可以大大降低这个因素。

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

-XX:+UseCompressedOops 

从JDK6u23(也就是JDK7)开始,它默认启用。更多信息 here

1. “过早的优化是万恶之源”(唐纳德·克努特)
2. 只优化瓶颈是有用的。
4. 如果没有任何技术可以帮助您尝试重写一段代码并通过 JNI ,因此本机代码正在工作。

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