java的对象构成
对于JVM来说,构造JAVA对象时,是以oops-klass二分模型来构建的,其中oops表示对象的相关信息。
基本结构如下:
class oopDesc {
friend class VMStructs;
private:
volatile markOop _mark;
union _metadata {
wideKlassOop _klass;
narrowOop _compressed_klass;
} _metadata;
对于数组来说,其结构如下:
class arrayOopDesc : public oopDesc
从源码上没找到length字段,我们只能看注释:
// The layout of array Oops is:
//
// markOop
// klassOop // 32 bits if compressed but declared 64 in LP64.
// length // shares klass memory or allocated after declared fields.
还有一段:
// The _length field is not declared in C++. It is allocated after the
// declared nonstatic fields in arrayOopDesc if not compressed, otherwise
// it occupies the second half of the _klass field in oopDesc.
这里的mark字段,用来表示一些JVM内部需要的相关信息
从OpenJDK源码中可以看到:
看下注释:
// 32 bits:
// --------
// hash:25 ------------>| age:4 biased_lock:1 lock:2 (normal object)
// 64 bits:
// --------
// unused:25 hash:31 -->| unused:1 age:4 biased_lock:1 lock:2 (normal object)
// unused:25 hash:31 -->| cms_free:1 age:4 biased_lock:1 lock:2 (COOPs && normal object)
我们运行的时候,默认是使用UseCompressedOops的,所以对应COOPs
我的机器是64bits的,测试下 normal object的mark:
源码如下:
public class HashCodeMemViewDemo {
public static void main(String[] args) throws IOException {
DataEntity data = new DataEntity();
data.setDataId(0x01020304);
System. out.println(data .hashCode());
System. in.read();
}
}
class DataEntity {
private int dataId;
public int getDataId() {
return dataId ;
}
public void setDataId(int dataId) {
this.dataId = dataId;
}
}
运行后输出的值为:1359740460
(对应的二进制值为:1010001000010111111111000101100)
查看对象DataEntity的内存布局:
hsdb> mem 0xf5980a58 2
0x00000000f5980a58: 0x000000510bfe2c01
0x00000000f5980a60: 0x01020304dbc99c30
0x000000510bfe2c01 就是DataEntity对象的mark字段值,对应的二进制值为(已拆分):
0000000000000000000000000(unused:25)
1010001000010111111111000101100(hash:31)
0(cms_free:1)
0000(age:4)
0(biased_lock:1)
01(lock:2)
这里的(hash:31),根据 程序中输出的值 对比, 就是DataEntity对应的hash code值了。
另外,这里的hash是 System.identityHashCode
其中一份PPT里提到:
● First word of every object is the mark word
● Used for synchronization and garbage collection
● Also holds identity hash code if computed
因为mark字段中会存储对象的age,做个测试:
同样的代码,增加GC。
GC前:
identity hash code: 1359740460
DataEntity addr: 0xf5980b48
hsdb> mem 0xf5980b48 2
0x00000000f5980b48: 0x000000510bfe2c01
0x00000000f5980b50: 0x01020304dbc99cc0
mark字段解析后:
0000000000000000000000000(unused:25)
1010001000010111111111000101100(hash:31)
0(cms_free:1)
0000(age:4)
0(biased_lock:1)
01(lock:2)
经过1次GC:
DataEntity addr: 0xe0c00838
地址已经变了
hsdb> mem 0xe0c00838 2
0x00000000e0c00838: 0x000000510bfe2c09
0x00000000e0c00840: 0x01020304dbc99930
0000000000000000000000000
1010001000010111111111000101100
0
0001(age:4)
0
01
因为mark字段还用来表示锁相关信息,目前不介绍锁的细节,只用一个例子来说明一点问题。
代码如下:
public class LockMemViewDemo {
public static void main(String[] args) throws IOException {
DataEntity data = new DataEntity();
data.setDataId(0x01020304);
synchronized (data ) {
System. out.println(System.identityHashCode( data));
System. in.read();
}
}
}
运行后输出的值为:353537765
查看对象DataEntity的内存布局:
hsdb> mem 0xf5980b78 2
0x00000000f5980b78: 0x00007f69cc004c1a
0x00000000f5980b80: 0x01020304dbc99ca0
其中mark字段的值为:0x00007f69cc004c1a ,对应的二进制值为(已拆分):
00000000000000000111111101101001110011000000000001001100000110
10
按照源码中的注释:
// [ptr | 10] monitor inflated lock (header is wapped out)
因此第一段就是指向monitor的指针,是0x1FDA73001306,具体是什么,指向哪个对象,无法验证。
有一段供参考:
In the uncontended case, a Java mutex consists of just 2 bits in the flags word. The JVM only associates a heavy-weight OS lock object with a Java mutex when the mutex is contended, and then releases the OS lock when the mutex has been exited by all threads.
参考:
http://arturmkrtchyan.com/java-object-header
http://stackoverflow.com/questions/4068562/how-heavy-are-java-monitors
http://www.programmershare.com/2077632/