堆的核心概述
堆与进程
- 一个JVM实例只存在一个堆内存，堆也是Java内存管理的核心区域。
- Java堆区在JVM启动的时候即被创建，其空间大小也就确定了，堆是JVM管理的最大一块内存空间，并且堆内存的大小是可以调节的。
- 《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。
- 所有的线程共享Java堆，在这里还可以划分线程私有的缓冲区（Thread Local Allocation Buffer，TLAB）
- 《Java虚拟机规范》中对Java堆的描述是：所有的对象实例以及数组都应当在运行时分配在堆上。（The heap is the run-time data area from which memory for all class instances and arrays is allocated）
从实际使用角度看：“几乎”所有的对象实例都在堆分配内存，但并非全部。因为还有一些对象是在栈上分配的（逃逸分析，标量替换）- 数组和对象可能永远不会存储在栈上（不一定），因为栈帧中保存引用，这个引用指向对象或者数组在堆中的位置。
- 在方法结束后，堆中的对象不会马上被移除，仅仅在垃圾收集的时候才会被移除。
也就是触发了GC的时候，才会进行回收
如果堆中对象马上被回收，那么会频繁调用垃圾回收器，占用资源- 堆，是GC（Garbage Collection，垃圾收集器）执行垃圾回收的重点区域。
public class SimpleHeap {
private int id;//属性、成员变量
public SimpleHeap(int id) {
this.id = id;
}
public void show() {
System.out.println("My ID is " + id);
}
public static void main(String[] args) {
SimpleHeap sl = new SimpleHeap(1);
SimpleHeap s2 = new SimpleHeap(2);
int[] arr = new int[10];
Object[] arr1 = new Object[10];
}
}
内存细分
现代垃圾收集器大部分都基于分代收集理论设计，堆空间细分为：
-
Java7 及之前堆内存逻辑上分为三部分：新生区+养老区+永久区
-
Java 8及之后堆内存逻辑上分为三部分：新生区+养老区+元空间
约定：新生区 <–> 新生代 <–> 年轻代 、 养老区 <–> 老年区 <–> 老年代、 永久区 <–> 永久代
设置堆内存大小与OOM
设置堆内存
- Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，大家可以通过选项”-xms”和”-Xmx”来进行设置。
-xms用于表示堆区的起始内存，等价于-XX:InitialHeapSize
-Xmx则用于表示堆区的最大内存，等价于-XX:MaxHeapSize
- 一旦堆区中的内存大小超过“-Xmx”所指定的最大内存时，将会抛出OutofMemoryError异常。
- 通常会将-xms和-Xmx两个参数配置相同的值
- 原因：假设两个不一样，初始内存小，最大内存大。在运行期间如果堆内存不够用了，会一直扩容直到最大内存。如果内存够用且多了，也会不断的缩容释放。频繁的扩容和释放造成不必要的压力，避免在GC之后调整堆内存给服务器带来压力。
- 如果两个设置一样的就少了频繁扩容和缩容的步骤。内存不够了就直接报OOM
- 默认情况下:初始内存大小：物理电脑内存大小/64；最大内存大小：物理电脑内存大小/4
/**
* 1. 设置堆空间大小的参数
* -xms 用来设置堆空间（年轻代+老年代）的初始内存大小
* -X 是jvm的运行参数
* ms 是memory start
* -Xmx 用来设置堆空间（年轻代+老年代）的最大内存大小
*
* 2. 默认堆空间的大小
* 初始内存大小：物理电脑内存大小 / 64
* 最大内存大小：物理电脑内存大小 / 4
* 3. 手动设置：-xms600m -Xmx600m
* 开发中建议将初始堆内存和最大的堆内存设置成相同的值。
*
* 4. 查看设置的参数：方式一： jps / jstat -gc 进程id
* 方式二：-XX:+PrintGCDetails
*/
public class HeapSpaceInitial {
public static void main(String[] args) {
//返回Java虚拟机中的堆内存总量
long initialMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024;
//返回Java虚拟机试图使用的最大堆内存量
long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024;
System.out.println("-xms : " + initialMemory + "M");
System.out.println("-Xmx : " + maxMemory + "M");
System.out.println("系统内存大小为：" + initialMemory * 64.0 / 1024 + "G");
System.out.println("系统内存大小为：" + maxMemory * 4.0 / 1024 + "G");
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printstacktrace();
}
}
}
-xms : 256M
-Xmx : 4072M
系统内存大小为：16.0G
系统内存大小为：15.90625G
查看数据：
方式一： jps / jstat -gc 进程id
其中：
SOC: S0区总共容量
S1C: S1区总共容量
S0U: S0区使用的量
S1U: S1区使用的量
EC: 伊甸园区总共容量
EU: 伊甸园区使用的量
OC: 老年代总共容量
OU: 老年代使用的量
方式二：-XX:+PrintGCDetails
OOM
public class OOMTest {
public static void main(String[] args) {
ArrayList<Picture> list = new ArrayList<>();
while(true){
try {
Thread.sleep(20);
} catch (InterruptedException e) {
e.printstacktrace();
}
list.add(new Picture(new Random().nextInt(1024 * 1024)));
}
}
}
class Picture{
private byte[] pixels;
public Picture(int length) {
this.pixels = new byte[length];
}
}
结果：
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at com.atguigu.java.Picture.<init>(OOMTest.java:29)
at com.atguigu.java.OOMTest.main(OOMTest.java:20)
Process finished with exit code 1
年轻代与老年代
- 存储在JVM中的Java对象可以被划分为两类：
- 一类是生命周期较短的瞬时对象，这类对象的创建和消亡都非常迅速
- 另外一类对象的生命周期却非常长，在某些极端的情况下还能够与JVM的生命周期保持一致
- Java堆区进一步细分的话，可以划分为年轻代（YoungGen）和老年代（oldGen）
- 其中年轻代又可以划分为Eden空间、Survivor0空间和Survivor1空间（有时也叫做from区、to区）
- 配置新生代与老年代在堆结构的占比
默认-XX:NewRatio=2，表示新生代占1，老年代占2，新生代占整个堆的1/3
可以修改-XX:NewRatio=4，表示新生代占1，老年代占4，新生代占整个堆的1/5- 在HotSpot中，Eden空间和另外两个survivor空间缺省所占的比例是8 : 1 : 1，
- 当然开发人员可以通过选项**-XX:SurvivorRatio调整这个空间比例。比如-XX:SurvivorRatio=8，必须显式设置它，不然不是默认值8**
- 几乎所有的Java对象都是在Eden区被new出来的。
- 绝大部分的Java对象的销毁都在新生代进行了（有些大的对象在Eden区无法存储时候，将直接进入老年代），IBM公司的专门研究表明，新生代中80%的对象都是“朝生夕死”的。
- 可以使用选项”-Xmn”设置新生代最大内存大小，但这个参数一般使用默认值就可以了。如果同时设置了新生代和老年代的比例，也设置了这个新生代的大小，则按这个设置为准
/**
* -xms600m -Xmx600m
*
* -XX:NewRatio ： 设置新生代与老年代的比例。默认值是2.
* -XX:SurvivorRatio ：设置新生代中Eden区与Survivor区的比例。默认值是8
* -XX:-UseAdaptiveSizePolicy ：关闭自适应的内存分配策略 （暂时用不到）
* -Xmn:设置新生代的空间的大小。 （一般不设置）
*
* @author shkstart [email protected]
* @create 2020 17:23
*/
public class EdenSurvivorTest {
public static void main(String[] args) {
System.out.println("我只是来打个酱油~");
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printstacktrace();
}
}
}
图解对象分配的一般过程
为新对象分配内存是一件非常严谨和复杂的任务，JVM的设计者们不仅需要考虑内存如何分配、在哪里分配等问题，并且由于内存分配算法与内存回收算法密切相关，所以还需要考虑GC执行完内存回收后是否会在内存空间中产生内存碎片。
具体过程：
- new的对象先放伊甸园区。此区有大小限制。
- 当伊甸园的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收（MinorGC），将伊甸园区中的不再被其他对象所引用的对象进行销毁。再加载新的对象放到伊甸园区。
- 然后将伊甸园中的剩余对象移动到幸存者0区。
- 如果再次触发垃圾回收，此时上次幸存下来的放到幸存者0区的，如果没有回收，就会放到幸存者1区。
- 如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。
- 啥时候能去养老区呢？可以设置次数。默认是15次。可以设置新生区进入养老区的年龄限制，设置 JVM 参数：-XX:MaxTenuringThreshold=N 进行设置
- 在养老区，相对悠闲。当养老区内存不足时，再次触发GC：Major GC，进行养老区的内存清理
- 若养老区执行了Major GC之后，发现依然无法进行对象的保存，就会产生OOM异常。
图解：
注意：
当eden区满时会触发YGC/Minor GC，那么当幸存者区满时会触发吗？？
不会触发(不会触发，不代表不存在垃圾回收)，当我们eden区触发YGC/Minor GC时，会将我们的eden区和幸存者区一起进行垃圾回收
幸存者区在这个计数还没有达到15前，有没有可能直接晋升到老年代？？
有可能，下面讲？
有没有可能一开始创建对象就在老年区，而不在eden区？？
有可能
- 关于垃圾回收：频繁在新生区收集，很少在养老区收集，几乎不在永久区/元空间收集。
- 针对幸存者s0,s1区的总结：复制之后有交换，谁空谁是to
特殊情况图解：
常用调优工具
- JDK命令行
- Eclipse：Memory Analyzer Tool
- Jconsole
- Visual VM（实时监控，推荐）
- jprofiler（IDEA插件）
- Java Flight Recorder（实时监控）
- GCViewer GCEasy
Minor GC,Major GC与Full GC的对比
- 我们都知道，JVM的调优的一个环节，也就是垃圾收集，我们需要尽量的避免垃圾回收，因为在垃圾回收的过程中，容易出现STW（Stop the World）的问题，而 Major GC 和 Full GC出现STW的时间，是Minor GC的10倍以上
- JVM在进行GC时，并非每次都对上面三个内存区域一起回收的，大部分时候回收的都是指新生代。针对Hotspot VM的实现，它里面的GC按照回收区域又分为两大种类型：一种是部分收集（Partial GC），一种是整堆收集（FullGC）
部分收集：不是完整收集整个Java堆的垃圾收集。其中又分为：
整堆收集（Full GC）：收集整个java堆和方法区的垃圾收集。
Young GC/Minor GC
年轻代 GC（Minor GC）触发机制
Major GC
老年代GC（MajorGC）触发机制
Full GC 触发机制
触发Full GC执行的情况有如下五种：
GC日志分析
/**
* 测试MinorGC 、 MajorGC、FullGC
* -xms9m -Xmx9m -XX:+PrintGCDetails
* @author shkstart [email protected]
* @create 2020 14:19
*/
public class GCTest {
public static void main(String[] args) {
int i = 0;
try {
List<String> list = new ArrayList<>();
String a = "atguigu.com";
while (true) {
list.add(a);
a = a + a;
i++;
}
} catch (Throwable t) {
t.printstacktrace();
System.out.println("遍历次数为：" + i);
}
}
}
[GC (Allocation Failure) [PSYoungGen: 2037K->504K(2560K)] 2037K->728K(9728K), 0.0455865 secs] [Times: user=0.00 sys=0.00, real=0.06 secs]
[GC (Allocation Failure) [PSYoungGen: 2246K->496K(2560K)] 2470K->1506K(9728K), 0.0009094 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [PSYoungGen: 2294K->488K(2560K)] 3305K->2210K(9728K), 0.0009568 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [PSYoungGen: 1231K->488K(2560K)] 7177K->6434K(9728K), 0.0005594 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [PSYoungGen: 488K->472K(2560K)] 6434K->6418K(9728K), 0.0005890 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (Allocation Failure) [PSYoungGen: 472K->0K(2560K)] [ParOldGen: 5946K->4944K(7168K)] 6418K->4944K(9728K), [Metaspace: 3492K->3492K(1056768K)], 0.0045270 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
[GC (Allocation Failure) [PSYoungGen: 0K->0K(1536K)] 4944K->4944K(8704K), 0.0004954 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (Allocation Failure) java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
at java.lang.StringBuilder.append(StringBuilder.java:136)
at com.atguigu.java1.GCTest.main(GCTest.java:20)
[PSYoungGen: 0K->0K(1536K)] [ParOldGen: 4944K->4877K(7168K)] 4944K->4877K(8704K), [Metaspace: 3492K->3492K(1056768K)], 0.0076061 secs] [Times: user=0.00 sys=0.02, real=0.01 secs]
遍历次数为：16
Heap
PSYoungGen total 1536K, used 60K [0x00000000ffd00000, 0x0000000100000000, 0x0000000100000000)
eden space 1024K, 5% used [0x00000000ffd00000,0x00000000ffd0f058,0x00000000ffe00000)
from space 512K, 0% used [0x00000000fff80000,0x00000000fff80000,0x0000000100000000)
to space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
ParOldGen total 7168K, used 4877K [0x00000000ff600000, 0x00000000ffd00000, 0x00000000ffd00000)
object space 7168K, 68% used [0x00000000ff600000,0x00000000ffac3408,0x00000000ffd00000)
Metaspace used 3525K, capacity 4502K, committed 4864K, reserved 1056768K
class space used 391K, capacity 394K, committed 512K, reserved 1048576K
堆空间分代思想
为什么要把Java堆分代？不分代就不能正常工作了吗？经研究，不同对象的生命周期不同。70%-99%的对象是临时对象。
新生代：有Eden、两块大小相同的survivor（又称为from/to或s0/s1）构成，to总为空。
老年代：存放新生代中经历多次GC仍然存活的对象。
其实不分代完全可以，分代的唯一理由就是优化GC性能。
对象内存分配策略
正常分配：
如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并将对象年龄设为1。
对象在Survivor区中每熬过一次MinorGC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁，其实每个JVM、每个GC都有所不同）时，就会被晋升到老年代
对象晋升老年代的年龄阀值，可以通过选项-XX:MaxTenuringThreshold来设置
针对不同年龄段的对象分配原则如下所示：
- 优先分配到Eden
- 大对象直接分配到老年代：尽量避免程序中出现过多的大对象
- 长期存活的对象分配到老年代
- 动态对象年龄判断：如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
- 空间分配担保： -XX:HandlePromotionFailure
TLAB为对象分配内存（保证线程安全）
为什么有 TLAB
- 堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据
- 由于对象实例的创建在JVM中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的
- 为避免多个线程操作同一地址，需要使用加锁等机制，进而影响分配速度。
什么是 TLAB
TLAB再说明
堆空间参数设置
/**
* 测试堆空间常用的jvm参数：
* -XX:+PrintFlagsInitial : 查看所有的参数的默认初始值
* -XX:+PrintFlagsFinal ：查看所有的参数的最终值（可能会存在修改，不再是初始值）
* 具体查看某个参数的指令： jps：查看当前运行中的进程
* jinfo -flag SurvivorRatio 进程id
*
* -xms：初始堆空间内存 （默认为物理内存的1/64）
* -Xmx：最大堆空间内存（默认为物理内存的1/4）
* -Xmn：设置新生代的大小。(初始值及最大值)
* -XX:NewRatio：配置新生代与老年代在堆结构的占比
* -XX:SurvivorRatio：设置新生代中Eden和S0/S1空间的比例
* -XX:MaxTenuringThreshold：设置新生代垃圾的最大年龄
* -XX:+PrintGCDetails：输出详细的GC处理日志
* 打印gc简要信息：① -XX:+PrintGC ② -verbose:gc
* -XX:HandlePromotionFailure：是否设置空间分配担保
*/
空间分配担保
- 在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间。
如果大于，则此次Minor GC是安全的
如果小于，则虚拟机会查看**-XX:HandlePromotionFailure**设置值是否允担保失败。- 如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小。
如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；
如果小于，则进行一次Full GC。
如果HandlePromotionFailure=false，则进行一次Full GC。- JDK6 Update 24之后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full GC。即 HandlePromotionFailure=true
堆是分配对象的唯一选择么？
在《深入理解Java虚拟机》中关于Java堆内存有这样一段描述：
随着JIT编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。
在Java虚拟机中，对象是在Java堆中分配内存的，这是一个普遍的常识。但是，有一种特殊情况，那就是如果经过逃逸分析（Escape Analysis）后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。这也是最常见的堆外存储技术。
逃逸分析
逃逸分析举例
没有发生逃逸的对象，则可以分配到栈（无线程安全问题）上，随着方法执行的结束，栈空间就被移除（也就无需GC）
public void my_method() {
V v = new V();
// use v
// ....
v = null;
}
下面代码中的 StringBuffer sb 发生了逃逸，不能在栈上分配
public static StringBuffer createStringBuffer(String s1, String s2) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
return sb;
}
如果想要StringBuffer sb不发生逃逸，可以这样写
public static String createStringBuffer(String s1, String s2) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
return sb.toString();
}
/**
* 逃逸分析
*
* 如何快速的判断是否发生了逃逸分析，大家就看new的对象实体是否有可能在方法外被调用。
*/
public class EscapeAnalysis {
public EscapeAnalysis obj;
/*
方法返回EscapeAnalysis对象，发生逃逸
*/
public EscapeAnalysis getInstance(){
return obj == null? new EscapeAnalysis() : obj;
}
/*
为成员属性赋值，发生逃逸
*/
public void setobj(){
this.obj = new EscapeAnalysis();
}
//思考：如果当前的obj引用声明为static的？仍然会发生逃逸。
/*
对象的作用域仅在当前方法中有效，没有发生逃逸
*/
public void useEscapeAnalysis(){
EscapeAnalysis e = new EscapeAnalysis();
}
/*
引用成员变量的值，发生逃逸
*/
public void useEscapeAnalysis1(){
EscapeAnalysis e = getInstance();
//getInstance().xxx()同样会发生逃逸
}
}
总结
开发中能使用局部变量的，就不要使用在方法外定义。
代码优化
使用逃逸分析，编译器可以对代码做如下优化：
栈上分配
同步省略（同步消除）
public void f() {
Object hollis = new Object();
synchronized(hollis) {
System.out.println(hollis);
}
}
代码中对hollis这个对象加锁，但是hollis对象的生命周期只在f()方法中，并不会被其他线程所访问到，所以在JIT编译阶段就会被优化掉，优化成：
public void f() {
Object hellis = new Object();
System.out.println(hellis);
}
字节码分析：
public class SynchronizedTest {
public void f() {
Object hollis = new Object();
synchronized(hollis) {
System.out.println(hollis);
}
}
}
注意：字节码文件中并没有进行优化，可以看到加锁和释放锁的操作依然存在，同步省略操作是在运行时发生的
分离对象或标量替换
标量替换举例
public static void main(String args[]) {
alloc();
}
private static void alloc() {
Point point = new Point(1,2);
System.out.println("point.x" + point.x + ";point.y" + point.y);
}
class Point {
private int x;
private int y;
}
以上代码，经过标量替换后，就会变成
private static void alloc() {
int x = 1;
int y = 2;
System.out.println("point.x = " + x + "; point.y=" + y);
}
- 可以看到，Point这个聚合量经过逃逸分析后，发现他并没有逃逸，就被替换成两个聚合量了。
- 那么标量替换有什么好处呢？就是可以大大减少堆内存的占用。因为一旦不需要创建对象了，那么就不再需要分配堆内存了。(因为如果为对象的话，那么局部变量表中放它的引用，实际存储在堆中；标量替换后的话，则基本数据类型保存在局部变量表里)
- 标量替换为栈上分配提供了很好的基础。
逃逸分析的不足
关于逃逸分析的论文在1999年就已经发表了，但直到JDK1.6才有实现，而且这项技术到如今也并不是十分成熟的。
其根本原因就是无法保证逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。
一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。
虽然这项技术并不十分成熟，但是它也是即时编译器优化技术中一个十分重要的手段。
注意到有一些观点，认为通过逃逸分析，JVM会在栈上分配那些不会逃逸的对象，这在理论上是可行的，但是取决于JVM设计者的选择。据我所知，Oracle Hotspot JVM中并未这么做（刚刚演示的效果，是因为HotSpot实现了标量替换），这一点在逃逸分析相关的文档里已经说明，所以可以明确在HotSpot虚拟机上，所有的对象实例都是创建在堆上。
目前很多书籍还是基于JDK7以前的版本，JDK已经发生了很大变化，intern字符串的缓存和静态变量曾经都被分配在永久代上，而永久代已经被元数据区取代。但是intern字符串缓存和静态变量并不是被转移到元数据区，而是直接在堆上分配，所以这一点同样符合前面一点的结论：对象实例都是分配在堆上。
堆是分配对象的唯一选择么？
对象实例都是分配在堆上
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
