blocks|key|1708944|text|Java从来不是特定于实现或平台的(至少就primitive+type+sizes而言)。无论你在什么平台上，它们的基本类型总是保持不变。这不同于(也被认为是)C和C%2B%2B的改进，后者的一些原语类型是特定于平台的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1708945|由于底层操作系统一次寻址四个字节(在64位系统中为八个字节)的速度更快，JVM可能会分配更多的字节来存储一个原始字节，但是您仍然只能在其中存储从-128到127的值。|1708946|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html^0|L|K|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

Java is never implementation or platform specific (at least as far as <a href="http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html" rel="noreferrer">primitive type sizes</a> are concerned). They primitive types are always guaranteed to stay the same no matter what platform you're on. This differs from (and was considered an improvement on) C and C++, where some of the primitive types were platform specific.

Since it's faster for the underlying operating system to address four (or eight, in a 64-bit system) bytes at a time, the JVM may allocate more bytes to store a primitive byte, but you can still only store values from -128 to 127 in it.

blocks|key|1493900|text|这取决于JVM如何应用填充等。字节数组(在任何正常的系统中)将被打包为每个元素1个字节，但具有4个字节字段的类可以被紧密打包，也可以填充到字边界上-这取决于实现。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1493901|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It depends on how the JVM applies padding etc. An array of bytes will (in any sane system) be packed into 1-byte-per-element, but a class with four byte fields could either be tightly packed or padded onto word boundaries - it's implementation dependent.

blocks|key|1493915|text|您可以随时使用long，并将数据打包到您自己中，以提高效率。这样你就可以一直使用所有的4个字节。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1493916|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You could always use longs and pack the data in yourself to increase efficiency. Then you can always gaurentee you'll be using all 4 bytes.

blocks|key|1709054|text|一个很有启发性的练习是在一些代码上运行javap，这些代码对字节和整数做了一些简单的事情。您将看到字节码期望int参数在字节上操作，字节码被插入到从一个字节到另一个字节的co-erce中。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1709055|请注意，字节数组不会存储为4字节值的数组，因此1024长度的字节数组将使用1k的内存(忽略任何开销)。|1709056|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javap.html^0|J|5|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

A revealing exercise is to run <a href="http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javap.html" rel="noreferrer">javap</a> on some code that does simple things with bytes and ints. You'll see bytecodes that expect int parameters operating on bytes, and bytecodes being inserted to co-erce from one to another.

Note though that arrays of bytes are not stored as arrays of 4-byte values, so a 1024-length byte array will use 1k of memory (Ignoring any overheads).

blocks|key|1493990|text|是的，Java中的byte变量实际上是内存中的4个字节。然而，这并不适用于数组。20字节的字节数组的存储实际上在存储器中仅为20字节。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1493991|这是因为Java字节码语言只知道两种整数类型:int和long。因此，它必须在内部将所有数字处理为任一类型，并且这些类型在内存中是4字节和8字节。|1493992|然而，Java知道每个整数格式的数组。因此，短数组的存储实际上是每个条目两个字节，字节数组的每个条目一个字节。|1493993|我之所以一直说“的存储”，是因为在Java中，数组也是一个对象，每个对象本身都需要多个字节的存储空间，而不管实例变量或数组所需的存储空间是多少。|1493994|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Yes, a byte variable in Java is in fact 4 bytes in memory. However this doesn't hold true for arrays. The storage of a byte array of 20 bytes is in fact only 20 bytes in memory. 

That is because the Java Bytecode Language only knows two integer number types: ints and longs. So it must handle all numbers internally as either type and these types are 4 and 8 bytes in memory.

However, Java knows arrays with every integer number format. So the storage of short arrays is in fact two bytes per entry and one byte per entry for byte arrays.

The reason why I keep saying "the storage of" is that an array is also an object in Java and every object requires multiple bytes of storage on its own, regardless of the storage that instance variables or the array storage in case of arrays require.

blocks|key|1494051|text|好的，有很多讨论，但没有太多代码:)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1494052|这里有一个快速基准。当涉及到这类事情时，它有通常的警告-测试内存由于JITting等原因而有些奇怪，但对于适当的大数字，它无论如何都是有用的。它有两种类型，每种都有80个成员--+LotsOfBytes有80个字节，LotsOfInts有80个It。我们构建了大量的内存，确保它们没有被GC，并检查内存使用情况：|1494053|class+LotsOfBytes
{
++++byte+a0,+a1,+a2,+a3,+a4,+a5,+a6,+a7,+a8,+a9,+aa,+ab,+ac,+ad,+ae,+af;
++++byte+b0,+b1,+b2,+b3,+b4,+b5,+b6,+b7,+b8,+b9,+ba,+bb,+bc,+bd,+be,+bf;
++++byte+c0,+c1,+c2,+c3,+c4,+c5,+c6,+c7,+c8,+c9,+ca,+cb,+cc,+cd,+ce,+cf;
++++byte+d0,+d1,+d2,+d3,+d4,+d5,+d6,+d7,+d8,+d9,+da,+db,+dc,+dd,+de,+df;
++++byte+e0,+e1,+e2,+e3,+e4,+e5,+e6,+e7,+e8,+e9,+ea,+eb,+ec,+ed,+ee,+ef;
}

class+LotsOfInts
{
++++int+a0,+a1,+a2,+a3,+a4,+a5,+a6,+a7,+a8,+a9,+aa,+ab,+ac,+ad,+ae,+af;
++++int+b0,+b1,+b2,+b3,+b4,+b5,+b6,+b7,+b8,+b9,+ba,+bb,+bc,+bd,+be,+bf;
++++int+c0,+c1,+c2,+c3,+c4,+c5,+c6,+c7,+c8,+c9,+ca,+cb,+cc,+cd,+ce,+cf;
++++int+d0,+d1,+d2,+d3,+d4,+d5,+d6,+d7,+d8,+d9,+da,+db,+dc,+dd,+de,+df;
++++int+e0,+e1,+e2,+e3,+e4,+e5,+e6,+e7,+e8,+e9,+ea,+eb,+ec,+ed,+ee,+ef;
}


public+class+Test
{
++++private+static+final+int+SIZE+=+1000000;

++++public+static+void+main(String[]+args)+throws+Exception
++++{++++++++
++++++++LotsOfBytes[]+first+=+new+LotsOfBytes[SIZE];
++++++++LotsOfInts[]+second+=+new+LotsOfInts[SIZE];

++++++++System.gc();
++++++++long+startMem+=+getMemory();

++++++++for+(int+i=0;+i+<+SIZE;+i%2B%2B)
++++++++{
++++++++++++first[i]+=+new+LotsOfBytes();
++++++++}

++++++++System.gc();
++++++++long+endMem+=+getMemory();

++++++++System.out.println+("Size+for+LotsOfBytes:+"+%2B+(endMem-startMem));
++++++++System.out.println+("Average+size:+"+%2B+((endMem-startMem)+/+((double)SIZE)));

++++++++System.gc();
++++++++startMem+=+getMemory();
++++++++for+(int+i=0;+i+<+SIZE;+i%2B%2B)
++++++++{
++++++++++++second[i]+=+new+LotsOfInts();
++++++++}
++++++++System.gc();
++++++++endMem+=+getMemory();

++++++++System.out.println+("Size+for+LotsOfInts:+"+%2B+(endMem-startMem));
++++++++System.out.println+("Average+size:+"+%2B+((endMem-startMem)+/+((double)SIZE)));

++++++++//+Make+sure+nothing+gets+collected
++++++++long+total+=+0;
++++++++for+(int+i=0;+i+<+SIZE;+i%2B%2B)
++++++++{
++++++++++++total+%2B=+first[i].a0+%2B+second[i].a0;
++++++++}
++++++++System.out.println(total);
++++}

++++private+static+long+getMemory()
++++{
++++++++Runtime+runtime+=+Runtime.getRuntime();
++++++++return+runtime.totalMemory()+-+runtime.freeMemory();
++++}
}|code-block|syntax|javascript|1494054|我盒子上的输出：|1494055|Size+for+LotsOfBytes:+88811688
Average+size:+88.811688
Size+for+LotsOfInts:+327076360
Average+size:+327.07636
0|1494056|因此，显然有一些开销-8字节，尽管不知何故只有7字节的LotsOfInts+(？就像我说的，这里有一些奇怪的地方)--但关键是字节字段似乎被打包到了LotsOfBytes中，因此(在去掉开销后)它只需要LotsOfInts的四分之一的内存。|1494057|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

Okay, there's been a lot of discussion and not a lot of code :)

Here's a quick benchmark. It's got the normal caveats when it comes to this kind of thing - testing memory has oddities due to JITting etc, but with suitably large numbers it's useful anyway. It has two types, each with 80 members - LotsOfBytes has 80 bytes, LotsOfInts has 80 ints. We build lots of them, make sure they're not GC'd, and check memory usage:

<pre><code>class LotsOfBytes
{
 byte a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, aa, ab, ac, ad, ae, af;
 byte b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, ba, bb, bc, bd, be, bf;
 byte c0, c1, c2, c3, c4, c5, c6, c7, c8, c9, ca, cb, cc, cd, ce, cf;
 byte d0, d1, d2, d3, d4, d5, d6, d7, d8, d9, da, db, dc, dd, de, df;
 byte e0, e1, e2, e3, e4, e5, e6, e7, e8, e9, ea, eb, ec, ed, ee, ef;
}

class LotsOfInts
{
 int a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, aa, ab, ac, ad, ae, af;
 int b0, b1, b2, b3, b4, b5, b6, b7, b8, b9, ba, bb, bc, bd, be, bf;
 int c0, c1, c2, c3, c4, c5, c6, c7, c8, c9, ca, cb, cc, cd, ce, cf;
 int d0, d1, d2, d3, d4, d5, d6, d7, d8, d9, da, db, dc, dd, de, df;
 int e0, e1, e2, e3, e4, e5, e6, e7, e8, e9, ea, eb, ec, ed, ee, ef;
}


public class Test
{
 private static final int SIZE = 1000000;

 public static void main(String[] args) throws Exception
 { 
 LotsOfBytes[] first = new LotsOfBytes[SIZE];
 LotsOfInts[] second = new LotsOfInts[SIZE];

 System.gc();
 long startMem = getMemory();

 for (int i=0; i &lt; SIZE; i++)
 {
 first[i] = new LotsOfBytes();
 }

 System.gc();
 long endMem = getMemory();

 System.out.println ("Size for LotsOfBytes: " + (endMem-startMem));
 System.out.println ("Average size: " + ((endMem-startMem) / ((double)SIZE)));

 System.gc();
 startMem = getMemory();
 for (int i=0; i &lt; SIZE; i++)
 {
 second[i] = new LotsOfInts();
 }
 System.gc();
 endMem = getMemory();

 System.out.println ("Size for LotsOfInts: " + (endMem-startMem));
 System.out.println ("Average size: " + ((endMem-startMem) / ((double)SIZE)));

 // Make sure nothing gets collected
 long total = 0;
 for (int i=0; i &lt; SIZE; i++)
 {
 total += first[i].a0 + second[i].a0;
 }
 System.out.println(total);
 }

 private static long getMemory()
 {
 Runtime runtime = Runtime.getRuntime();
 return runtime.totalMemory() - runtime.freeMemory();
 }
}
</code></pre>

Output on my box:

<pre><code>Size for LotsOfBytes: 88811688
Average size: 88.811688
Size for LotsOfInts: 327076360
Average size: 327.07636
0
</code></pre>

So obviously there's some overhead - 8 bytes by the looks of it, although somehow only 7 for LotsOfInts (? like I said, there are oddities here) - but the point is that the byte fields appear to be packed in for LotsOfBytes such that it takes (after overhead removal) only a quarter as much memory as LotsOfInts.

blocks|key|1494094|text|看起来答案很可能取决于您的JVM版本，也可能取决于您运行的CPU架构。Intel+CPU行高效地执行字节操作(由于其8位CPU历史记录)。一些RISC芯片需要字(4字节)对齐来进行许多操作。对于堆栈上的变量、类中的字段和数组中的变量，内存分配可以是不同的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1494095|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

It appears that the answer is likely to depend on your JVM version and probably also the CPU architecture you're running on. The Intel line of CPUs do byte manipulation efficiently (due to its 8-bit CPU history). Some RISC chips require word (4 byte) alignment for many operations. And memory allocation can be different for variables on the stack, fields in a class, and in an array.

blocks|key|1709280|text|我使用http://code.google.com/p/memory-measurer/做了一个测试，注意我使用的是64位Oracle/Sun+Java6，没有对引用等进行任何压缩。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1709281|每个对象占用一些空间，另外JVM需要知道该对象的地址，而"+address“本身就是8个字节。|1709282|对于原语，看起来像是将原语转换为64位以获得更好的性能(当然！)：|1709283|byte:+16+bytes,
+int:+16+bytes,
long:+24+bytes.|code-block|syntax|javascript|1709284|使用数组：|1709285|byte[1]:+24+bytes
+int[1]:+24+bytes
long[1]:+24+bytes

byte[2]:+24+bytes
+int[2]:+24+bytes
long[2]:+32+bytes

byte[4]:+24+bytes
+int[4]:+32+bytes
long[4]:+48+bytes

byte[8]:+24+bytes+=>+8+bytes,+"start"+address,+"end"+address+=>+8+%2B+8+%2B+8+bytes
+int[8]:+48+bytes+=>+8+integers+(4+bytes+each),+"start"+address,+"end"+address+=>+8*4+%2B+8+%2B+8+bytes
long[8]:+80+bytes+=>+8+longs+(8+bytes+each),+"start"+address,+"end"+address+=>+8x8+%2B+8+%2B+8+bytes|1709286|现在你猜怎么了..。|1709287|++++byte[8]:+24+bytes
+byte[1][8]:+48+bytes
+++byte[64]:+80+bytes
+byte[8][8]:+240+bytes|1709288|P.S.+Oracle+Java6，最新和最好的，64位，1.6.0_37，MacOS+X|1709289|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/p/memory-measurer/^0|3|15|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@$A|15|B|16|1|17]]|C|$]]|$1|D|3|E|5|6|7|18|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|19|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|1A|8|@]|9|@]|C|$K|L]]|$1|M|3|N|5|6|7|1B|8|@]|9|@]|C|$]]|$1|O|3|P|5|J|7|1C|8|@]|9|@]|C|$K|L]]|$1|Q|3|R|5|6|7|1D|8|@]|9|@]|C|$]]|$1|S|3|T|5|J|7|1E|8|@]|9|@]|C|$K|L]]|$1|U|3|V|5|6|7|1F|8|@]|9|@]|C|$]]|$1|W|3|-4|5|6|7|1G|8|@]|9|@]|C|$]]]|X|$Y|$5|Z|10|11|C|$12|13]]]]

I did a test using <a href="http://code.google.com/p/memory-measurer/" rel="noreferrer">http://code.google.com/p/memory-measurer/</a>
Note that I am using 64-bit Oracle/Sun Java 6, without any compression of references etc.

Each object occupies some space, plus JVM needs to know address of that object, and "address" itself is 8 bytes.

With primitives, looks like primitives are casted to 64-bit for better performance (of course!):

<pre><code>byte: 16 bytes,
 int: 16 bytes,
long: 24 bytes.
</code></pre>

With Arrays:

<pre><code>byte[1]: 24 bytes
 int[1]: 24 bytes
long[1]: 24 bytes

byte[2]: 24 bytes
 int[2]: 24 bytes
long[2]: 32 bytes

byte[4]: 24 bytes
 int[4]: 32 bytes
long[4]: 48 bytes

byte[8]: 24 bytes =&gt; 8 bytes, "start" address, "end" address =&gt; 8 + 8 + 8 bytes
 int[8]: 48 bytes =&gt; 8 integers (4 bytes each), "start" address, "end" address =&gt; 8*4 + 8 + 8 bytes
long[8]: 80 bytes =&gt; 8 longs (8 bytes each), "start" address, "end" address =&gt; 8x8 + 8 + 8 bytes
</code></pre>

And now guess what...

<pre><code> byte[8]: 24 bytes
 byte[1][8]: 48 bytes
 byte[64]: 80 bytes
 byte[8][8]: 240 bytes
</code></pre>

P.S. Oracle Java 6, latest and greatest, 64-bit, 1.6.0_37, MacOS X

I have heard mixed opinions over the amount of memory that a byte takes up in a java program.

I am aware you can store no more than +127 in a java byte, and the <a href="http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html" rel="noreferrer">documentation</a> says that a byte is only 8 bits but <a href="http://www.jguru.com/faq/view.jsp?EID=13647" rel="noreferrer">here</a> I am told that it actually takes up the same amount of memory as an int, and therefore is just a Type that helps in code comprehension and not efficiency. 

Can anyone clear this up, and would this be an implementation specific issue?

Size of a byte in memory - Java

MacOS

Java

关于一个字节在java程序中占用的内存量，我听到过各种不同的意见。我知道你可以在一个java字节中存储不超过+127的内容，说一个字节只有8位，但是我被告知它实际上占用了与int相同的内存量，因此只是一种有助于代码理解而不是效率的类型。有人可以澄清这一点吗?这会是一个特定于实现的问题吗？

问内存中字节的大小- Java
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问内存中字节的大小- JavaEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问内存中字节的大小- Java
EN