在这里,我发现了一个问题,在不同版本的JVM中,相同类的实例大小是不一样的( in 1.6.0_21,24 in 1.6.0_31)。尽管如此,代码还是一样的。你以前遇到过类似的问题吗?或者你有什么建议?
JDK 1.6.0_21
# java -version
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)
# java obj.ObjectSize &
# jps | grep ObjectSize
27251 ObjectSize
# jmap -histo 27251 | grep US_ASCII
145: 1 40 sun.nio.cs.US_ASCIIJDK 1.6.0_31
# java -version
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
# java obj.ObjectSize &
# jps | grep ObjectSize
26645 ObjectSize
# jmap -histo 26645 | grep US_ASCII
161: 1 24 sun.nio.cs.US_ASCIIObjectSize.java
package obj;
import java.util.concurrent.TimeUnit;
import sun.nio.cs.US_ASCII;
public class ObjectSize {
public static void main(String[] args) {
US_ASCII as = new US_ASCII();
System.out.println(as);
try {
TimeUnit.MINUTES.sleep(5);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}发布于 2013-01-08 09:12:26
我认为您所遇到的只是源于编译后的编程语言是如何工作的一个事实,特别是当它们在VM中运行时。
虚拟机实现中的更改允许不同的行为,例如产生不同大小的Java字节代码--只要它们保持相同的Java。
记忆使用上的差异真的有那么大吗?如果增加内存大小实际上是一个问题,我敢说,你已经有一个记忆问题在第一。
如果您使用一个VM以50%的容量工作,并且现在正与另一个VM一起达到上限,那么我想您需要对代码进行一些更深层次的更改。或者用更多的硬件来解决问题。;)
发布于 2013-01-08 09:23:01
早期版本的Java6支持-XX:+UseCompressedOops,但默认情况下是关闭的。( Java 6的最初版本根本不支持这一点),这意味着64位JVM中的引用是64位。在较新的JVM中,如果堆小于32 GB,则使用32位引用。它可以这样做,因为遵从with是8字节对齐的,所以您可以使用32位引用来寻址2^32 *8字节。
注意: US_ASCII从字符集继承三个字段
private final String name; // tickles a bug in oldjavac
private final String[] aliases; // tickles a bug in oldjavac
private Set<String> aliasSet = null;这些引用是4字节更小的节省12字节,但是对象是8字节对齐,所以总保存是16字节。
使用压缩的oops减少了使用的内存量。
顺便说一句:您不会直接使用这个类,而是使用StandardCharset.US_ASCII
https://stackoverflow.com/questions/14210990
复制相似问题