Java 7以及之前堆内存逻辑上是分为三部分：新生区+养老区+永久区
Java 8以及之后的堆内存逻辑上分为：新生区+养老区+元空间
-Xms //用于表示堆空间的起始内存（泛指年轻代与老年代），等价 -XX:InitialHeapSize
-Xmx //用于表示堆区的最大内存 -XX:MaxHeapSize
----------------------------------------------
/**
* 1. 设置堆空间大小的参数
* -Xms 用来设置堆空间（年轻代+老年代）的初始内存大小
* -X 是jvm的运行参数
* ms 是memory start
* -Xmx 用来设置堆空间（年轻代+老年代）的最大内存大小
*
* 2. 默认堆空间的大小
* 初始内存大小：物理电脑内存大小 / 64
* 最大内存大小：物理电脑内存大小 / 4
* 3. 手动设置：-Xms600m -Xmx600m
* 开发中建议将初始堆内存和最大的堆内存设置成相同的值。
*
* 4. 查看设置的参数：方式一： jps / jstat -gc 进程id
* 方式二：-XX:+PrintGCDetails
查看堆内存占用情况
import java.util.ArrayList;
import java.util.Random;
/**
* -Xms600m -Xmx600m
* @author shkstart shkstart@126.com
* @create 2020 21:12
*/
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];
}
}
Java堆区进一步花费可分为
年轻代（YoungGen）
年轻代可以划分为
Eden（伊甸园）空间
Survivor 0空间(From区)
Survivor 1空间(To区)
老年代(OldGen)
-Xms600m -Xmx600m
-XX:NewRatio ： 设置新生代与老年代的比例。默认值是2.
-XX:SurvivorRatio ：设置新生代中Eden区与Survivor区的比例。默认值是8
-XX:-UseAdaptiveSizePolicy ：关闭自适应的内存分配策略 （暂时用不到）
-Xmn:设置新生代的空间的大小。 （一般不设置）
1. new 的对象先放在伊甸园区(Eden)这个区域有大小限制===>因此只有这里有OOM异常
2. 当一点远去的空间填满时,触发Minor GC,进行垃圾回收
3. 将伊甸园中剩余对象移动到幸存者0区
4. 在此触发垃圾回收,此时幸存者0区的对象还是或者那么就会方法幸存者1区
5. 如果在此精力垃圾回收,此时会重新放回幸存者0区,接着再去1区
6. 什么时候进入养老区呢?可以设置次数,默认阈值是15(既age=15,在0区1区反复横跳15次之后)
也可用过参数设阈值 -XX:MaxTenurigThreshold=<N>
复制之后有交换,谁空谁是to区
频繁的在新生区收集,很少在养老区收集,几乎不去永久区/元空间收集
JVM进行GC时,并不是针对上面三个内存区域(新生代,老年代,方法区)一起回收的
新年代收集(Minor GC/Young GC):只是新生代的垃圾回收
老年代收集(Major GC/Old GC):只是老年代的垃圾收集
目前只有CMS GC会有单独收集老年代的行为
注意:Major GC只是老年代的垃圾收集,不能Full GC混淆使用.需要具体分辨是老年代回收还是值整堆回收
混合收集(Mixed GC) :收集整个新生代以及部分老年代的垃圾收集
目前,只有G1 GC会有这种行为
收集整个java堆和方法区的垃圾收集
当年轻代内存不足时,就会触发Minor GC 这里年轻代是指Eden(伊甸园)代满了 , Survivor满了不会触发GC
Java大多对象具有朝生夕死的特性,因此Minor GC是频繁的,一般回收速度也比较快
Minor GC会触发STW,暂停其他用户的线程,等垃圾回收结束,用户线程才能恢复运行
1. 值发生在老年代的GC,对象从老年代小时,便可以说Major GC 或者 Full GC触发了
2. 出现了Major GC 经常会伴随至少一次的Minor GC(不绝对,在Parallel Scavenge 收集器的收集策略就有直接进行Major GC 的策略选择过程)
3. Major GC的速度一般会比Minor GC 慢10倍以上,因此STW时间更长
4. 如果Major GC后,内存还不足就会报OOM异常
要避免full gc 是开发调优中要避免的 这样STW时间会短一点
因为Java的对象70%-99%都是朝生夕死的 分代可以优化GC的一个性能问题
/**
* 测试堆空间常用的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：是否设置空间分配担保
*
*/
public class HeapArgsTest {
public static void main(String[] args) {
}
}
随着JIT编译器的发展与逃逸分析技术逐渐成熟,栈上分配与标量替换优化技术会导致一些微妙的变化,所有对象都分配到对上也逐渐不那么绝对了
如果经过====>逃逸分析(Escape Analysis)后发现,一个对象并没有逃逸出去方法的话,那么就可能被优化成栈上分配
当一个对象在方法中被定义后,**对象只在方法内部使用,**则**认为没有发生逃逸**
/**
* 逃逸分析
*
* 如何快速的判断是否发生了逃逸分析，大家就看new的对象实体是否有可能在方法外被调用。
* @author shkstart
* @create 2020 下午 4:00
*/
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()同样会发生逃逸
}
}
开发中能使用局部变量的,就不要使用方法外定义
package com.atguigu.java2;
/**
* 栈上分配测试
* -Xmx1G -Xms1G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
*/
public class StackAllocation {
public static void main(String[] args) {
long start = System.currentTimeMillis();
for (int i = 0; i < 10000000; i++) {
alloc();
}
// 查看执行时间
long end = System.currentTimeMillis();
System.out.println("花费的时间为： " + (end - start) + " ms");
// 为了方便查看堆内存中对象个数，线程sleep
try {
Thread.sleep(1000000);
} catch (InterruptedException e1) {
e1.printStackTrace();
}
}
private static void alloc() {
User user = new User();//未发生逃逸
}
static class User {
}
}
大家可以看到这个是开启逃逸分析的效果(JDK7(确切来说JDK6_23)以后是默认开启逃逸分析)
执行时间是5毫秒
那我们来看看不开启逃逸分析的结果
执行时间是113毫秒 可见优化以后的性能是大有提升的
如果一个对象被发现只能从一个线程被访问到 那么对于这个对象的操作者可以不考虑同步
- 线程同步代价是相当高的,同步的后果是降低并发性和性能
- JIT可以借助逃逸分析来判断同步快锁使用的锁对象是否能够被一个线程锁访问而没有被发布到其他线程
====>有的对象可能不需要作为一个连续的内存结构存在也可以被访问到
====>那么对象的部分(或者全部)可以不存在内存 而是存在CPU的寄存器里
===>无法在分解成更小的数据的数据
如Java中的原始数据类型就是标量
可以分解的数据叫聚合量
如Java对象
JIT阶段如果经过逃逸分析,发现一个对象不会被外界访问的话 那么经过JIT优化就会把这个对象拆解成若干个其中包含多个成员变量来代替换 这个过程就好标量替换
/**
* 标量替换测试
* -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:-EliminateAllocations
*/
public class ScalarReplace {
public static class User {
public int id;
public String name;
}
public static void alloc() {
User u = new User();//未发生逃逸
u.id = 5;
u.name = "www.atguigu.com";
}
public static void main(String[] args) {
long start = System.currentTimeMillis();
for (int i = 0; i < 10000000; i++) {
alloc();
}
long end = System.currentTimeMillis();
System.out.println("花费的时间为： " + (end - start) + " ms");
}
}
/*
class Customer{
String name;
int id;
Account acct;
}
class Account{
double balance;
}
*/