包装器java_说说java基本类型和包装器类

工作中，我们经常会使用到 int／long这些基本数值类型和相应的包装器Integer／Long类型，平时使用时只有注意它们一个是基本类型一个是对象，需要做类型上的区分，并没有深入的思考过包装器类的原理。最近一次偶然的javap，看到的数据有点可怕，就深入的了解了下它们的实现原理，在这里记录下。

实验环境：

mac ox 10.12.6

jdk8 64-Bit

涉及工具：

jdb，hsdb

1.使用javap分析包装器类算术运算过程

图1

很简单的一段代码，一个Integer对象做加法操作，通过javap分析它的执行过程：

1.调用valueOf方法生成一个Integer对象，将对象赋值给变量a；

2.做加法操作时，先调intValue方法转换为int值，再做加法操作；

3.加法执行完后，调用valueOf方法生成一个Integer对象，将对象赋值给变量a；

可以看到，对Integer进行算术运算时，它会先转换为int基本类型，运算完成后会生成一个新的Integer对象。所以如果涉及到大量运算的，最好用基本类型。当然，jvm对包装器类型有做优化，对于每种类型，jvm会在堆里缓存一定值的对象。

2.包装器类在内存中的存储

例子代码：

图2

使用jdb调试(开启指针压缩)，并使用HSDB查看对象内存：

图3

通过OQL搜索Long类型对象，可以看到堆里有很多Long对象。jvm在使用到包装器类型时，会在堆里缓存一定值的包装器类型对象。对于Long类型，它缓存值为 -127 - 127 的Long对象。当程序中要生成的Long对象值在里面时，它会直接返回这个缓存的Long对象。要生成的Long对象值不在这个范围内时，jvm会在堆里生成一个新的Long对象。

一个Long对象在堆里占24byte内存，8byte MarkWord + 4byte klassPoint + 4byte padding + 8byte数值。

有点奇怪，4byte的padding 为什么是在第 13-16 字节，而不是在最后 21-24 字节位置呢？

还一点，jvm里缓存的Long对象都在main线程TLAB区，多线程场景下是如何处理的？

3.基本类型内存对齐方式

基本对齐顺序：

double, long

float, int

short, char

boolean, byte

测试代码：

图4

图5

关闭指针压缩：

图6

在关闭指针压缩时，对象头占16byte，后面的字段数据，按照基本对齐顺序进行对齐存储。

开启指针压缩：

图7

在开启指针压缩时，对象头占12byte，后面的数据字段，先取了一个4byte的int，补足klassPoint剩余的4byte，其他字段再按基本对齐顺序进行对齐存储。

==》对齐原则：

1.对齐顺序

double, long

float, int

short, char

boolean, byte

2.紧凑排列

以8byte为一个字，每个字段存储时不能跨字。按1的顺序，依次补足字宽，不能补足的byte用空白填充；

如此上面Long对象的padding就清楚了。

4:多线程场景下包装器类的缓存

测试代码：

图8

main线程：命中缓存的Long对象

图9

new线程：命中缓存的Long对象

图10

可以看到，Long对象的缓存在公用Eden区，两个线程中的Long对象都指向缓存值为32的Long对象。

补充一个场景：多线程下，只有单线程使用到某种包装器类型时，包装器类型缓存对象的存储

图11

图12

可以看到，缓存的Long对象 和 Integer对象 均在公用Eden区。

HSDB相关操作参考：http://rednaxelafx.iteye.com/blog/1847971