一个类，在加载到内存的时候，JVM会把它存放在运行时数据区的方法区中，然后在堆区中创建一个java.lang.Class对象，用来封装这个类在方法区内的数据结构。
那现在我问，我们用new来创建这个类的对象时，这个创建出来的对象的引用是指向堆区中代表这个类的java.lang.Class类的对象还是指向方法区中这个类的地址？
那现在我问，我们用new来创建这个类的对象时，这个创建出来的对象的引用是指向堆区中代表这个类的java.lang.Class类的对象还是指向方法区中这个类的地址？
Two-Word Object HeadersThe Java HotSpot VM uses a two machine-word object header, as opposed to three words in the Classic VM. Since the average Java object size is small, this has a significant impact on space consumption -- saving approximately eight percent in heap size for typical applications. The first header word contains information such as the identity hash code and GC status information. The second is a reference to the object's class. Only arrays have a third header field, for the array size.
再来用感性的认识来看一下，如果引用指向的是方法区中这个类的地址，那么类的对象要打算什么时候用。方法区中这个类的地址只能被别人指向却不可以指向别人，也就是说你的引用指向了它就等于死在那里了，指不回来了。
内部实现实在没有研究过，不清楚，所以不能做出理性的分析
对象头的后面就是对象的实际数据了。
对象的identity hash code 可以通过System.identityHashCode(obj)得到。
然后创建对象，再把【Class对象】“注入”到对象中去，这就是为什么java.lang.Object中有个方法：getClass()就是用来获得各种各样的对象对应的【Class对象】的，至于对象引用当然是指向对象。
我是说楼上的楼上
“对象的identity hash code 可以通过System.identityHashCode(obj)得到。”那Object.hashCode()方法返回的也是这个么？
public static int identityHashCode(Object x)返回给定对象的哈希码，该代码与默认的方法 hashCode() 返回的代码一样，无论给定对象的类是否重写 hashCode()。null 引用的哈希码为 0。
下面是对象头格式的一些说明,来自Oop.hpp文件.
// The Oop describes the header of an object.
//
// Note that the is not a real oop but just a word.
// It is placed in the oop hierarchy for historical reasons.
//
// Bit-format of an object header (most significant first):
//
// 32 bits: unused:0 hash:25 age:4 biased_lock:1 lock:2
// 64 bits: unused:24 hash:31 cms:2 age:4 biased_lock:1 lock:2
// unused:20 size:35 cms:2 age:4 biased_lock:1 lock:2 (if cms
// free chunk)
//
// - hash contains the identity hash value: largest value is
// 31 bits, see os::random(). Also, 64-bit vm's require
// a hash value no bigger than 32 bits because they will not
// properly generate a mask larger than that: see library_call.cpp
// and c1_CodePatterns_sparc.cpp.
//
// - the biased lock pattern is used to bias a lock toward a given
// thread. When this pattern is set in the low three bits, the lock
// is either biased toward a given thread or "anonymously" biased,
// indicating that it is possible for it to be biased. When the
// lock is biased toward a given thread, locking and unlocking can
// be performed by that thread without using atomic operations.
// When a lock's bias is revoked, it reverts back to the normal
// locking scheme described below.
//
// Note that we are overloading the meaning of the "unlocked" state
// of the header. Because we steal a bit from the age we can
// guarantee that the bias pattern will never be seen for a truly
// unlocked object.
//
// Note also that the biased state contains the age bits normally
// contained in the object header. Large increases in scavenge
// times were seen when these bits were absent and an arbitrary age
// assigned to all biased objects, because they tended to consume a
// significant fraction of the eden semispaces and were not
// promoted promptly, causing an increase in the amount of copying
// performed. The runtime system aligns all JavaThread* pointers to
// a very large value (currently 128 bytes) to make room for the
// age bits when biased locking is enabled.
//
// [JavaThread* | epoch | age | 1 | 01] lock is biased toward given thread
// [0 | epoch | age | 1 | 01] lock is anonymously biased
//
// - the two lock bits are used to describe three states: locked/unlocked and monitor.
//
// [ptr | 00] locked ptr points to real header on stack
// [header | 0 | 01] unlocked regular object header
// [ptr | 10] monitor inflated lock (header is wapped out)
// [ptr | 11] ed used by Sweep to an object
// not valid at any other time
//
// We assume that stack/thread pointers have the lowest two bits cleared.