大将生来胆气豪 腰横秋水雁翎刀
风吹鼍鼓山河动 电闪旌旗日月高
天上麒麟原有种 穴中蝼蚁岂能逃
太平待诏归来日 朕与将军解战袍
开篇聊闲天。
在使用Java的过程中，一直困扰我的一个问题是，一个对象到底占用多大内存?(Java并没有sizeof操作符) 但这个问题，结果却并没有那么简单。
Java没有sizeof也不需要sizeof操作符，所有数据类型的大小都在Java语言规范中定义，和机器平台不相关。但从Java虚拟机的角度，一个Java中定义的对象，在虚拟机中占用多大内存？这个问题好像只能通过分析虚拟机的实现来找到答案。这就牵扯到另一个问题，我们到底需不需要了解我们所使用工具的实现？
探索知识的任何阶段都是存有疑惑的，就像中学和大学都有数学，但学习深入的程度不同，分别有不同方面的疑惑。我们只是基于一些公知的认识，使其作为本阶段学习的起点，并以此展开上层的研究。
少部分人会有一个无止尽思考的奇怪思维现象。举例来说，我们都知道地球围绕太阳做周期性公转，又知道电子围绕原子核做周期性公转运动，这和地球绕太阳公转的行为如出一辙，不禁会让人想，太阳是不是相当于原子核，地球相当于一个电子，我们都生活在一个电子上。而我们的是身体里有那么多原子和电子，我们的身体是否又定义了另一个新的宇宙。无尽的遐想，无尽的疑惑，虽然有些荒诞，但并非完全不合理。但是如果无休止地问下去，虽然会对底层的科学更加清晰，但是对上层的知识结构的构建非常不利，从而我们需要一个公设，例如认为原子是不可再分的，没有更小的对象了，一切理论研究以此为基础展开。例如乘法是基于加法的，在计算3*4的结果时，必须不去质疑为什么1+1=2这件事，并认为它是真理。在学习操作系统时，不去思考硬件内部究竟是如何工作的，只假设硬件是一个给定输入有给定输出的系统。
这里的Java虚拟机，作为一个运行字节码的平台，显然不能当做一个公设来看待。虚拟机包含三个概念，语言规范，具体实现和运行实例。语言规范描述了虚拟机需要实现什么，而并没有规定需要如何去实现。复杂的虚拟机(Hotspot/JRockit/J9)和简单的虚拟机(Kaffe/Jamvm/cacaovm)在实现方面有很大的差异。对一个有不确定实现的工具，冲一杯咖啡，打开音乐，从源代码的角度分析工具的实现，对上层知识的构建非常有利(事实也证明，Java使用者对虚拟机的了解程度，远远不如c/c++使用者对机器平台的了解程度深)。
以Hotspot为例，在虚拟机的内部，通过instanceOopDesc来表示一个对象(OOP-Klass二分模型在另一个篇中写），每个对象包含Mark Word和元数据指针作为对象头，接下来依次是实例数据和padding:
对象在内存中分布
Mark Word: 定义在oopDesc中的_mark成员，储存对象运行时的记录信息，如HashCode/GC分代年龄状态锁标志/线程持有的锁/偏向线程ID/偏向时间戳等。_mark成员的数据类型为markOop，占用内存大小与虚拟机word长度一致。在32位虚拟机上为32位，在64位虚拟机上为64位(可以压缩)。
元数据指针: 定义在oopDesc中的_metadata成员，指向描述类型的Klass对象指针。根据是否压缩定义为一个union。虚拟机在运行时频繁使用这个指针定位到位于方法区的信息。
对象头中的元信息
虚拟机运行时，每创建一个对象，在虚拟机内部就要创建相应有对象头的对象，因此对象头的布局对对象内存空间利用率(Instance Data/Header+instanceData+padding)十分重要。但是，在对象生命周期内，虚拟机要记录很多信息，如hashCode/GC分代年龄/锁记录指针/线程ID 等，因此header必须要仔细设计。
设计1: 虚拟机配置选项-XX:UserCompressedOops。其作用是在64位机器上，对_metadata成员使用32位指针存储。在64位系统上，指针类型为64位，这样一来，从32位系统迁移到64位系统时，内存利用率就会有所下降。union联合体中wideKlassOop是指向klassOopDesc指针，而narrowOop是32位无符号整形。
设计2: _mark成员模仿网络协议报文头部，把mark word划分为多个比特区间，并在不同对象状态下赋予每个bit不同含义。
Hotspot有三种对象成员排列顺序: [oops,longs/doubles/ints/shorts/chars/bytes]，[longs/doubles, ints, shorts/chars, bytes, oops] 和 [Fields allocation: oops fields in super and sub classes are together]。默认为第二种顺序。源码如下:
根据allocation_style值的不同应用不同的内存排列模型
排列规则如下，每个对象内存地址要是8的倍数，每个成员的内存地址要是自己大小的倍数，例如整形要是4字节的倍数，long要是8字节的倍数。
假设，在Java代码中，定义如下类:
定义一个直接继承Object的类
如果虚拟机不改变成员变量排列顺序，32位机器，在内存中顺序如下:
按Java代码中定义顺序排列
这样有14字节因为padding被浪费了。如果重新调整排序规则:
虚拟机重排序过后的排列
这样只有6字节因为padding被浪费。在每个成员都要内存对齐的情况下，先分配大内存的成员会节约内存。
按照这个规则来计算Object对象的直接子类Boolean，header+value+padding=8+1+7=16，竟然需要16字节。
如果类不是直接继承Object对象，即父类中如果有成员变量的话。举例如下:
定义有成员函数的父类
一个B的实例在内存中看起来长这样:
应用默认规则，先排列父类成员再排列子类成员
其他情况的排序不再赘述，可根据代码自行排列。
了解Boolean类内存利用率很低以后，再说一下HashMap。对于应用层的程序来说，这简直是神器，只要创建了之后就可以不断的丢东西进去，添加删除都是O(1)操作，又快又好。不过引用第一位图灵奖获得者Alan Perlis的名言：“Lisp programmers know the value of everything but the cost of nothing.”，目的是想提醒我们做事情不要忘记背后的代价。对于HashMap来说，代价主要是内存的开销，试想一下，Java没有HashMap<boolean,boolean>只有HashMap<Boolean,Boolean>。
网友评论