工作中，我们经常会使用到 int／long这些基本数值类型和相应的包装器Integer／Long类型，平时使用时只有注意它们一个是基本类型一个是对象，需要做类型上的区分，并没有深入的思考过包装器类的原理。最近一次偶然的javap，看到的数据有点可怕，就深入的了解了下它们的实现原理，在这里记录下。
实验环境：
mac ox 10.12.6
jdk8 64-Bit
涉及工具：
jdb，hsdb
1.使用javap分析包装器类算术运算过程
很简单的一段代码，一个Integer对象做加法操作，通过javap分析它的执行过程：
1.调用valueOf方法生成一个Integer对象，将对象赋值给变量a；
2.做加法操作时，先调intValue方法转换为int值，再做加法操作；
3.加法执行完后，调用valueOf方法生成一个Integer对象，将对象赋值给变量a；
可以看到，对Integer进行算术运算时，它会先转换为int基本类型，运算完成后会生成一个新的Integer对象。所以如果涉及到大量运算的，最好用基本类型。当然，jvm对包装器类型有做优化，对于每种类型，jvm会在堆里缓存一定值的对象。
2.包装器类在内存中的存储
例子代码：
使用jdb调试（开启指针压缩），并使用HSDB查看对象内存：
通过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
测试代码：
关闭指针压缩：
在关闭指针压缩时，对象头占16byte，后面的字段数据，按照基本对齐顺序进行对齐存储。
开启指针压缩：
在开启指针压缩时，对象头占12byte，后面的数据字段，先取了一个4byte的int，补足klassPoint剩余的4byte，其他字段再按基本对齐顺序进行对齐存储。
==》对齐原则：
1.对齐顺序
double, long
float, int
short, char
boolean, byte
2.紧凑排列
以8byte为一个字，每个字段存储时不能跨字。按1的顺序，依次补足字宽，不能补足的byte用空白填充；
如此上面Long对象的padding就清楚了。
4:多线程场景下包装器类的缓存
测试代码：
main线程：命中缓存的Long对象
new线程：命中缓存的Long对象
可以看到，Long对象的缓存在公用Eden区，两个线程中的Long对象都指向缓存值为32的Long对象。
补充一个场景：多线程下，只有单线程使用到某种包装器类型时，包装器类型缓存对象的存储
可以看到，缓存的Long对象 和 Integer对象 均在公用Eden区。
HSDB相关操作参考：http://rednaxelafx.iteye.com/blog/1847971
