blocks|key|4839163|text|方法和方法参数上的最后一个修饰符对性能没有任何帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4839164|此外，Java+HotSpot+wiki很好地概述了HotSpot使用的优化，以及如何在Java代码中有效地使用这些优化。|offset|length|4839165|entityMap|0|LINK|mutability|MUTABLE|url|https://wiki.openjdk.java.net/display/HotSpot/PerformanceTechniques^0|0|3|H|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

The final modifier on methods and method parameters doesn't help with the performance at all.

Also, the <a href="https://wiki.openjdk.java.net/display/HotSpot/PerformanceTechniques" rel="nofollow noreferrer">Java HotSpot wiki</a> gives a good overview of the optimizations used by HotSpot and how to efficiently use them in Java code.

blocks|key|1233225|text|人们将String+a+=+"this"+%2B+var1+%2B+"+is+"+%2B+var2;替换为对StringBuilder或StringBuffer的多个调用。它实际上已经在幕后使用了StringBuilder。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1233226|entityMap^0|3|15|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

People replacing <code>String a = "this" + var1 + " is " + var2;</code> with multiple calls to StringBuilder or StringBuffer. It actually already uses StringBuilder behind the scenes.

blocks|key|3427883|text|在开始性能优化之前，有必要定义时间/内存权衡。这就是我如何为我的内存/时间关键型应用程序做到这一点(重复上面的一些答案，以完成)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3427884|3427885|Rule+#1永远不会在开发的早期阶段做性能优化，如果你真的不需要，也不会这么做。如果决定这样做，那么：|ordered-list-item|offset|length|style|BOLD|3427886|使用profiler来查找瓶颈，审查源代码以找到与定义的时间/内存和合适的算法(例如迭代和递归等)最适合的bottlenecks;|3427887|choose合适的数据结构的原因；|3427888|避免使用java库中的同步对象，如果你显式/隐式地创建新对象时不需要它。当且仅当您确定它们不适合您的requirements.|3427889|Use时，java附带的|3427890|override/re-implement数据类型/算法用于测试所选算法/数据结构的性能的小型独立测试。|3427891|3427892|entityMap^0|0|0|0|Y|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Y|8|@$F|Z|G|10|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|11|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|12|8|@]|9|@]|A|$]]|$1|N|3|O|5|E|7|13|8|@]|9|@]|A|$]]|$1|P|3|Q|5|E|7|14|8|@]|9|@]|A|$]]|$1|R|3|S|5|E|7|15|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|V|$]]

It is necessary to define time/memory trade-offs before starting the performance optimization. This is how I do it for my memory/time critical application (repeating some answers above, to be complete):

<ol>
<li>Rule #1 Never do performance optimization on the earlier stage of development. Never do it if your don't need it really. If decided to do it, then:</li>
<li>use profiler to find bottlenecks, review the source code to find the reasons for bottlenecks;</li>
<li>choose appropriate data structure with the best fit into the defined time/memory trade-offs;</li>
<li>choose appropriate algorithms (e.g. iteration vs recursion, etc);</li>
<li>avoid using synchronized objects from java library, if you don't need it really;</li>
<li>avoid explicitly/implicitly new object creation;</li>
<li>override/re-implement data types/algorithms coming with the java if and only if you are sure they doesn't fit your requirements.</li>
<li>Use small, independent tests to test the performance of chosen algos/data structures.</li>
</ol>

blocks|key|3427728|text|2001年，我为一款J2ME手机开发了应用程序。它只有一块砖头那么大。几乎相当于一块砖头的计算能力。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3427729|要让Java应用程序在它上面运行，需要以尽可能过程化的方式编写它们。此外，非常大的性能改进是捕获ArrayIndexOutOfBoundsException以在向量中的所有项上退出for循环。想想看！|offset|length|style|CODE|3427730|即使在Android上，也有“快速”循环遍历数组中的所有项和“慢”方式编写相同的东西，正如dalvik+VM内部的Google+IO视频中所提到的那样。|3427731|然而，在回答你的问题时，我会说，如今必须对这类事情进行微优化是非常不寻常的，而且我进一步预计，在JIT虚拟机(甚至是添加了JIT的新Android+2.2虚拟机)上，这些优化是没有意义的。在2001年，该手机运行的KVM解释器的频率为33+the。现在它运行dalvik+-一个比KVM快得多的虚拟机-在500+Now到1500+Now，使用更快的ARM架构(更好的处理器，甚至考虑到时钟速度的提高)与L1+e.t.c。然后JIT就来了。|3427732|无论是在手机上还是在使用i7的桌面上，我们还不能适应用Java语言进行直接像素操作的领域，所以仍然有一些普通的日常代码对Java语言来说还不够快。我对此持怀疑态度，我写了一些图像操作代码，我看到了Here's+an+interesting+blog和原生的像素循环之间的数量级。也许我错过了什么把戏...？:D|3427733|entityMap|0|LINK|mutability|MUTABLE|url|http://strattonbrazil.blogspot.com/2008/11/sunflow-java-ray-tracer.html^0|0|1C|U|0|0|0|2Q|Q|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@]|9|@$D|12|E|13|1|14]]|A|$]]|$1|N|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

In 2001 I made apps for a J2ME phone. It was the size of a brick. And very nearly the computational power of a brick.

Making Java apps run acceptably on it required writing them in as procedural fashion as possible. Furthermore, the very large performance improvement was to catch the <code>ArrayIndexOutOfBoundsException</code> to exit for-loops over all items in a vector. Think about that!

Even on Android there are 'fast' loops through all items in an array and 'slow' ways of writing the same thing, as mentioned in the Google IO videos on dalvik VM internals.

However, in answer to your question, I would say that it is most unusual to have to micro-optimise this kind of thing these days, and I'd further expect that on a JIT VM (even the new Android 2.2 VM, which adds JIT) these optimisations are moot.
In 2001 the phone ran KVM interpreter at 33MHz. Now it runs dalvik - a much faster VM than KVM - at 500MHz to 1500MHz, with a much faster ARM architecture (better processor even allowing for clock speed gains) with L1 e.t.c. and JIT arrives.

We are not yet in the realms where I'd be comfortable doing direct pixel manipulation in Java - either on-phone or on the desktop with an i7 - so there are still normal every-day code that Java isn't fast enough for. <a href="http://strattonbrazil.blogspot.com/2008/11/sunflow-java-ray-tracer.html">Here's an interesting blog</a> that claims an expert has said that Java is 80% of C++ speed for some heavy CPU task; I am sceptical, I write image manipulation code and I see an order of magnitude between Java and native for loops over pixels. Maybe I'm missing some trick...? :D

blocks|key|3427972|text|JVM不要手动调用垃圾回收器，它会损害现代|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3427973|的性能，而不是Long不会节省太多空间，但会限制数字的范围。|ordered-list-item|3427974|避免手动生成枚举类，而使用内置枚举。Java1.5引入了实枚举，使用它们。|3427975|3427976|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|K|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|L|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

<ol>
<li>Don't manually call the garbage collector, it hurts performance on modern JVM implementations.</li>
<li>Integer instead of Long will not save much space, but will limit the range of the numbers.</li>
<li>Avoid hand generated Enum classes and use the built in Enum instead. Java 1.5 introduced real Enums, use them.</li>
</ol>

blocks|key|4839400|text|使用内存小于32+x64+的x64+JVM时的|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4839401|与32位JVM相比，64位JVM使用的内存要多30%25-50%25，因为普通对象指针更大。通过使用JDK6%2B，您可以大大减少这一因素。|offset|length|style|BOLD|4839402|从JDK6u6p到JDK6u22，它是可选的，可以通过添加JVM参数来启用：|4839403|-XX:%2BUseCompressedOops+|code-block|syntax|javascript|4839404|在JDK6u23+(也是JDK7)中，它是默认启用的。更多信息here。|4839405|entityMap|0|LINK|mutability|MUTABLE|url|http://blog.juma.me.uk/2008/10/14/32-bit-or-64-bit-jvm-how-about-a-hybrid/^0|0|0|1S|0|0|12|0|0|0|10|V|4|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@$D|10|E|11|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|12|8|@$D|13|E|14|F|G]]|9|@]|A|$]]|$1|J|3|K|5|L|7|15|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|16|8|@$D|17|E|18|F|G]]|9|@$D|19|E|1A|1|1B]]|A|$]]|$1|Q|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

When using x64 JVM with RAM less than 32GB:

64bit JVM use 30%-50% more memory in comparision to 32bit JVM because of bigger ordinary object pointers. You can heavily reduce this factor by using JDK6+.

From JDK6u6p to JDK6u22 it is optional and can be enabled by adding JVM argument:

<pre><code>-XX:+UseCompressedOops 
</code></pre>

From JDK6u23 (JDK7 also) it is enabled by default. More info <a href="http://blog.juma.me.uk/2008/10/14/32-bit-or-64-bit-jvm-how-about-a-hybrid/" rel="nofollow">here</a>.

blocks|key|3427942|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3427943|“过早的优化是万恶之源”(Donald+Knuth)|ordered-list-item|3427944|只有在每种情况下都应该分析代码，优化才是有用的。也许你可以用一个快速的HashSet代替TreeSet，因为你不需要排序功能，或者你可以使用float而不是double(看看Android+SDK)。|3427945|如果没有技术帮助你可以尝试重写一段代码并通过JNI调用它，这样原生代码就可以工作了。|offset|length|3427946|3427947|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/JNI^0|0|0|0|M|3|0|0|0^^$0|@$1|2|3|-4|4|5|6|S|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|T|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|U|7|@]|8|@]|9|$]]|$1|F|3|G|4|C|6|V|7|@]|8|@$H|W|I|X|1|Y]]|9|$]]|$1|J|3|-4|4|5|6|Z|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|10|7|@]|8|@]|9|$]]]|L|$M|$4|N|O|P|9|$Q|R]]]]

<ol>
<li>"Premature optimization is the root of all evil"(Donald Knuth)</li>
<li>It is useful to optimize only the bottlenecks.</li>
<li>You should analyze the code in each situation. Maybe you can replace the TreeSet by a fast HashSet because you don't need the sorting feature or maybe you can use float instead of double( look at the Android SDK).</li>
<li>If no technique helps you can try to rewrite a piece of code and call it via <a href="http://en.wikipedia.org/wiki/JNI" rel="nofollow">JNI</a>, so that native code is working.</li>
</ol>

blocks|key|4839437|text|我发现上面的链接已经过时了。这里有一个关于Java优化的新版本：http://www.appperfect.com/support/java-coding-rules/optimization.html|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4839438|entityMap|0|LINK|mutability|MUTABLE|url|http://www.appperfect.com/support/java-coding-rules/optimization.html^0|W|1X|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

I found links above outdated. Here is a new one on Java optimization: <a href="http://www.appperfect.com/support/java-coding-rules/optimization.html" rel="nofollow">http://www.appperfect.com/support/java-coding-rules/optimization.html</a>

There are number of performance tips made obsolete by Java compiler and especially <a href="http://en.wikipedia.org/wiki/Profile-guided_optimization" rel="noreferrer">Profile-guided optimization</a>. For example, these platform-provided optimizations can drastically (according to sources) reduces the cost of virtual function calls. VM is also capable of method inlining, loop unrolling etc.

What are other performance optimization techniques you came around still being applied but are actually made obsolete by optimization mechanisms found in more modern JVMs?

Obsolete Java Optimization Tips

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

有许多性能技巧已经被Java编译器，特别是淘汰了。例如，这些平台提供的优化可以极大地(根据消息来源)降低虚拟函数调用的成本。VM还具有方法内联、循环展开等功能。您遇到的其他性能优化技术还有哪些仍在应用，但实际上已被更现代的JVM中的优化机制淘汰了？

问过时的Java优化提示
EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问过时的Java优化提示EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问过时的Java优化提示
EN