文章目录
操作系统的堆和栈
- 堆（操作系统）：一般由程序员分配释放，若程序员不释放，程序结束时可能由OS回收，分配方式类似于链表。
- 栈（操作系统）：由操作系统自动分配释放，存放函数的参数值，局部变量值等。操作方式与数据结构中的栈相类似。
（jdk1.7）上图表明：jvm虚拟机位于操作系统的堆中，并且，程序员写好的类加载到虚拟机执行的过程是：当一个classLoder启动的时候，classLoader的生存地点在jvm中的堆，然后它会去主机硬盘上将A.class装载到jvm的方法区，方法区中的这个字节文件会被虚拟机拿来new A字节码()，然后在堆内存生成了一个A字节码的对象，然后A字节码这个内存文件有两个引用一个指向A的class对象，一个指向加载自己的classLoader.
java虚拟机与main方法的关系：main函数就是一个java应用的入口，main函数被执行时，java虚拟机就启动了。启动了几个main函数就启动了几个java应用，同时也启动了几个java的虚拟机。
java的虚拟机种有两种线程，一种叫叫守护线程，一种叫非守护线程（也叫普通线程），main函数就是个非守护线程，虚拟机的gc就是一个守护线程。java的虚拟机中，只要有任何非守护线程还没有结束，java虚拟机的实例都不会退出，所以即使main函数这个非守护线程退出，但是由于在main函数中启动的匿名线程也是非守护线程，它还没有结束，所以jvm没办法退出
虚拟机的gc（垃圾回收机制）就是一个典型的守护线程。
JVM运行时数据区域
jdk1.7虚拟机运行时数据区，下图是jdk1.8运行时内存区域
JVM在新版本的改进更新：
（1）对比：
- JDK 1.7 及以往的 JDK 版本中，Java 类信息、常量池、静态变量都存储在Perm（永久代）里。类的元数据和静态变量在类加载的时候分配到 Perm，当类被卸载的时候垃圾收集器从 Perm 处理掉类的元数据和静态变量。当然常量池的东西也会在 Perm 垃圾收集的时候进行处理。
- JDK 1.8 的对 JVM 架构的改造将类元数据放到本地内存中，另外，将常量池和静态变量放到 Java 堆里。HotSopt VM将会为类的元数据明确分配和释放本地内存。在这种架构下，类元信息就突破了原来
-XX:MaxPermSize的限制，现在可以使用更多的本地内存。这样就从一定程度上解决了原来在运行时生成大量类的造成经常 Full GC 问题，如运行时使用反射、代理等。
（2）注意
- 如果服务器内存足够，升级到 JDK 1.8 修改 JVM 参数最简单的办法就是将
-XX:PermSize和
-XX:MaxPermSize参数替换为-XX:MetaspaceSize和-XX:MaxMetaspaceSize
（3）优势理解：
- permSize：原来的jar包及你自己项目的class存放的内存空间，这部分空间是固定的，启动参数里面-permSize确定，如果你的jar包很多，经常会遇到permSize溢出，且每个项目都会占用自己的permGen空间改成metaSpaces，各个项目会共享同样的class内存空间，比如两个项目都用了fast-json开源包，在mentaSpaces里面只存一份class，提高内存利用率，且更利于垃圾回收
（4）区别
- 元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制
（5）参数来指定元空间的大小
-XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。-XX:MaxMetaspaceSize，最大空间，默认是没有限制的。- 除了上面两个指定大小的选项以外，还有两个与 GC 相关的属性：
-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集
-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集
程序计数器
内存空间小，线程私有。字节码解释器工作是就是通过改变这个计数器的值来选取下一条需要执行指令的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖计数器完成。
如果线程正在执行一个 Java 方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是 Native 方法，这个计数器的值则为 (Undefined)。此内存区域是唯一一个在 Java 虚拟机规范中没有规定任何 OutOfMemoryError 情况的区域。
Java虚拟机栈
线程私有，生命周期和线程一致。描述的是 Java 方法执行的内存模型：每个方法在执行时都会创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行结束，就对应着一个栈帧从虚拟机栈中入栈到出栈的过程。
局部变量表：存放了编译期可知的各种基本类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference 类型)和 returnAddress 类型(指向了一条字节码指令的地址)。其中long和double会占用2个局部变量空间，其余的数据类型只占用一个。在运行期间不会改变局部变量表的大小。
StackOverflowError：线程请求的栈深度大于虚拟机所允许的深度。
OutOfMemoryError：如果虚拟机栈可以动态扩展，而扩展时无法申请到足够的内存。
本地方法栈
功能与Java虚拟机栈十分相同。区别在于，本地方法栈为虚拟机使用到的native方法服务。
也会有 StackOverflowError 和 OutOfMemoryError 异常。
java堆
堆是JVM内存占用最大，管理最复杂的一个区域。其唯一的目的就是存放对象实例：几乎所有的对象实例及数组都在对上进行分配。
- JDK 1.8 的对 JVM 架构的改造将类元数据放到本地内存中，另外，将常量池和静态变量放到 Java 堆里。HotSopt VM 将会为类的元数据明确分配和释放本地内存。在这种架构下，类元信息就突破了原来 -XX:MaxPermSize 的限制，现在可以使用更多的本地内存。这样就从一定程度上解决了原来在运行时生成大量类的造成经常 Full GC 问题，如运行时使用反射、代理等。
- java堆中可能分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer, TLAB)。
- Java堆可以位于物理上不连续的空间，但是逻辑上要连续。
- OutOfMemoryError：如果堆中没有内存完成实例分配，并且堆也无法再扩展时，抛出该异常。
堆有自己进一步的内存分块划分，按照GC分代收集角度的划分请参见上图。
堆空间内存分配（默认情况下）
- 老年代 ： 三分之二的堆空间
- 年轻代 ： 三分之一的堆空间
- eden区： 8/10 的年轻代空间
- survivor0 : 1/10 的年轻代空间
- survivor1 : 1/10 的年轻代空间
命令行上执行如下命令，查看所有默认的jvm参数
java -XX:+PrintFlagsFinal -version
相关参数
| 参数 | 作用 | 默认值 |
|---|---|---|
| -XX:SurvivorRatio | 新生代Eden/Survivor空间的比例 | 8 |
| -XX:NewRatio | Old区 和 Yong区 的内存比例 | 2 |
元数据区
元数据区取代了1.7版本及以前的永久代。元数据区和永久代本质上都是方法区的实现。方法区存放虚拟机加载的类信息，静态变量，常量等数据。
HostSpot 虚拟机对象
对象的创建
遇到 new 指令时，首先检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已经被加载、解析和初始化过。如果没有，执行相应的类加载。
类加载检查通过之后，为新对象分配内存(内存大小在类加载完成后便可确认)。在堆的空闲内存中划分一块区域( ‘指针碰撞-内存规整’ 或 ‘空闲列表-内存交错’ 的分配方式)。选择哪种分配方式由Java堆是否规整决定，而Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。详情参考深入理解Java虚拟机。
前面讲的每个线程在堆中都会有私有的分配缓冲区(TLAB)，这样可以很大程度避免在并发情况下频繁创建对象造成的线程不安全。
内存空间分配完成后会初始化为 0(不包括对象头)，这一步操作保证了对象实例字段在java代码中可以不赋初值就可以直接使用。
接下来就是填充对象头，把对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的 GC 分代年龄等信息存入对象头。
执行 new 指令后执行 init 方法后才算一份真正可用的对象创建完成。
对象的内存布局
在 HotSpot 虚拟机中，分为 3 块区域：对象头(Header)、实例数据(Instance Data)和对齐填充(Padding)
- 对象头(Header)：包含两部分，第一部分用于存储对象自身的运行时数据，如哈希码、GC
分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等，32 位虚拟机占 32 bit，64 位虚拟机占 64 bit。官方称为 ‘Mark Word’。第二部分是类型指针，即对象指向它的类的元数据指针，虚拟机通过这个指针确定这个对象是哪个类的实例。但并不是所有的虚拟机实现都必须在对象数据上保留类型指针。另外，如果是 Java 数组，对象头中还必须有一块用于记录数组长度的数据，因为普通对象可以通过 Java 对象元数据确定大小，而数组对象不可以。 - 实例数据(Instance Data)：程序代码中所定义的各种类型的字段内容(包含父类继承下来的和子类中定义的)。
- 对齐填充(Padding)：不是必然需要，主要是占位，保证对象大小是某个字节的整数倍。
对象的访问定位
使用对象时，通过栈上的 reference 数据来操作堆上的具体对象。
目前主流的访问方式有使用句柄和直接指针
句柄的方式，就是在java堆中划分出一块内存区域叫做句柄池，用来存放到对象实例的指针，而栈中存放的是句柄池中对应对象的地址。这种方式的好处就是，在频繁的改变java堆中的对象的时候，只需要修改句柄池指向对象的引用就可以，而不需要，修改栈中存放的句柄池中的引用。相当于做了一次中转。就好比邮局，将信件送到邮局，之后的事情就可以交给邮局去处理了。
直接指针，就是放弃了中转，直接将栈中的引用指向堆中的实例对象。这种方式的好处在于，减少一次指针变换的开销。
注意：jdk1.8之后没有方法区，取而代之的是类元数据存放在元数据区
内存溢出异常
在Java虚拟机规范的描述中，除了程序计数器外，虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError（OOM）异常的可能。
Java堆溢出
| 参数 | 含义 | 解释 |
|---|---|---|
| -Xms | 初始堆大小 | 默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制. |
| -Xmx | 最大堆大小 | 默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制 |
| -XX:+HeapDumpOnOutOfMemoryError | 可以让JVM在出现内存溢出时候Dump出当前的内存转储快照。 | 可以用Eclipse Memory Analyzer打开生产的快照进行分析 |
public void HeapOOM() {
/**
* VM Args: -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
*/
List<String> list = new ArrayList<>();
int i = 0;
while (true) {
list.add(new String(i + ""));
i++;
}
}
输出：
java.lang.OutOfMemoryError: GC overhead limit exceeded
Dumping heap to java_pid17236.hprof ...
Heap dump file created [21362623 bytes in 0.068 secs]
Java堆溢出了，这表明程序有严重的问题。我们需要找造成OutOfMemoryError原因。一般有两种情况：
- 内存泄露，对象已经死了，无法通过垃圾收集器进行自动回收，通过找出泄露的代码位置和原因，才好确定解决方案；
- 内存溢出，内存中的对象都还必须存活着，这说明Java堆分配空间不足，检查堆设置大小（-Xmx与-Xms），检查代码是否存在对象生命周期太长、持有状态时间过长的情况。
栈内存溢出
虚拟机栈和本地方法栈描述了两种异常：
-
如果线程请求的深度大于虚拟机所允许的最大深度，将抛出StackOverFlowError异常
-
如果虚拟机在扩展栈时无法申请足够的内存空间，将抛出OutOfMemoryError异常
/**
* -Xss128k
* */
public class StackSOF {
private int stackLength=1;
public void stackLeak(){
stackLength++;
stackLeak();
}
public static void main(String[] args) throws Throwable{
StackSOF oom=new StackSOF();
try {
oom.stackLeak();
} catch (Exception e) {
// TODO: handle exception
System.out.println("Stack Length:"+oom.stackLength);
throw e;
}
}
}
运行结果：
Exception in thread "main" java.lang.StackOverflowError
参考：
1196
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
