JVM之内存和对象创建过程

1.5.3多核并行

Lambda支持会极大改善目前Java语言不适合函数式编程的现状.函数式编程的一个重要优点就是天然适合并行运行.

 

2.2.1程序计数器（每条线程独立私有）

         程序计数器是一块较小的内存空间，它可以看做是当前线程所执行的字节码的行号指示器

字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支 循环 跳转 异常处理 线程恢复等基础功能都需要依赖这个计数器来完成

         jvm的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现

2.2.2 Java虚拟机栈（JVM stacks）

         stacks也是线程私有 描述的是java方法执行的内存模型，每个方法在执行的同时会创建一个栈帧（Stack Frame）用于存储局部变量表，操作数栈，动态链接，方法出口等信息。

每一个方法从调用到执行完成的过程，就对应栈帧从入栈到出栈的过程

         在概念模型中，两个栈帧作为虚拟机栈的元素，相互之间是完全独立的，但是大多数虚拟机的实现里都会作一些优化处理，令两个栈帧出现一部分重叠。让下栈帧的部分操作数栈与上面栈帧的部分局部变量表重叠在一起，这样在进行方法调用返回时就可以共用一部分数据，而无须进行额外的参数复制传递了，重叠过程如下图：

 

 

         局部变量表存放八种基本数据类型、对象引用（reference类型，不一定是本身 也可能是指向对象地址的指针或者句柄）、returnAddress（指向字节码指令的地址）

         （64位的long和double会占用两个局部变量空间（Slot）(字宽)，其他为1个）

         局部变量表的内存空间在编译期间完成分配（执行时不会改变空间大小）

         stackOverflowError:线程请求的栈深度大于虚拟机所允许的深度

         OutOfMemoryError:虚拟机栈动态拓展时无法申请到足够的内存   

2.2.3本地方法栈(为JVM使用到的Native方法服务)

和虚拟机栈类似 区别是本地方法栈执行Native方法服务

2.2.4 java堆（Heap）（唯一目的：存放对象实例）

         Java堆时JVM管理内存中最大的一块，java堆是被所有线程共享的一块内存区域，在JVM启动时创建

         Java堆是垃圾收集器管理的主要区域，因此很多时候也被称做"GC堆"

         内存回收的角度：现在收集器基本都采用分代收集算法

         heap可以处于物理上不连续的内存空间中，只要逻辑上连续即可

可以通过配置(-Xmx和-Xms)来拓展堆空间

2.2.5 方法区（描述为堆的一个逻辑部分，但是与堆是分开的 Non-Heap）(HotSpot专属 永久代 Perm Generation)

         JDK1.7的HotSpot,已经把原本放在永久代的字符串常量池移出.

         各个线程共享的内存区域，用于存储已被加载的类信息，常量，静态变量，即时编译器编译后的代码。

         和heap一样不需要连续的内存和可以选择固定代销或者可拓展外，还可以选择不实现垃圾收集

         方法区的内存回收目标 主要针对常量池的回收和对类型的卸载。类型卸载的条件非常苛刻

2.2.6 运行时常量池（Runtime Constant Pool）

         运行时常量池是方法区的一部分，用于存放编译期生成的各种字面量和符号引用（发生时间在类加载后进入方法区时）

         通常 直接引用也会存储在运行时常量池中

         动态性，java语言并不要求常量一定只有编译期才能产生，运行期间也可能将新的常量放入池中（如String类的intern（）方法）

         运行时常量池相遇Class文件常量池的另外一个重要特征是具备动态性(常量不是只有在编译期才会产生,如String.intern())

intern（）方法的目的是重用String对象，以节省内存消耗

 

jdk1.7之前 常量池放在PERM区（属于方法区）使用引号声明的字符串都是会直接在字符串常量池中生成的，而new出来的String对象是放在堆里

所以两者的内存地址肯定不一样，

 

2.2.7 直接内存

         jdk1.4后加入NIO（New Input/Output）类，引入了一种基于通道与缓冲区的I/O方式，它可以使用native函数库直接分配堆外内存，，

然后通过一个存储在java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。可以避免在Java堆和Native堆中来回复制数据

直接内存的分配不会受到Java堆大小的限制.避免大于物理内存的情况

2.3.1对象的创建

         虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载

解析和初始化过，如果没有，先执行相应的类加载过程，接下来为新生对象分配内存

         1.为对象分配空间的任务等同于把一块确定大小的内存从堆中划分出来。（两种方式由java堆是否规整决定《--由采用的垃圾收集器是否带有压缩功能决定）

         指针碰撞（堆中内存绝对规整）

         不规整，空闲和使用的内存相互交错，JVM必须维护一个列表，记录哪些内存块是可用的，分配时候找到一块足够大的分配给对象实例，这种分配方式被称为‘空闲列表’

new

         2.并发创建对象（非线程安全）

         方案1：对分配内存空间的动作进行同步处理--实际上JVM采用CAS配上失败重试的方式保证更新操作的原子性

         方案2：把内存分配的动作按照线程划分在不同的空间中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer,TLAB）

         哪个线程要分配内存，就在哪个线程的TLAB上分配，只有TLAB用完并分配心得TLAB时，才需要同步锁定。

         通过-XX:+/-UseTLAB

         内存分配完成后，需要将分配到的内存空间都初始化为零（不包括对象头：存放对象的各种信息），如果使用TLAB，这一工作过程也可以提前至TLAB分配时进行

         用以保证对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值

<init>

2.3.2对象的内存布局

         对象在内存中存储的布局可以分为三个区域：对象头（Header），实例数据（Instance Data） 和对齐填充（Padding）

Header：        

  1.存储对象自身的运行时数据（Mark Word）：hashCode，Gc age，线程持有的锁，偏向线程ID，偏向事件戳等

    2.类型指针（对象指向它的类元数据的指针，通过其确定是哪个类的实例）：

实例数据：

存储代码中所定义的各种类型的字段内容,HotSpot虚拟机默认的分配策略为longs/doubles,ints,shorts/chars,bytes/booleans,oops(ordinary Object Pointers)

           (相同宽度的字段被分在一起)，在这个前提下，父类中定义的变量会出现在子类之前。如果CompactFields参数值为true，那么子类之中较窄的变量也可能会插入父类变量的间隙中

Padding：不是必然存在的，仅仅是占位符 HotSpotVm的自动内存管理系统要求对象的起始地址是8字节的整数倍，就是对象的大小必须是8字节的整数倍，

         而header是8的整数倍，因此当对象实例没有对齐，就通过对齐填充来补全

2.3.3 对象的访问定位

         java程序需要通过栈上的reference数据来操作堆上的具体对象。由于reference类型在JVM规范中只规定了一个指向对象的引用,并未定义这个引用如何定位和访问具体位置，所以对象访问方式由具体虚拟机实现而定。主要有句柄和直接指针两种方式

         1.句柄访问：堆中划分一块内存来作为句柄池，reference中存储的就是对象的句柄地址，句柄中包含了对象实例数据和类型数据各自的具体地址信息

优势：在对象被移动（GC中移动对象很常见）时只会改变句柄的实例数据指针，reference本身不需要修改    

         2.直接指针：堆对象的布局中必须考虑如何放置访问类型数据的相关信息，reference中存储的直接是对象地址

优势：速度快，节省了一次指针定位的时间开销，对象的访问在java中非常频繁，因此可以减少执行成本（Sun HotSpot虚拟机主要使用）

 

2.4 OutOfMemoryError 异常                    （-Xms=-Xmx设置为一样 可以避免堆自动拓展）

JVM启动参数（Run环境 arguments）-verbose：gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8

-XX：+HeapDumpOnOutOfMemoryError：可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便事后进行分析

2.4.1 java堆溢出

         在对象数量到达最大堆得容量限制后就会产生内存溢出异常

         java.lang.OutOfMemoryError:Java heap space

         解决方法：一般的手段先通过内存映像分析工具（Eclipse Memory Analyzer）对Dump出来的堆转储快照进行分析，

         目的是确认内存中的对象是否是必要的（先分清楚是内存泄漏（Memory Leak）还是内存溢出（Memory Overflow））

         1.内存泄漏（堆内存无法释放造成系统内存的浪费）：查看泄漏对象到GC Roots的引用链。就能找到泄漏对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收他们的，就可以准备定位泄漏代码的位置

         2.如果不存在泄漏,即所有对象都必须存活，检查虚拟机的堆参数（-Xmx与-Xms）与物理内存对比是否需要上调，

         从代码上检查是否存在某些对象生命周期过长，持有状态时间过长的情况，尝试减少程序运行期的内存消耗

 

2.4.2 虚拟机栈和本地方法栈溢出

         HotSpot不分区虚拟机栈和本地方法栈，因此栈容量只由-Xss参数设定

         1.StackOverflowError：如果线程请求的栈深度大于虚拟机所允许的最大深度（主）（阅读错误堆栈）

         2.OutOfMemoryError：如果虚拟机在拓展栈时无法申请到足够的内存空间

操作系统分配给每个进程的内存是有限制的，虚拟机提供参数来控制Java堆和方法区的内存的最大值。

剩余的内存为=2GB(操作系统限制)-Xmx（堆最大容量）-MaxPermSize（最大方法区容量）

每个线程分配到的栈容量越大，可以建立的线程数量自然就越少，建立线程时就越容易把剩下的内存耗尽

如果是建立过多线程导致的内存溢出，在不能减少线程数或者更换64位虚拟机的情况下，只能通过减少最大堆和减少栈容量来换取更多的线程

 

2.4.3方法区和运行时常量池溢出 Perm（永久代）

         String.intern()是一个Native方法，它的作用是：

如果字符串常量池已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并且返回此String对象的引用

         JDK1.6 intern（）方法会把首次遇到的字符串实例复制到永久代中，返回的也是永久代中这个字符串实例的引用

         JDK1.7 intern（）方法不会再复制实例，只是在常量池中记录首次出现的实例引用

         方法区用于存放Class的相关信息：类名，访问修饰符，常量池，字段描述，方法描述。

         方法区溢出（大量JSP或者动态产生JSP文件的应用，基于OSGI的应用（即使是同一个类文件，被不同的加载器加载也会视为不同的类））也是一种常见的内存溢出异常，一个类要被GC回收掉，判断条件比较苛刻。在经常动态生成大量Class的应用中，需要注意类的回收

2.4.4 本机直接内存溢出

         DirectMemory容量可以通过-XX：MaxDirectMemorySize指定，默认与-Xmx一样