java 指针大小 - 对象引用有多大？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/5839434/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Pointer Size - How big is an object reference?
提问by J-Rou
The question finishes after the first horizontal line, the rest is extra information.
问题在第一条水平线后结束，其余是额外信息。
The question is simple, what is the size that a reference in Androids Java VM consume?
问题很简单，Androids Java VM 中的引用消耗的大小是多少？
By that I mean:
我的意思是：
If we have
如果我们有
String str = "Watever";
I need what strtakes, not "Watever". -- "Watever"is what's saved in the location to which the pointer (or the reference) that stris holding, is pointing to.
我需要什么str，而不是"Watever"。-- "Watever"是保存在str所持有的指针（或引用）所指向的位置中的内容。
Also,
还，
If we have
如果我们有
String str = null;
how much memory does it consume?? Is it the same than the other str??
消耗多少内存？？和另一个一样str吗？？
now, if we have:
现在，如果我们有：
Object obj[] = new object[2];
how much does objconsume and how much does obj[1]and obj[2]consume?
需要多少obj消费，多少钱obj[1]和obj[2]消费？
The reason for the queston is the following: (in case someone can recommend something).
问题的原因如下：（以防有人可以推荐一些东西）。
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.
在图库上显示这些图片时，我过去常常在列表中搜索图片（SLOW），然后，如果图片不存在，我过去常常显示临时下载图像，直到图片被下载。
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.
正如我之前解释过的，这个搜索发生在 UI 线程中（我不能改变它）。因此，如果碰撞开始减慢线程速度，就会成为一个问题。
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).
我读过“为了平衡时间和空间效率，哈希表应该大约是半满”，但这会使冲突发生一半的时间（对于 UI 线程不实用）。这让我想到拥有一个很长的哈希表（与保存的图片数量相比）并使用更多的 RAM（可用的 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 neccesary.
我知道与图片可能消耗的内存相比，哈希表的大小可能非常小，但我想确保我没有消耗超过必要的内存。
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, 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.
如果您因任何原因不明白某事，或者想了解更多信息，请发表评论，我会尽快回复。
Than You Verry much.
比你非常。
回答by Stephen C
A object or array reference occupies one 32 bit word (4 bytes) on a 32 bit JVM or Davlik VM. A nulltakes 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.)
对象或数组引用在 32 位 JVM 或 Davlik VM 上占用一个 32 位字（4 个字节）。Anull占用与引用相同的空间。（它必须，因为 null 必须适合引用类型的槽；即实例字段、局部变量等）
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.
另一方面，一个对象最少占用2个32位字（8个字节），一个数组最少占用3个32位字（12个字节）。实际大小取决于对象字段的数量和种类，以及数组元素的数量和种类。
For a 64 bit JVM, the size of a reference is 64 bits, unless you have configured the JVM to use compressed pointers:
对于 64 位 JVM，引用的大小是 64 位，除非您已将 JVM 配置为使用压缩指针：
-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.
-XX:+UseCompressedOops 启用压缩指针（对象引用表示为 32 位偏移而不是 64 位指针）以优化 64 位性能，Java 堆大小小于 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 HashMapor Hashtablewith 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 + initialSize32 bit words. It is unlikely that this will be significant ... unless you get your size estimate drastically wrong.
如果你分配一个HashMap或Hashtable一个大的初始大小，大部分空间将被散列数组占用。这是一个引用数组，因此大小为3 + initialSize32 位字。这不太可能是重要的......除非你的尺寸估计完全错误。
However, I think you are probably worrying unnecessarily about performance. If you are storing objects in a default allocated HashMapor 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.
但是，我认为您可能不必要地担心性能。如果您将对象存储在默认分配的HashMap或 中Hashtable，则该类将随着哈希表变大而自动调整其大小。因此，如果您的对象具有不错的散列函数（不太慢，不会将所有内容散列到少量值），散列表不应直接成为 CPU 性能问题。
回答by Haphazard
References are nearly free. Even more so when compared to images.
参考资料几乎是免费的。与图像相比更是如此。
Having a few collisions in a Map isn't a real problem. Collisions can be resolved far quicker than a linear search through a list of items. That said, a Binary Search through a sorted list of items would be a good way to keep memory usage down (compared to a Map).
在 Map 中发生一些碰撞并不是真正的问题。与通过项目列表进行线性搜索相比，解决冲突的速度要快得多。也就是说，通过排序的项目列表进行二分搜索将是降低内存使用量的好方法（与 Map 相比）。
I can vouch for the effectiveness of a having smaller initial sizes for Maps - I recently wrote a program that makes a Trie structure of 170000 English words. When I set the initial size to 26, I would run out of memory by the time I got to words starting with R. Cutting it down to 5, I was able to create the maps without memory issues and can search the tree (with many collisions) in effectively no time.
我可以保证使用较小的 Maps 初始大小的有效性 - 我最近编写了一个程序，该程序可以生成 170000 个英文单词的 Trie 结构。当我将初始大小设置为 26 时，当我遇到以 R 开头的单词时，内存就会耗尽。将其减少到 5，我能够创建没有内存问题的地图，并且可以搜索树（有很多碰撞）实际上很快。
[Edit] If a reference is 32 bit (4 bytes) and your average image is around 2 megabytes, you could fit 500000 references into the same space that a single image would take. You don't have to worry about the references.
[编辑] 如果引用是 32 位（4 字节）并且您的平均图像大约为 2 兆字节，那么您可以将 500000 个引用放入单个图像所占用的相同空间。您不必担心引用。
