一个对象占多少字节？
关于对象的大小，对于C/C++来说，都是有sizeof函数可以直接获取的，但是Java似乎没有这样的方法。不过还好，在JDK1.5之后引入了Instrumentation类，这个类提供了计算对象内存占用量的方法。至于具体Instrumentation类怎么用就不说了，可以参看这篇文章如何精确地测量java对象的大小。
不过有一点不同的是，这篇文章使用命令行传入JVM参数来指定代理，这里我通过Eclipse设置JVM参数：
后面的是我打的agent.jar的具体路径。剩下的就不说了，看一下测试代码：
1 public class JVMSizeofTest { 2 3 @Test 4 public void testSize() { 5 System.out.println("Object对象的大小：" + JVMSizeof.sizeOf(new Object()) + "字节"); 6 System.out.println("字符a的大小：" + JVMSizeof.sizeOf('a') + "字节"); 7 System.out.println("整型1的大小：" + JVMSizeof.sizeOf(new Integer(1)) + "字节"); 8 System.out.println("字符串aaaaa的大小：" + JVMSizeof.sizeOf(new String("aaaaa")) + "字节"); 9 System.out.println("char型数组（长度为1）的大小：" + JVMSizeof.sizeOf(new char[1]) + "字节"); 10 } 11 12 }
运行结果为：
Object对象的大小：16字节
字符a的大小：16字节
整型1的大小：16字节
字符串aaaaa的大小：24字节
char型数组（长度为1）的大小：24字节
接着，代码不变，加入一条虚拟机参数"-XX:-UseCompressedOops"，再运行一遍测试类，运行结果为：
Object对象的大小：16字节
字符a的大小：24字节
整型1的大小：24字节
字符串aaaaa的大小：32字节
char型数组（长度为1）的大小：32字节
后文来详细解释一下原因。
Java对象大小计算方法
JVM对于普通对象和数组对象的大小计算方式有所不同，我画了一张图说明：
解释一下其中每个部分：
为了保证效率，Java编译期在编译Java对象的时候，通过字段类型对Java对象的字段会进行排序，具体顺序如下表所示：
了解这个是很有用的，我们可以通过在字段时间通过填充长整型变量的方式把热点变量隔离在不同的缓存行中，减少伪同步，在多核CPU中极大地提升效率，这个以后有机会写文章专门讲解。
最后再说说元数据指针的大小。元数据指针是一个引用类型，因此正常来说64位机元数据指针应当为8字节，32位机元数据指针应当为4字节，但是HotSpot中有一项优化是对元数据类型指针进行压缩存储，使用JVM参数：
HotSpot默认是前者，即开启元数据指针压缩，当开启压缩的时候，64位机上的元数据指针将占据4个字节的大小。换句话说就是当开启压缩的时候，64位机上的引用将占据4个字节，否则是正常的8字节。
Java对象内存大小计算
有了上面的理论基础，我们就可以分析JVMSizeofTest类的执行结果及为什么加入了"-XX:-UseCompressedOops"这条参数后同一个对象的大小会有差异了。
首先是Object对象的大小：
接着是字符'a'的大小：
接着是整型1的大小：
接着是字符串"aaaaa"的大小，所有静态字段不需要管，只关注实例字段，String对象中实例字段有"char value[]"与"int hash"，由此可知：
最后是长度为1的char型数组的大小：
Mark Word
Mark Word前面已经看到过了，它是Java对象头中很重要的一部分。Mark Word存储的是对象自身的运行数据，如哈希码（HashCode）、GC分代年龄、锁状态标识、线程持有的锁、偏向线程ID、偏向时间戳等等。
不过由于对象需要存储的运行时数据很多，其实已经超出了32位、64位Bitmap结构所能记录的限度，但是对象头是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息。例如在32位的HotSpot虚拟机中对象未被锁定的状态下，Mark Word的32个Bits空间中的25Bits用于存储对象哈希码（HashCode），4Bits用于存储对象分代年龄，2Bits用于存储锁标识位，1Bit固定位0。在其他状态（轻量级锁定、重量级锁定、GC标记、可偏向）下对象的存储内容如下图所示：
这里要特别关注的是锁状态，后文将对锁状态及锁状态的变化进行研究。
锁的升级
如上图所示，锁的状态共有四种：无锁态、偏向锁、轻量级锁和重量级锁，其中偏向锁和轻量级锁是JDK1.6开始为了减少获得锁和释放锁带来的性能消耗而引入的。
四种锁的状态会随着竞争情况逐渐升级，锁可以升级但是不能降级，意味着偏向锁可以升级为轻量级锁但是轻量级锁不能降级为偏向锁，目的是为了提高获得锁和释放锁的效率。用一张图表示这种关系：
偏向锁
HotSpot作者经过以往的研究发现大多数情况下锁不仅不存在多线程竞争，而且总是由同一线程多次获得,为了让线程获得锁的代码更低因此引入了偏向锁。偏向锁的获取过程为：
有获取就有释放，偏向锁的释放点在于上述的第（4）步，只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程不会主动去释放偏向锁。偏向锁的释放过程为：
轻量级锁
轻量级锁的加锁过程为：
偏向锁、轻量级锁与重量级锁的对比
下面用一张表格来对比一下偏向锁、轻量级锁与重量级锁，网上看到的，我觉得写得非常好，为了加深记忆我自己又手打了一遍：
