转载请注明出处：http://mingnianshimanian.iteye.com/admin/blogs/2321634
本文主要和大家一起分享学习关于Java内存方面的知识，主要学习java虚拟机，内存分配，堆栈，垃圾回收以及内存优化等知识点，都是自己手工整理的，供大家学习参考，如果有错误的地方还望指出，共同进步！
1.JVM
JVM全称Java Virginia Machine，是一种用于计算设备的规范，是想象出来的一个机器，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。Java虚拟机包括一套字节码指令集、一组寄存器、一个栈、一个垃圾回收堆和一个存储方法域。 JVM屏蔽了与具体操作系统平台相关的信息，使Java程序只需生成在Java虚拟机上运行的目标代码（字节码）,就可以在多种平台上不加修改地运行。 JVM在执行字节码时，实际上最终还是把字节码解释成具体平台上的机器指令执行。
2.JRE/JDK/JVM
- JRE(JavaRuntimeEnvironment),java运行环境，平台。所有java开发的程序都需要在JRE下运行。一般安装JRE之后再运行java程序即可。
- JDK(Java Development Kit)是程序开发者用来来编译、调试java程序用的开发工具包。JDK的工具也是Java程序，也需要JRE才能运行。为了保持JDK的独立性和完整性，在 JDK的安装过程中，JRE也是 安装的一部分。所以，在JDK的安装目录下有一个名为jre的目录，用于存放JRE文件。
- JVM(JavaVirtualMachine，Java虚拟机)是JRE的一部分。它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。JVM有自己完善的硬件架构，如处理器、堆栈、寄存器等，还具有相应的指令系统。Java语言最重要的特点就是跨平台运行。使用JVM就是为了支持与操作系统无关，实现跨平台。
3.JVM原理，执行过程
- 加载.class文件
- 管理并分配内存
- 执行垃圾收集
- 创建JVM装载环境和配置。
- 装载JVM.dll。
- 初始化JVM.dll并挂界到JNIENV(JNI调用接口)实例。
- 调用JNIEnv实例装载并处理class类。
java代码编译到执行要经历一下3个重要机制：
- java源码编译机制
- 类加载机制
- 类执行机制
1.java源码编译机制
java源码编译机制主要由3个部分组成分别是：
- 源码分析：将源代码转变成标记（Token）集合，标记是编译过程的最小元素。如 int a = b + 2; ---> int、a、=、b、+、2。
- 填充到符号表：符号表是由一组符号地址和符号信息组成的表格（类似哈希表的K-V值对形式）、符号表所登记的信息在编译的不同阶段都要用到。如在语义分析中，符号 表用于语义检查（如检查一个名字的使用和原先的说明是否一致）和产生中间代码。在目标代码生成阶段，当对符号名地址分配时，符号表是其依据。（补充：如果用户代码没有提供任何构造函数，此阶段会添加无参访问性与当前类一致的默认构造方法）
- 注解处理：处理用户自定义的annotation，可以生成附加代码，节省共用代码的编写。
- 语法分析：包括变量使用前是否声明，变量与赋值之间的数据类型是否匹配，常量折叠，每条路径是否有返回值异常是否处理等。
- 最后生成的class文件由以下部分组成：
- 结构信息。包括class文件格式版本号及各部分的数量与大小的信息。
- 元数据。对应于Java源码中声明与常量的信息。包含类/继承的超类/实现的接口的声明信息、域与方法声明信息和常量池。
- 方法信息。对应Java源码中语句和表达式对应的信息。包含字节码、异常处理器表、求值栈与局部变量区大小、求值栈的类型记录、调试符号信息。
2.类加载机制
- 寻找jre目录，寻找jvm.dll，并初始化JVM。
- 产生一个Bootstrap Loader（启动类加载器）。 负责加载$JAVA_HOME中jre/lib/rt.jar里所有的class，由C++实现，不是ClassLoader子类。
- Bootstrap Loader自动加载Extended Loader（标准扩展类加载器），并将其父Loader设为Bootstrap Loader。 负责加载java平台中扩展功能的一些jar包，包括$JAVA_HOME中jre/lib/*.jar或-Djava.ext.dirs指定目录下的jar包。
- Bootstrap Loader自动加载AppClass Loader（系统类加载器），并将其父Loader设为Extended Loader。 负责记载classpath中指定的jar包及目录中class。
- 最后由AppClass Loader加载HelloWorld类。
- 命令行启动应用时候由JVM初始化加载。
- 通过Class.forName()方法动态加载。
- 通过ClassLoader.loadClass()方法动态加载。
从上面的结果可以看出，并没有获取到ExtClassLoader的父Loader，原因是Bootstrap Loader（启动类加载器）是用C语言实现的，找不到一个确定的返回父Loader的方式，于是就返回null。
3.类执行机制
JVM是基于栈的体系结构来执行class字节码的。线程创建后，都会产生程序计数器（PC）和栈（Stack），程序计数器存放下一条要执行的指令在方 法内的偏移量，栈中存放一个个栈帧，每个栈帧对应着每个方法的每次调用，而栈帧又是有局部变量区和操作数栈两部分组成，局部变量区用于存放方法中的局部变量和参数，操作数栈中用于存放方法执行过程中产生的中间结果。在下一章节中会详细阐述在类执行过程中java内存堆栈执的分配原理。
4.JVM生命周期
- 启动。启动一个Java程序时，一个JVM实例就产生了，任何一个拥有public static void main(String[] args)函数的class都可以作为JVM实例运行的起点。
- 运行。main()作为该程序初始线程的起点，任何其他线程均由该线程启动。JVM内部有两种线程：守护线程和非守护线程，main()属于非守护线程，守护线程通常由JVM自己使用，java程序也可以表明自己创建的线程是守护线程。
- 消亡。当程序中的所有非守护线程都终止时，JVM才退出；若安全管理器允许，程序也可以使用Runtime类或者System.exit()来退。（此种方式不推荐使用，影响JVM垃圾回收）
以下几种情况JVM会结束生命周期：
- 执行了System.exit()方法。
- 程序正常执行结束。
- 程序在执行过程中遇到了异常或错误而异常终止。
- 由于操作系统出现错误而导致Java虚拟机进程终止。
5.JVM体系结构
- 类装载器（ClassLoader）（用来装载.class文件）
- 执行引擎（执行字节码，或者执行本地方法）
- 运行时数据区（方法区、堆、java栈、PC寄存器、本地方法栈）
1.PC寄存器(Program Counter Register)
- pc程序计数器。
- optop操作数栈顶。
- frame当前执行环境。
- vars指向当前执行环境中第一个局部变量的指针。
- 所有寄存器均为32位。pc用于记录程序的执行。optop,frame和vars用于记录指向Java栈区的指针。
2.JVM栈(stack)
JVM栈是线程私有的，每个线程创建的同时都会创建JVM栈，JVM栈中存放的为当前线程中局部基本类型的变量（java中定义的八种基本类型：boolean、char、byte、short、int、long、float、double）、部分的返回结果以及Stack Frame，非基本类型的对象在JVM栈上仅存放一个指向堆上的地址。保存类的实例，即堆区对象的引用(指针)。也可以用来保存加载方法时的帧。在Java 虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError 异常；如果虚拟机栈可以动态扩展（当前大部分的Java 虚拟机都可动态扩展，只不过Java 虚拟机规范中也允许固定长度的虚拟机栈），当扩展时无法申请到足够的内存时会抛出OutOfMemoryError 异常。
3.本地方法栈(Native Method Stacks)
本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行Java 方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的Native 方法服务。虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机（譬如Sun HotSpot 虚拟机）直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError 和OutOfMemoryError异常。
4.堆(heap)
用来存放动态产生的数据，比如new出来的对象或者数组。注意创建出来的对象只包含属于各自的成员变量，并不包括成员方法。因为同一个类的对象拥有各自的成员变量，存储在各自的堆中，但是他们共享该类的方法，并不是每创建一个对象就把成员方法复制一次。可以认为Java中所有通过new创建的对象的内存都在此分配，Heap中的对象的内存需要等待GC进行回收。
- 堆是JVM中所有线程共享的，因此在其上进行对象内存的分配均需要进行加锁，这也导致了new对象的开销是比较大的。
- Sun Hotspot JVM为了提升对象内存分配的效率，对于所创建的线程都会分配一块独立的空间 TLAB（Thread Local Allocation Buffer），其大小由JVM根据运行的情况计算而得，在TLAB上分配对象时不需要加 锁，因此JVM在给线程的对象分配内存时会尽量的在TLAB上分配，在这种情况下JVM中分配对象内存的性能和C基本是一样高效的，但如果对象过大的话则 仍然是直接使用堆空间分配。
- TLAB仅作用于新生代的Eden Space，因此在编写Java程序时，通常多个小的对象比大的对象分配起来更加高效。
- 所有新创建的Object 都将会存储在新生代Yong Generation中。如果Young Generation的数据在一次或多次GC后存活下来，那么将被转移到OldGeneration。新的Object总是创建在Eden Space。
堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC 堆”（GarbageCollected Heap，幸好国内没翻译成“垃圾堆”）。根据Java 虚拟机规范的规定，Java 堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms 控制）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError 异常。
5.方法区(Method Area)
与堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆），目的应该是与Java 堆区分开来。对于习惯在HotSpot 虚拟机上开发和部署程序的开发者来说，很多人愿意把方法区称为“永久代”（Permanent Generation），本质上两者并不等价，仅仅是因为HotSpot 虚拟机的设计团队选择把GC 分代收集扩展至方法区，或者说使用永久代来实现方法区而已。对于其他虚拟机（如BEA JRockit、IBM J9 等）来说是不存在永久代的概念的。即使是HotSpot 虚拟机本身，根据官方发布的路线图信息，现在也有放弃永久代并“搬家”至Native Memory 来实现方法区的规划了。Java 虚拟机规范对这个区域的限制非常宽松，除了和Java 堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据进入了方法区就如永久代的名字一样“永久”存在了。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是有必要的。在Sun 公司的BUG 列表中，曾出现过的若干个严重的BUG 就是由于低版本的HotSpot 虚拟机对此区域未完全回收而导致内存泄漏。根据Java 虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError 异常。
6.运行时常量区(Runtime Constant Pool)
运行时常量池是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述等信息外，还有一项信息是常量池（Constant PoolTable），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。Java 虚拟机对Class 文件的每一部分（自然也包括常量池）的格式都有严格的规定，每一个字节用于存储哪种数据都必须符合规范上的要求，这样才会被虚拟机认可、装载和执行。但对于运行时常量池，Java 虚拟机规范没有做任何细节的要求，不同的提供商实现的虚拟机可以按照自己的需要来实现这个内存区域。不过，一般来说，除了保存Class 文件中描述的符号引用外，还会把翻译出来的直接引用也存储在运行时常量池中。运行时常量池相对于Class 文件常量池的另外一个重要特征是具备动态性，Java 语言并不要求常量一定只能在编译期产生，也就是并非预置入Class 文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的便是String 类的intern() 方法。既然运行时常量池是方法区的一部分，自然会受到方法区内存的限制，当常量池无法再申请到内存时会抛出OutOfMemoryError 异常。
6.内存溢出
1.堆内存溢出
Java 堆内存的OutOfMemoryError异常是实际应用中最常见的内存溢出异常情况。出现Java 堆内存溢出时，异常堆栈信息“java.lang.OutOfMemoryError”会跟着进一步提示“Java heapspace”。遇到这种情况就要检查虚拟机的堆参数（-Xmx 与-Xms），与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。
2.栈内存溢出
递归调用方法，这样随着栈深度的增加，JVM 维持着一条长长的方法调用轨迹，直到内存不够分配，产生栈溢出。
3.常量池溢出
