blocks|key|78617|text|我不是Java历史学家但是..。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|78618|HotSpot似乎本质上是由甲骨文维护和分发的一种特定类型的JVM虚拟机的商标名称。它的名字来源于即时编译器，该编译器可以检测频繁执行的代码的“热点”，并对其进行动态优化。|78619|Android+Runtime也具有这种JIT编译器行为，以及在安装时将java字节码提前编译为本机代码。|78620|这使我认为ART与HotSpot属于同一类别(就此检查而言)，因此您应该使用此调用的“空数组”版本。|78621|78622|当有疑问的时候，测量一下！|78623|确定的最好方法是编写一个测试程序，该程序执行方法的两个版本，并测量哪个版本运行得更快。|78624|78625|资料来源：|78626|78627|https://en.wikipedia.org/wiki/HotSpot|unordered-list-item|offset|length|78628|https://en.wikipedia.org/wiki/Android_Runtime|78629|78630|entityMap|0|LINK|mutability|MUTABLE|url|1^0|0|0|0|0|0|0|0|0|0|0|0|11|0|0|0|19|1|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|18|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|19|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1B|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1C|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1E|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1G|8|@]|9|@$T|1H|U|1I|1|1J]]|A|$]]|$1|V|3|W|5|S|7|1K|8|@]|9|@$T|1L|U|1M|1|1N]]|A|$]]|$1|X|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]]|Z|$10|$5|11|12|13|A|$14|R]]|15|$5|11|12|13|A|$14|W]]]]

I am not a Java historian, but...

HotSpot appears to be essentially a brand name for a particular kind of JVM maintained and distributed by Oracle. It takes its name from the just-in-time compiler that can detect "hot spots" of frequently-executed code and optimize them on the fly.

The Android Runtime also has this JIT compiler behavior, as well as ahead-of-time compilation of java bytecode into native machine code at installation time.

This makes me think that ART falls into the same category as HotSpot (as far as this inspection is concerned), and therefore that you should use the "empty array" version of this call.

<hr>

When in doubt, measure!

The best way to know for sure is to write a test program that executes both versions of the method and measures which one runs faster.

<hr>

Sources:

<ul>
<li><a href="https://en.wikipedia.org/wiki/HotSpot" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/HotSpot</a></li>
<li><a href="https://en.wikipedia.org/wiki/Android_Runtime" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Android_Runtime</a></li>
</ul>

blocks|key|76830|text|问得好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|76831|https://shipilev.net/blog/2016/arrays-wisdom-ancients/#_new_reflective_array|offset|length|76832|76833|+底线：toArray(new+T[0])看起来更快、更安全、合同更干净，因此现在应该是默认选择。未来的VM优化可能会缩小toArray(new+T[size])的这一性能差距，使当前的“被认为是最优的”使用与实际最优的使用情况相当。toArray+API中的Further+improvements将遵循与toArray(new+T[0]) - 相同的逻辑，集合本身应该创建适当的存储。|blockquote|style|BOLD|CODE|76834|76835|entityMap|0|LINK|mutability|MUTABLE|url|1|https://bugs.openjdk.java.net/browse/JDK-8060192|2|http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2015-December/000047.html^0|0|0|24|0|0|0|1|2|4|H|1P|K|39|7|4A|H|3M|7|1|3U|C|2|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@$D|10|E|11|1|12]]|A|$]]|$1|F|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|14|8|@$D|15|E|16|J|K]|$D|17|E|18|J|L]|$D|19|E|1A|J|L]|$D|1B|E|1C|J|L]|$D|1D|E|1E|J|L]]|9|@$D|1F|E|1G|1|1H]|$D|1I|E|1J|1|1K]]|A|$]]|$1|M|3|-4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|C]]|U|$5|Q|R|S|A|$T|V]]|W|$5|Q|R|S|A|$T|X]]]]

Great question.

<a href="https://shipilev.net/blog/2016/arrays-wisdom-ancients/#_new_reflective_array" rel="noreferrer">https://shipilev.net/blog/2016/arrays-wisdom-ancients/#_new_reflective_array</a>

<blockquote>
 Bottom line: <code>toArray(new T[0])</code> seems faster, safer, and contractually
 cleaner, and therefore should be the default choice now. Future VM
 optimizations may close this performance gap for <code>toArray(new T[size])</code>,
 rendering the current "believed to be optimal" usages on par with an
 actually optimal one. <a href="https://bugs.openjdk.java.net/browse/JDK-8060192" rel="noreferrer">Further</a> <a href="http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2015-December/000047.html" rel="noreferrer">improvements</a> in <code>toArray</code> APIs would
 follow the same logic as <code>toArray(new T[0])</code> — the collection itself
 should create the appropriate storage.
</blockquote>

blocks|key|76865|text|它读取since+late+updates+of+OpenJDK+6，并且使用哪个运行时来运行它并不重要-因为在Dalvik上作为编译类运行的代码的语言级别可能是Java6、7、8。重要的是项目使用哪个语言级别来编译它。例如：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|76866|compileOptions+{
++++sourceCompatibility+JavaVersion.VERSION_1_8
++++targetCompatibility+JavaVersion.VERSION_1_8
}|code-block|syntax|javascript|76867|设置JavaVersion.VERSION_1_6可能甚至会禁用检查投诉...在这些过时的设备上修复性能问题可能不值得努力-一些/大多数甚至可能不会受到影响，因为只有“早期更新”的行为与所有后续更新的行为不同。|76868|entityMap^0|3|V|0|0|2|N|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|S|8|@$9|T|A|U|B|C]]|D|@]|E|$]]|$1|M|3|-4|5|6|7|V|8|@]|D|@]|E|$]]]|N|$]]

It reads <code>since late updates of OpenJDK 6</code> and it does not matter which run-time is being used to run it - because the language-level of the code, which runs as compiled classes on Dalvik, might be Java 6, 7, 8. it only matters which language-level the project used to compile it. For example:
<pre><code>compileOptions {
 sourceCompatibility JavaVersion.VERSION_1_8
 targetCompatibility JavaVersion.VERSION_1_8
}
</code></pre>
Setting <code>JavaVersion.VERSION_1_6</code> might possibly even disable the inspection complaint... fixing performance issues on these dated devices is probably not worth the effort - and some/most might not even be affected, because only the &quot;earlier updates&quot; behave different than all what followed up.

when using <code>ar.toArray(new String[ar.size()])</code> Android studio 3.2.1 warns about pre-sized array and recommends empty array:

<blockquote>
 There are two styles to convert a collection to an array: either using
 a pre-sized array (like c.toArray(new String[c.size()])) or using an
 empty array (like c.toArray(new String[0]). In older Java versions
 using pre-sized array was recommended, as the reflection call which is
 necessary to create an array of proper size was quite slow. However
 since late updates of OpenJDK 6 this call was intrinsified, making the
 performance of the empty array version the same and sometimes even
 better, compared to the pre-sized version. Also passing pre-sized
 array is dangerous for a concurrent or synchronized collection as a
 data race is possible between the size and toArray call which may
 result in extra nulls at the end of the array, if the collection was
 concurrently shrunk during the operation. This inspection allows to
 follow the uniform style: either using an empty array (which is
 recommended in modern Java) or using a pre-sized array (which might be
 faster in older Java versions or non-HotSpot based JVMs).
</blockquote>

is it true for Android or just for java?

<blockquote>
 using a pre-sized array (which might be faster in older Java versions
 or non-HotSpot based JVMs).
</blockquote>

because i think Android is non-HotSpot its virtual machine was Dalvik and now it is ART

toArray with pre sized array

虚拟机

编译器

Android

Java

使用ar.toArray(new String[ar.size()]) Android studio 3.2.1时，警告数组大小已预置，建议使用空数组有两种方式可以将集合转换为数组:使用预置大小的数组(如c.toArray(  Stringc.size()或使用空数组(如c.toArray(新String) )。在较早...

问具有预调整大小的数组的toArray
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问具有预调整大小的数组的toArrayEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问具有预调整大小的数组的toArray
EN