通俗地讲，线程执行的任务在计算机语言中，被当做是一条条的指令。线程需要一个计数器来帮助它标记执行了什么指令，以及选取下一条指令。
每条线程被CPU执行之后，需要切换下一条，为了使线程能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各线程之间的计数器互不影响，独立存储。
这一块内存区域为“线程私有”的内存。
Java 虚拟机栈
Java 虚拟机栈（Java Virtual Machine Stacks）也是线程私有的，生命周期与线程相同，因为它描述的是Java方法执行的内存模型。
Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧（Stack Frame，方法运行时的基础数据结构）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。
每个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
在Java虚拟机的规范中，对这个区域规定了两种异常情况：
StackOverflowError
如果线程请求的栈深度大于虚拟机所允许的深度，将抛出 StackOverflowError异常
OutOfMemoryError
如果虚拟机栈在扩展的时无法申请到足够的内存，就会抛出 OutOfMemoryError异常
本地方法栈
本地方法栈（Native Mrthod Stack）与虚拟机栈发挥的作用非常相似，他们之间的区别：
虚拟机栈为虚拟机执行java方法（也就是字节码）服务
本地方法栈则为虚拟机使用到的Native方法服务
与虚拟机一样，本地方法栈区域也会抛出 StackOverflowError 和 OutOfMemeoryError 异常。
Java 堆
Java 堆（Java Heap）是Java虚拟机锁管理的内存中最大的一块，Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例。
Java 堆可以处于物理上不连续的内存空间中，只要逻辑上是连续即可。在实现时，既可以实现成固定大小的，也可以是可扩展的（通过-Xmx 和 -Xms 控制）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出 OutOfMemoryError 异常。
此外，Java 堆是垃圾收集器器管理的主要区域。
方法区
方法区（Method Area）与 Java 堆 一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编辑器编译后的代码等数据。
方法区是堆的一个逻辑部分，但是它与java堆又是不同的，所以它有了一个别名——非堆（Non-Heap）。
方法区中的内存一般不会被 GC 回收，GC 也难回收，所以被取名为“永久代”，意思是永久存在。这区域的内存回收目标主要是针对常量池的回收和对类的卸载。但是“永久代”中的数据并非真的永久存在，只是回收比较麻烦。
根据 Java 虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出 OutOfMemoryError 异常。
小结
线程共享区域：
Java 堆
方法区
线程私有区域：
程序计数器
Java 虚拟机栈
本地方法栈
可能抛出 OutOfMemoryError 异常：
Java 虚拟机栈
本地方法栈
Java 堆
方法区
可能抛出 StackOverflowError 异常：
Java 堆
对我来说，Java 堆 是 JVM 的常用内存区域，因为 java堆 负责存放对象实例，而我使用 java 编程，无时无刻都在和对象打交道。
new
虚拟机遇到一条 new 指令时：
检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过
类加载检查通过
虚拟机java堆为新主对象分配内存，对象所需内存的大小在类加载完成后便可完全确定
虚拟机将分配到的内存空间都初始化为零值（不包括对象头）。所以有时候某些字段不赋初始值就能直接使用
设置对象头，对象头中存储了该对象是拿了类的实例等信息
执行 init 方法（否则所有字段还为零值），把对象按照程序员的意愿进行初始化
对象的内存布局
对象在内存中存储的布局可以分为3块区域
对象头（Header）
实例数据（Instance Data）
对其填充（Padding）
对象头
对象头包含两部分信息：
存储对象自身的运行时数据
哈希码、GC分代年龄、锁定态标识、线程持有锁等
类型指针
即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例
创建完对象，到了使用对象的时候，通常声明一个同类型的引用指向该类型的对象，由这个引用来操作对象的字段、方法等。
1Objectobj =newObject();
我们的Java程序需要通过栈上的 reference 数据来操作堆上的具体对象，目前主流的访问方式有使用句柄和直接指针两种，我更青睐于后者，或者说基本只使用后者，那么，我简要介绍一下如何通过直接指针访问对象。
采用直接指针访问，那么Java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，而 reference 中存储的直接就是对象地址，如图篇首。
使用这种方式的最大好处就是速度更快。就虚拟机 Sun HotSpot 而言，它是使用了直接指针访问方式记性对象访问。
Java 堆溢出
Java 堆是创建对象的区域，当GC来不及清除这些对象，并且对象数量达到最大堆的容量限制后就会产生内存溢出异常。
Java 堆可以自动扩展，如果将 -Xms（堆最小值）和 -Xmx（堆最大值）设置为一样可以避免堆自动扩展。
Java 堆内存的 OOM 异常是实际应用中常见的内存溢出情况。当 Java 堆出现 OOM 异常时，会提示错误信息：
1java.lang.OutOfMemoryError: Java heap sapce
值得注意的是，此时异常还分为两种：
内存泄露（Memroy Leak）
对象本应该被 GC 回收，而未被回收。内存从 GC 中泄露出来。
内存溢出（Memory Overflow）
对象都还必须存活（JVM会判断），这些对象占的内存超出了Java堆的最大容量。此时最直接的方法就是调大物理内存。
两者的唯一区别就是，GC没有清除的对象是否是必要的存在的。
虚拟机栈
由于在HotSpot虚拟机中并不区分虚拟机栈和本地方法栈，所以，-Xoss参数（本地方法栈大小）没有是实际作用。栈容量只由 -Xss 参数设定。
在虚拟机栈中，存在两种异常：
SatckOverflowError
线程请求的站深度大于虚拟机栈所允许的最大深度
OutOfMemoryError
虚拟机在扩展时无法申请到足够的内存空间（同java堆）
当在单线程环境中，只会出现 StackOverflowError 异常。切换至多线程后，会出现 OutOfMemoryError 异常。
看起来，可以通过增大内存空间来缓解或者解决虚拟机栈的 OOM，但是，通过 Java 运行时的数据区域分析得知：
1
物理机总内存 = 程序计数器消耗内存 + Xmx（最大 Java堆容量）+ MaxPermSize（最大方法区容量）+ Xss（虚拟机栈容量）+ Xoss（本地栈容量）
由于程序计数器消耗内存很小，忽略不计。并且将本地栈容量归为虚拟机栈容量管理的话，那么：
1
Xss（虚拟机栈容量）= 物理机总内存 - Xmx（最大 Java堆容量）- MaxPermSize（最大方法区容量）
虚拟机栈是线程的“私有内存”，目的是线程分配运行时需要的内存容量，所以有：
1
Xss（虚拟机栈容量）= 线程数 * 线程栈容量
最后得到：
1
线程数 * 线程栈容量 = 物理机总内存 - Xmx（最大 Java堆容量）- MaxPermSize（最大方法区容量）
在实际情况中，我们希望得到更高的并发量，也就是增大线程数量，此时，有三种方法：
增大物理机总内存
减小java堆内存、方法区容量
减小线程栈容量
作为开发人员，能做的，也就是后两者。第一条不说申请流程复杂，就算是增加了，那也可能是个无底洞。
概述
如篇首图所示，Class 文件被 JVM 加载至 JVM内存，在内存中验证、解析、初始化之后，形成可以被 JVM 直接使用的 Java类型。这就是类加载的简要过程。类的加载过程是在 Java程序运行期间完成，虽然会损耗一部分性能，但是提高了Java语言的灵活性，体现在动态扩展方面，例如：多态（晚期绑定）。
类加载的时机
类的生命周期
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：
加载
验证
准备
解析
初始化
使用
卸载
其中，验证、准备和解析三个部分称为连接。解析和初始化的相对顺序不是固定的，当解析在初始化之后执行时，称为动态绑定或者晚期绑定，例如：晚期绑定的多态特性。
初始化
在 JVM 规范中没有强制约束加载的时机，不过对于初始化，JVM有严格的规范，根据《深刻理解JVM虚拟机》所述，有且只有5种情况必须对类进行初始化，但是我只能理解其中3种：
遇到 new、getstatic、putstatic或invokestatic 这4条指令时
如果类没有进行过初始化，则需要先触发其初始化。getstatic指读取一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）；invokestatic指调用一个类的静态方法。
使用 java.lang.reflect 包的方法对类进行反射调用的时候
如果类没有进行过初始化，则需要先触发其初始化。
派生类
初始化一个派生类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类
上述三种情况，被称为对一个类进行 主动引用。除此之外的引用类被称为 被动引用，不会触发初始化。
通过子类引用父类的静态字段，父类初始化，但子类不会初始化
package com.zhoupq.jvm.calssload;publicclassSuperClass{static{System.out.println("SuperClass init!");}publicstaticinti =1;}publicclassSubClassextendsSuperClass{static{System.out.println("SubClass init!");}}publicclassTestApp{publicstaticvoidmain(String[] args){System.out.println(SubClass.i);}}/*
SuperClass init!
1
*/
类加载的过程
加载
在家在阶段，虚拟机需要完成以下三件事情：
通过一个类的全限定名来获取定义此类的二进制字节流
可以从一个java文件、jsp文件获取class文件，即生成一个对应的class类。
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
在内存中生成一个代表这个类的java.lang.Class对象，作为这个方法区这个类的各种数据的访问入口
加载阶段与连接阶段的部分内容是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始。
验证
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件中的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
准备
准备阶段是正式为类变量（被static修饰的变量）分配内存并设置类变量初始值（0值）的阶段，这些变量所使用的内存都将在方法区中进行分配。
方法区中分配的是静态变量的内存，并为其设置0值，具体的值将在初始化阶段后再赋值。成员变量（实例变量）随对象一起在java堆中分配内存，具体的值也是在初始化阶段后再赋值。
但是如果静态变量被 final 修饰，那么该静态变量在准备阶段就会被赋实际的值。
解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。在 JVM（三）——对象的访问定位中有介绍什么是直接引用。
初始化
初始化阶段是类加载过程的最后一步，在此之前的阶段，基本都是由迅疾主导和控制，在此阶段，才真正开始执行类中定义的 Java 程序代码。
在准备阶段，类变量已经赋过一次初始值（0值），在此阶段，则根据程序员的主观计划去初始化类变量和其他资源。
有一种说法：
初始化阶段是执行类构造器 < clinit>()方法的过程
类构造器< clinit>() 方法 与 实例构造器< init>()方法（构造方法） 不同，它不需要显示地调用父类构造器，虚拟机会保证在子类的< clinit>() 方法执行前，父类的< clinit>()方法已经执行完毕。因此在虚拟机中，第一个被执行的< clinit>()方法的类肯定是 java.lang.Object。
< clinit>() 方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的。如果没有静态语句块，也没有对类变量的赋值操作，那么编译器可以不生成< clinit>()方法。
由于父类的< clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量复制操作。
接口中不能使用静态语句块，但是仍然有变量初始化的赋值操作，因为接口与类一样，都会生成< clinit>()方法。但接口与类不同的是，执行接口的< clinit>()方法不需要先执行父接口的< clinit>()方法。只有当父接口中定义的变量使用时，父接口才会初始化。实现类与接口不是继承关系，所以不存在< clinit>()方法执行的先后顺序。
在多线程中，虚拟机会保证一个类的< clinit>()方法在被正确地加锁、同步，只会有一个线程去执行这个类的< clinit>()方法，其他线程都需要阻塞等待，知道活动线程执行< clinit>()方法完毕。并且< clinit>()方法只会被执行一次，当其他线程被唤醒后，是不会再进入< clinit>()方法。
概述
GC 是 JVM 自带的功能，它能够自动回收对象，清理内存，这是 Java 语言的一大优势，但是GC绝不仅伴随着Java，相反，GC历史比Java更悠久。关于GC，我认为有四个问题需要解决：
为什么了解 GC？
哪些内存需要回收？
什么时候回收？
如何回收？
为什么了解 GC
GC 已经比较成熟，绝大部分情况下都“自动化”运行。之所以还需要了解GC，是因为当需要排查各种内存溢出、内存泄露问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节。
哪些内存需要回收
判定哪些内存需要回收，不是靠 JVM 去猜，也不是随机，而是 JVM 靠一些列算法得到结果，当然，算法也是人写的，虽然不能做到百分之百地符合所有开发者的要求，但这已经是最好的了。下面介绍一种判定内存回收的算法——可达性分析算法，这是我能在理论上理解的算法。
可达性分析算法
这个算法的基本思路是通过一些列的称为 “GC Roots” 的对象作为起点，从这些起点开始向下搜索，搜索走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的，也就是待回收的。例如，上图中的 Object 5、Object 6 虽然两者相互关联，但是它们任何一个都和 GC Roots 不可达，所以 Object 5 和 Object 6 将会被判定为可回收的对象。
GC Roots
至于什么是 GC Roots 对象，解释如下：
虚拟机栈（栈帧中的本地变量表）引用的对象
方法区中类静态变量引用的对象
方法区中常量引用的对象
本地方法栈 JNI 引用的变量
什么时候回收
当通过“可达性分析”等算法标记好需要回收的对象后，等待它们的不是即可问斩，而是宣告“缓刑”。最后的回收条件是此对象是否有必要执行 finalize() 方法。
finalize() 方法
当对象没有覆盖 finalize() 方法，或者 finalize() 方法已经被虚拟机调用过，虚拟机都将视作“没有必要执行”。如果这个对象呗判定为有必要执行 finalize() 方法，那么这个对象将会放置在一个叫作 F-Queue 的队列中，这个队列在后期会被某个JVM自动创建的线程执行，如果一个对象在finalize()方法中执行缓慢或者发生了死循环，将可能导致 F-Queue 队列中其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃，幸运的是任何一个对象的 finalize() 方法只会被系统调用一次。
在 《深入理解 JVM 虚拟机》中，作者建议尽量避免使用 finalize() 方法，它不是c++ 中的析构函数，更像是java为适应c++程序员而作出的让步。我觉得是finalize()方法是一根鸡肋，一根如果运用不当将会引发灾难的鸡肋，如同 goto 语句。它的运行代价极高，不确定性大，无法保证各个对象的调用顺序。它的功能经常会被误以为类似 try-finally，然而 finalize() 能做的工作， try-finally 都能做，而且做得更好、更及时。
如何回收
标记-清除法
“标记-清除”（Mark-Sweep）法是最基础的手机算法。算法分为两个阶段——“标记”和“清除”：首先标记出所有需要被回收的对象，在标记完成后统一回收所有标记了的对象，图如篇首。
它有两个不足之处：
效率不高
标记和清除两个过程的效率都不高
产生大量不连续碎片
虽然对象被回收，但是剩下的内存很有可能不连续，在这种情况下，当需要为系统分配一个较大对象时，会因为无法找到足够的连续的内存而不得不提前触发另一次垃圾收集动作。这样，又会造成效率问题
针对上述两个缺点，后面两种算法对此进行了改进。
复制法
“复制”（Copying）是为了解决“标记-清除”的效率不高问题而被发明。它将内存按容量划分为等量的两块。每次只使用其中的一块。当使用的这一块内存用完了，就将还存活的对象复制到另一块（被称作“保留区”）上面，然后再把已使用的内存空间一次清理掉。每次都对整个半区进行回收，再也不用担心内存碎片化问题，图如下所示。
The requested content cannot be loaded.
Please try again later.
但是“复制”法也有缺点，每次都将内存缩小为一半，会导致内存利用率不高。并且在对象存活率高时进行复制操作，效率就会变低（因为存活的对象要复制到“保留区”）。当遇上极端情况，对象存活率百分百（以原内存一半为单位），那就需要另外的百分之五十的空间作为分配担保。
标记-整理法
“标记-整理”（Mark-Compact）法适合对象存活率高的情况使用。“标记”过程同“标记-清除”法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，图如下所示：
The requested content cannot be loaded.
Please try again later.
分代收集法
据知，当前商业虚拟机都采用“分代收集”（Generational Collection）法，根据对象的存活周期的不同将内存划分为几块。一般是把 Java 堆分成新生代和老年代，这样可以根据更年代的特点采用最适当的收集算法。
新生代
在新生代中，每次垃圾收集时都会发现有大量对象死去，只有少量存活，那就选用复制算法，只需要复制少量的对象就可以完成收集，成本小。
老年代
老年代中的对象存活率高、没有额外的空间对它进行分配担保，就必须使用“标记-清除”、和“标记-整理”法来进行回收
