对象引用有多大? [英] How big is an object reference?
问题描述
Android的Java VM中的引用占用的大小是多少?
更多信息:
我的意思是，如果我们有
String str ="Watever"; 我需要 str 需要什么，而不是"Watever" .-"Watever" 是 str 所持有的指针(或引用)指向的位置中保存的内容.
如果有的话
String str = null; 它消耗多少内存?与其他 str 一样吗?
现在，如果我们有:
对象obj [] =新对象[2]; obj 消耗多少， obj [1] 和 obj [2] 消耗多少?
问题的原因如下:(以防有人可以推荐一些东西).
我正在开发一个应用程序，该应用程序管理着许多从互联网下载的图片.我开始将那些图片存储在银行"存储库中.(由图片列表组成).
在画廊上显示这些图片时，我曾经在列表中搜索图片(慢速)，然后，如果没有图片，我就一直显示临时下载图片，直到图片被下载为止./p>
由于发生在UI线程上，因此该应用程序变得非常慢，因此我考虑在银行而不是我拥有的列表上实现哈希表.
正如我之前解释的那样，此搜索在UI线程中进行(并且我无法更改).因此，如果冲突开始减慢线程速度，就会成为问题.
我已经读到为了平衡时间和空间效率，哈希表应该大约是满的一半"，但是这使得冲突发生的时间是一半(对于UI线程不切实际).那让我考虑使用一个非常长的哈希表(与保存的图片数量相比)并使用更多的RAM(具有更少的可用VMHeap).
在确定哈希表的大小之前，我想知道它将消耗多少内存，以免浪费内存.
我知道哈希表的大小与图片可能消耗的内存相比可能很小，但是我想确保自己没有消耗比必要更多的内存.
在问这个问题之前，我在其他地方之间搜索
(是的，我知道其中两个地方相互矛盾，这就是问题的一部分).
在32位JVM或Davlik VM上，对象或数组引用占用一个32位字(4个字节). null 占用与引用相同的空间.(必须这样做，因为必须在引用类型的插槽中插入null；即实例字段，局部变量等)
另一方面，一个对象至少占用2个32位字(8个字节)，而一个数组至少占用3个32位字(12个字节).实际大小取决于对象的字段数量和种类，以及数组元素的数量和种类.
对于64位JVM，除非已将JVM配置为使用压缩指针，否则引用的大小为64位:
-XX:+ UseCompressedOops启用压缩指针(以32位偏移而不是64位指针表示的对象引用)的使用，以优化Java堆大小小于32gb的64位性能.
我想这是您的问题所在.
在确定哈希表的大小之前，我想知道它将消耗多少内存，以免浪费内存.
如果您分配具有较大初始大小的 HashMap 或 Hashtable ，则大部分空间将被哈希数组占用.这是一个引用数组，因此大小为 3 + initialSize 32位字.除非您对尺寸的估计完全错误，否则这不太可能是重要的.
但是，我认为您可能不必要地担心性能.如果将对象存储在默认分配的 HashMap 或 Hashtable 中，则该类将在其变大时自动调整其大小.因此，只要您的对象具有不错的哈希函数(不要太慢，不要将所有内容哈希为少量值)，哈希表就不会直接影响CPU性能.
What is the size that a reference in Android's Java VM consumes?
More info:
By that I mean, if we have
String str = "Watever";
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.
Also, if we have
String str = null;
how much memory does it consume? Is it the same as the other str?
Now, if we have:
Object obj[] = new object[2];
how much does obj consume and how much does obj[1] and obj[2] consume?
The reason for the question is the following: (in case someone can recommend something).
I'm working on an app that manages many pictures downloaded from internet. I started storing those pictures on a "bank" (that consists of 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.
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.
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.
I have read that "To balance time and space efficiency, the hash table should be around half full", but that makes collisions occur 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).
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 necessary.
Before asking this question i searched, between other places, in
How big is an object reference in Java and precisely what information does it contain?
(Yes, I know two of the places contradict each other, that's part of the reason for the question).
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.)
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.
For a 64 bit JVM, the size of a reference is 64 bits, unless you have configured the JVM to use compressed pointers:
-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.
Before determining the size of the hash table, I wanted to know how much memory would it consume in order not to exagerate.
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.
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屋！
