指针大小 - 到底有多大的对象引用？ [英] Pointer Size - How big is an object reference?
问题描述
这个问题很简单，那是什么在机器人的Java虚拟机的参考消耗的大小？
The question is simple, what is the size that a reference in Androids Java VM consume?
我的意思是：
如果我们有
String str = "Watever";
我需要什么 STR 需要，而不是Watever。 - Watever是什么保存的位置，它是指针（或引用）的 STR 持有，指向。
I need what str takes, not "Watever". -- "Watever" is what's saved in the location to which the pointer (or the reference) that str is holding, is pointing to.
此外，
如果我们有
String str = null;
多少内存它消耗？是不是比其他 STR ??
现在，如果我们有：
Object obj[] = new object[2];
多少钱 OBJ 消耗多少呢 OBJ [1] 和 OBJ [2] 消耗？
how much does obj consume and how much does obj[1] and obj[2] consume?
的原因queston如下：。（如果有人能推荐一下）
The reason for the queston is the following: (in case someone can recommend something).
我工作的一个应用程序，maneges从互联网上下载了许多照片。 我开始进行存储在一个银行那些照片（图片列表上consisten）。
I'm working on an app that maneges many pictures downloaded from internet. I started storing those pictures on a "bank" (that consisten on a list of pictures).
在显示在画廊的那些照片，我用来搜索的图片列表中（慢），然后，如果再把图片是不存在的，我用来显示时间下载图像，直到图像被下载。
When displaying those pictures on a gallery, I used to search for the picture in the list (SLOW) and then, if then picture wasn't there, I used to show a temporal downloading image until the picture was downloaded.
由于发生在UI线程，应用程序变得非常慢，所以我想到了实施上，而不是名单我有银行的哈希表。
Since that happened on the UI Thread, the app became very slow, so I thought about implementing a hash table on the bank instead of the list I had.
正如我以前解释的那样，出现这种搜索在UI线程（我不能改变这种状况）。正因为如此，冲突可以成为一个问题，如果他们启动线程放缓。
As I explained before, this search occurs in the UI Thread (and I can't change that). Because of that, collisions can become a problem if they start slowing the thread.
我已阅读，为了平衡时间和空间效率，哈希表应该是大约半满，但是这使得碰撞ocurr的时间（不实际的UI线程）的一半。这使我想到有一个很长的哈希表（与保存的图片的量），并使用更多的内存（有较少免费VMHeap）。
I have read that "To balance time and space efficiency, the hash table should be around half full", but that makes collisions ocurr half of the time (Not practical for the UI Thread). That makes me think about having a very long hash table (compared to the amount of pictures saved) and use more RAM (having less free VMHeap).
在确定哈希表的大小，我想知道有多少内存将是消费，以免exagerate。
Before determining the size of the hash table, I wanted to know how much memory would it consume in order not to exagerate.
我知道，相对于这些照片可能消耗内存的哈希表的大小可能非常小，但我想确保我没有消耗超出必要更多的内存。
I know that the size of the hash table might be very small compared to the memory that the pictures might consume, but I wanted to make sure I wasn't consuming more memory than neccesary.
在问这个问题，我搜索，其他地方之间，在
Before asking this question i searched, between other places, in
<一个href="http://stackoverflow.com/questions/981073/how-big-is-an-object-reference-in-java-and-$p$pcisely-what-information-does-it-con">How大是在Java和$ P $的对象引用pcisely它包含哪些信息？
在Java 引用类型大小
（是的，我知道两个地方的相互矛盾，这就是对这一问题的原因之一）。
(Yes, I know two of the places contradict each other, thats part of the reason for the question).
如果你以任何理由，不明白的地方，或想了解更多信息，请发表评论，我会尽快尽我所能作出回应。
If you, by any reason, don't understand something, or want more information, please leave a comment, I'll respond as soon as I can.
比你柠了。
推荐答案
一个对象或数组引用占有在32位JVM或Davlik VM 1个32位字（4字节）。 A 空采用相同的空间作为参考。 （它有，因为空了，可安装在参考类型的插槽;即实例字段，局部变量等）
A object or array reference occupies one 32 bit word (4 bytes) on a 32 bit JVM or Davlik VM. A null takes the same space as a reference. (It has to, because a null has to fit in a reference-typed slot; i.e. instance field, local variable, etc.)
在另一方面，对象占用至少2 32位字（8字节），和一个阵列占据最小3 32位字（12字节）。的实际尺寸依赖于数和种领域为对象，并在元件的数组的数量和种类。
On the other hand, an object occupies a minimum of 2 32 bit words (8 bytes), and an array occupies a minimum of 3 32 bit words (12 bytes). The actual size depends on the number and kinds of fields for an object, and on the number and kind of elements for an array.
对于64位JVM中，参考的长度为64位，除非你已经配置为使用COM pressed指针的JVM：
For a 64 bit JVM, the size of a reference is 64 bits, unless you have configured the JVM to use compressed pointers:
-XX：+ UseCom pressedOops允许使用COM $ P $的pssed指针（对象引用重新psented 32位偏移量，而不是64位指针$ P $）与Java堆优化的64位性能尺寸小于32GB。
-XX:+UseCompressedOops Enables the use of compressed pointers (object references represented as 32 bit offsets instead of 64-bit pointers) for optimized 64-bit performance with Java heap sizes less than 32gb.
这是你的问题的症结，我想。
This is the nub of your question, I think.
在确定哈希表的大小，我想知道有多少内存将是消费，以免exagerate。
Before determining the size of the hash table, I wanted to know how much memory would it consume in order not to exagerate.
如果您分配一个的HashMap 或的Hashtable 具有较大的初始大小，大部分的空间将被占用由散列数组。这是引用数组，因此规模将 3 + INITIALSIZE 32位字。这是不可能的，这将是显著......除非你得到你的尺寸的估计完全错误的。
If you allocate a HashMap or Hashtable with a large initial size, the majority of the space will be occupied by the hash array. This is an array of references, so the size will be 3 + initialSize 32 bit words. It is unlikely that this will be significant ... unless you get your size estimate drastically wrong.
不过，我觉得你可能担心不必要的有关性能。如果您在分配一个默认的存储对象的HashMap 或的Hashtable ，班会自动调整哈希表，因为它得到大。所以，只要你的对象有一个体面的哈希函数（不是太慢了，不散列一切少数值）的哈希表不应该是一个直接的CPU性能的关注。
However, I think you are probably worrying unnecessarily about performance. If you are storing objects in a default allocated HashMap or Hashtable, the class will automatically resize the hash table as it gets larger. So, provided that your objects have a decent hash function (not too slow, not hashing everything to a small number of values) the hash table should not be a direct CPU performance concern.
这篇关于指针大小 - 到底有多大的对象引用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
