JVM内存结构
- Class Loader类加载器
- Execution Engine 执行引擎负责解释命令，提交操作系统执行
- Native Interface 本地接口
- Runtime Data Area 运行数据区
1、Class Loader 类加载器
负责加载class文件，class文件在文件开头有特定的文件标示，并且ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。
2、Native Interface
本地接口的作用是融合不同的编程语言为Java所用，它的初衷是融合C/C++程序，Java 诞生的时候是C/C++横行的时候，要想立足，必须有调用C/C++程序，于是就在内存中专门开辟了一块区域处理标记为native的代码，它的具体做法是Native Method Stack中登记native方法，在Execution Engine执行时加载native libraies。目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机，或者Java系统管理生产设备，在企业级应用中已经比较少见。 因为现在的异构领域间的通信很发达，比如可以使用Socket通信，也可以使用WebService等等， 不多做介绍。
3、Method Area方法区
方法区是被所有线程共享，所有字段和方法字节码，以及一些特殊方法如构造函数，接口代码也在此定义。简单说，所有定义的方法的信息都保存在该区域，此区属于共享区间。 静态变量+常量+类信息+运行时常量池(JDK1.6)存在方法区中 实例变量存在堆内存中保存。
4、PC Register 程序计数器
每个线程都有一个程序计数器，就是一个指针，指向方法区中的方法字节码(下一个将要执行的指令代码)，由执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。
5、Native Method Stack 本地方法栈
它的具体做法是Native Method Stack中登记native方法，在Execution Engine执行时加载native libraies。
类加载器
类加载的过程
1. 加载
这个很简单，程序运行之前jvm会把编译完成的.class二进制文件加载到内存，供程序使用，用到的就是类加载器classLoader ，这里也可以看出java程序的运行并不是直接依 靠底层的操作系统，而是基于jvm虚拟机。如果没有类加载器，java文件就只是磁盘中的一个普通文件。
2. 链接
连接是很重要的一步，过程比较复杂，分为三步 验证 》准备 》解析
验证：确保类加载的正确性。一般情况由javac编译的class文件是不会有问题的，但是可能有人的class文件是自己通过其他方式编译出来的，这就很有可能不符合jvm的编译规则，这一步就是要过滤掉这部分不合法文件
准备：为类的静态变量分配内存，将其初始化为默认值 。我们都知道静态变量是可以不用我们手动赋值的，它自然会有一个初始值，比如int 类型的初始值就是0 ；boolean类型初始值为false；引用类型的初始值为null 。 这里注意，只是为静态变量分配内存，此时是没有对象实例的
解析：把类中的符号引用转化为直接引用。解释一下符号引用和直接引用。比如在方法A中使用方法B，
A（）{B（）；}
这里的B（）就是符号引用，初学java时我们都是知道这是java的引用，以为B指向B方法的内存地址，但是这是不完整的，这里的B只是一个符号引用，它对于方法的调用没有太多的实际意义，可以这么认为，他就是给程序员看的一个标志，让程序员知道，这个方法可以这么调用，但是B方法实际调用时是通过一个指针指向B方法的内存地址，这个指针才是真正负责方法调用，他就是直接引用。
3. 类初始化
为类的静态变量赋予正确的初始值，上述的准备阶段为静态变量赋予的是虚拟机默认的初始值，此处赋予的才是程序编写者为变量分配的真正的初始值
类加载器的种类
JDK 默认提供了如下几种ClassLoader
-
Bootstrp loaderBootstrp加载器是用C++语言写的，它是在Java虚拟机启动后初始化的，它主要负责加载%JAVA_HOME%/jre/lib,-Xbootclasspath参数指定的路径以及%JAVA_HOME%/jre/classes中的类。
-
ExtClassLoader Bootstrp loader加载ExtClassLoader,并且将ExtClassLoader的父加载器设置为Bootstrp。 loader.ExtClassLoader是用Java写的，具体来说就是 sun.misc.Launcher$ExtClassLoader，ExtClassLoader主要加载%JAVA_HOME%/jre/lib/ext，此路径下的所有classes目录以及java.ext.dirs系统变量指定的路径中类库。
-
AppClassLoader Bootstrp loader加载完ExtClassLoader后，就会加载AppClassLoader,并且将
AppClassLoader的父加载器指定为 ExtClassLoader。AppClassLoader也是用Java写成的，它的实现类是sun.misc.Launcher$AppClassLoader，另外我们知道ClassLoader中有个getSystemClassLoader方法,此方法返回的正是AppclassLoader.AppClassLoader主要负责加载classpath所指定的位置的类或者是jar文档，它也是Java程序默认的类加载器。
双亲委托机制
1、工作流程
- 当Application ClassLoader 收到一个类加载请求时，他首先不会自己去尝试加载这个类，而是将这个请求委派给父类加载器Extension ClassLoader去完成。
- 当Extension ClassLoader收到一个类加载请求时，他首先也不会自己去尝试加载这个类，而是将请求委派给父类加载器Bootstrap ClassLoader去完成。
- 如果Bootstrap ClassLoader加载失败(在<JAVA_HOME>\lib中未找到所需类)，就会让Extension ClassLoader尝试加载。
- 如果Extension ClassLoader也加载失败，就会使用Application ClassLoader加载。
- 如果Application ClassLoader也加载失败，就会使用自定义加载器去尝试加载。
- 如果均加载失败，就会抛出ClassNotFoundException异常。
“双亲委派”机制只是Java推荐的机制，并不是强制的机制。我们可以继承java.lang.ClassLoader类，实现自己的类加载器。
如果想保持双亲委派模型，就应该重写findClass(name)方法；如果想破坏双亲委派模型，可以重写loadClass(name)方法。
2、为什么使用这种双亲委托模式呢？
因为这样可以避免重复加载，当父亲已经加载了该类的时候，就没有必要子ClassLoader再加载一次。
考虑到安全因素，我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String已经在启动时被加载，所以用户自定义类是无法加载一个自定义的ClassLoader。
2、思考
假如我们自己写了一个java.lang.String的类，我们是否可以替换调JDK本身的类？
JVM强制 java.* 包下的类是由Bootstrap ClassLoader加载
栈（stack）栈管运行
栈（stack）是什么?
栈也叫栈内存，主管Java程序的运行，是在线程创建时创建，它的生命期是跟随线程的生命期，线程结束栈内存也就释放，对于栈来说不存在垃圾回收问题，只要线程结束该栈就Over,生命周期和线程一致，是线程私有的。基本类型的变量和对象的引用变量都是在函数的栈内存中分配。
栈运行的原理
栈中的数据都是以栈帧(Stack Frame) 的格式存在，栈帧是一个内存区块，是一个数据集，是一个有关方法(Method)和运行期数据的数据集，当一个方法A被调用时就产生了一个栈帧F1, 并被压入到栈中，A方法又调用了B方法，先是产生栈帧F2也被压入栈，B方法又调用了C方法，于是产生栈帧F3也被压入栈，… 执行完毕后，先弹出F3栈帧，再弹出F2栈帧，再弹出F1栈…遵循“先进后出”或者“后进先出”原则，可以把栈想象成弹夹，方法为子弹。
栈结构图
- 局部变量表
局部变量表是一组变量值存储空间，用于存放方法参数和方法内部定义的局部变量。 - 操作数栈
操作数栈也是被组织成一个以字节为单位的数组，通过标准的栈操作—压栈和出栈—来访问的。比如，如果某个指令把一个值压入到操作数栈中，稍后另一个指令就可以弹出这个值来使用。 虚拟机把操作数栈作为它的工作区——大多数指令都要从这里弹出数据，执行运算，然后把结果压回操作数栈。比如，iadd指令就要从操作数栈中弹出两个整数，执行加法运算，其结果又压回到操作数栈中，看看下面的示例，它演示了虚拟机是如何把两个int类型的局部变量相加，再把结果保存到第三个局部变量的：
- begin
- iload_0 // push the int in local variable 0 onto the stack
- iload_1 // push the int in local variable 1 onto the stack
- iadd // pop two ints, add them, push result
- istore_2 // pop int, store into local variable 2
- end
在这个字节码序列里，前两个指令iload_0和iload_1将存储在局部变量中索引为0和1的整数压入操作数栈中，其后iadd指令从操作数栈中弹出那两个整数相加，再将结果压入操作数栈。第四条指令istore_2则从操作数栈中弹出结果，并把它存储到局部变量区索引为2的位置。
- 动态连接
每个栈帧都包含一个指向运行时常量池中该栈帧所属性方法的引用，持有这个引用是为了支持方法调用过程中的动态连接。在 Class 文件的常量池中存有大量的 符号引用，字节码中的方法调用指令就以常量池中指向方法的符号引用为参数。这些符号引用一部分会在类加载阶段或第一次使用的时候转化为直接引用，这种转化 称为静态解析。另外一部分将在每一次的运行期期间转化为直接引用，这部分称为动态连接 - 方法返回地址
当一个方法被执行后，有两种方式退出这个方法：正常退出和异常退出。
无论采用何种方式退出，在方法退出之前，都需要返回到方法被调用的位置，程序才能继续执行，方法返回时可能需要在栈帧中保存一些信息，用来帮助恢复它的上 层方法的执行状态。一般来说，方法正常退出时，调用者 PC 计数器的值就可以作为返回地址，栈帧中很可能会保存这个计数器值。而方法异常退出时，返回地址是 要通过异常处理器来确定的，栈帧中一般不会保存这部分信息。
方法退出的过程实际上等同于把当前栈帧出栈，因此退出时可能执行的操作有：恢复上层方法的局部变量表和操作数栈，把返回值 (如果有的话) 压入调用栈帧的操作数栈中，调用 PC 计数器的值以指向方法调用指令后面的一条指令等。
栈内存溢出
Exception in thread “main” java.lang.StackOverflowError
异常产生的原因：栈帧压栈的时候，超出了栈的深度。
堆
三种JVM
- Sun HotSpot
提起HotSpot VM，相信所有Java程序员都知道，它是Sun JDK和OpenJDK中所带的虚拟机，也是目前使用范围最广的Java虚拟机。
HotSpot VM的热点代码探测能力可以通过执行计数器找出最具有编译价值的代码，然后通知JIT编译器以方法为单位进行编译。 如果一个方法被频繁调用，或方法中有效循环次数很多，将会分别触发标准编译和OSR（栈上替换）编译动作。 通过编译器与解释器恰当地协同工作，可以在最优化的程序响应时间与最佳执行性能中取得平衡，而且无须等待本地代码输出才能执行程序， 即时编译的时间压力也相对减小，这样有助于引入更多的代码优化技术，输出质量更高的本地代码。
在2006年的JavaOne大会上，Sun公司宣布最终会把Java开源，并在随后的一年，陆续将JDK的各个部分（其中当然也包括了HotSpot VM）在GPL协议下公开了源码， 并在此基础上建立了OpenJDK。这样，HotSpot VM便成为了Sun JDK和OpenJDK两个实现极度接近的JDK项目的共同虚拟机。
在2008年和2009年，Oracle公司分别收购了BEA公司和Sun公司，这样Oracle就同时拥有了两款优秀的Java虚拟机：JRockit VM和HotSpot VM。 Oracle公司宣布在不久的将来（大约应在发布JDK 8的时候）会完成这两款虚拟机的整合工作，使之优势互补。 整合的方式大致上是在HotSpot的基础上，移植JRockit的优秀特性，譬如使用JRockit的垃圾回收器与MissionControl服务， 使用HotSpot的JIT编译器与混合的运行时系统。 - BEA JRocket
BEA JRockit 旨在驱动要求极高的服务器端 Java 应用，以便为企业应用提供极高的性能、可管理性和可靠性。Oracle JRockit （原来的 Bea JRockit）系列产品是一个全面的Java运行时解决方案组合，包括了行业最快的标准Java解决方案。 大量的行业基准测试显示，基本JRockit JVM是世界上最快的JVM。JRockit面向延迟敏感型应用的解决方案JRockit Real Time提供以毫秒或微秒级的JVM响应时间，适合财务前端办公、军事指挥与控制和电信网络的需要。使用JRockit产品，客户已经体验到了显著的性能提高（一些超过了70% ）和硬件成本的减少（达50%）。
JRocket主要是定位于服务器应用，所以不关注虚拟机的启动速度，它会将所有代码即时编译为本地代码执行，JRocket的垃圾收集器具有很高的收集效率。 - IBM J9
J9与JRockit类似，亮点是高度模块化，不但可以部署在桌面或服务器上，还可以部署到嵌入式环境中，例如CLDC级别的环境；这些环境用的是同一个J9核心VM，搭配上适用于具体环境的GC和JIT编译器。IBM J9包含整套解决方案，后期维护相对会比较方便。
堆内存划分
一个JVM示例只存在一个堆内存，堆内存的大小是可以调节的，类加载器读取了类文件后，需要把类，方法，放在堆内存中，保存着所有引用类型的真实信息，以方便执行器执行，堆内存分为三部分：新生区、养老区、永久区。
堆内存示意图
新生区
新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。新生区又分为两部分:伊甸区(Eden space) 和幸存者区(Survivor pace) ，所有的类都是在伊甸区被new出来的。幸存区有两个: 0区(Survivor 0 space)和1区。新生区的空间以后会进行垃圾回收，幸存的对象，再移动到养老区。若养老区也满了,那么这个时候将产生MajorGC (FullGC) ，进行养老区的内存清理。若养老区执行了Full GC之后发现依然无法进行对象的保存，就会产生0OM异常“OutOfMemoryError"。 如果出现java lang OutofMemoryError: Java heap space异常，说明Java虛拟机的堆内存不够。原因有二: (1) Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。 (2) 代码中创建了大量大对象，并且长时间不能被垃圾收集器收集(存在被引用)
养老区
养老区用于保存从新生区筛选出来的JAVA对象，一般池对象都会在这个区域活跃
永久区
永久存储区是一个常驻内存区域，用于存放JDK自身所携带的Class, Interface的元数据，也就是说它存储的是运行环境必须的类信息，被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭JVM才会释放此区域所占用的内存。 如果出现java. lang. OutOfMemoryError: PermGen space, 说明是Java虚拟机对永久代Perm内存设置不够。般出 现这种情况，都是程序启动需要加载大量的第三方jar包。例如:在个Tomcat 下部署了太多的应用。或者大量动态反射生成的类不断被加载，最终导致Perm区被占满
熟悉三区结构后方可学习JVM垃圾收集
实际而言，方法区(MethodArea)和堆一样，是各个线程共享的内存区域，它用于存储虚拟机加载的:类信息+普通常量+静态常量+编译器编译后的代码等等，虽然JVM规范将方法区描述为堆的一个逻辑部分，但它却还有一个别名叫做Non-Heap(非堆)， 目的就是要和堆分开。 对于HotSpot虚拟机，很多开发者习惯将方法区称之为“永久代(Parmanent Gen)” ，但严格来说，两者有本质的不 同，或者说使用永久代来实现方法区而已，永久代是方法区(相当于是一个接口interface)的一个实现，jdk1.7的版 本中，已经将原本放在永久代的字符串常量池移走。
Jdk1.6及之前: 有永久代，常量池在方法区 Jdk1.7: 有永久代，但已经逐步“去永久代”，常量池在堆 Jdk1.8及之后:无永久代， 常量池在元空间
内存划分
1.7
1.8
JDK1.8以后将最初的永久代取消了，由元空间取代
目的：将HotSpot与JRockit两个虚拟机合并标准
简单参数调优
| 参数 | 注释 |
|---|---|
| -Xms | 设置初始分配大小，默认为物理内存的 1/64 |
| -Xmx | 最大分配内存，默认为物理内存的 1/4 |
| -XX:+PrintGCDetails | 输出详细的GC处理日志 |
EXP：-Xmx1024m -Xms1024m -XX:+PrintGCDetails
Runtime.getRuntime().totalMemory()
Runtime.getRuntime().maxMemory()
自动触发垃圾回收
String str = "study";
while(true){
str += str + new Random().nextInt(88888888);
}
JVM在GC 的时候，并非每次都对上面三个内存一起回收，大部分回收的指的是新生代。
按照回收区域分为两种：普通GC(Minor GC)（新生代）和全局GC(Major GC)（老年代）
GC算法
复制算法-年轻代的GC
HotSpot JVM把年轻代分为三部分，1个Eden区和2个Survivor区(分别叫from和to) .默认比例为8:1:1,一般情况下，新创建的对象都会被分配到Eden区，这些对象经过一次MinorGC，如果仍然存活，将会被移到Survivor区，对象在Survivor区中每熬过一次MinorGC，年龄就会增加1岁，当它能年龄增加到一定程度时，就会被移动到老年代中。因为年轻代中的对象基本都是期生夕死的（80%以上），所以在年轻代的垃圾回收算法使用的是复制整理算法，复制整理算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。
在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。
优点：
- 不会产生内存碎片。
缺点：
- 会开辟新的空间也就是 To survivor，用来保存有用对象
- 复制对象会花费一些时间
标记清除
分为标记和清除两阶段：首先标记出所有需要回收的对象，然后统一回收所有被标记的
缺点：
- 标记阶段和清除阶段的效率都不高。
- 显而易见的，清除后产生了大量不连续的内存碎片，导致在程序运行过程中需要分配较大对象的时候，无法找到足够的连续内存而不得不提前触发一次垃圾收集动作。
标记整理
标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
优点:
- 自带整理功能，这样不会产生大量不连续的内存空间，适合老年代的大对象存储。
算法小结：
- 内存效率：复制算法>标记清除算法>标记整理算法
- 内存整齐度：复制算法=标记整理算法>标记清除算法
- 内存利用率：标记整理算法=标记清除算法>复制算法
没有最好的算法，只有最合适的算法。
分代收集
当前商业虚拟机的垃圾收集都采用分代收集。
此算法没啥新鲜的，就是将上述三种算法整合了一下。具体如下： 根据各个年代的特点采取最适当的收集算法
- 在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法。只需要付出少量存活对象的复制成本就可以完成收集。
- 老年代中因为对象存活率高、没有额外空间对他进行分配担保，就必须用标记-清除或者标记-整理。
JVM参数类型
标配参数
- java -version
- java -help
X参数
-Xint 解释执行 -Xcomp 第一次使用就编译成本地代码 -Xmixed 混合模式
当JIT编译启用时（默认是启用的），JVM读入.class文件解释后，将其发给JIT编译器。JIT编译器将字节码编译成本机机器代码。 通常javac将程序源码编译，转换成java字节码，JVM通过解释字节码将其翻译成相应的机器指令，逐条读入，逐条解释翻译。非常显然，经过解释运行，其运行速度必定会比可运行的二进制字节码程序慢。为了提高运行速度，引入了JIT技术。 在执行时JIT会把翻译过的机器码保存起来，已备下次使用，因此从理论上来说，采用该JIT技术，能够接近纯编译技术。
XX参数
boolean类型
公式：-XX:+或者-某个属性值
+表示开启
-表示关闭
kv设值类型
公式：-XX:属性值key=属性值value
默认的活过15岁进入养老区的参数设置：-XX:MaxTenuringThreshold=30
参数查看命令
-XX:+PrintFlagsInitial : 查看默认参数设置 -XX:+PrintFlagsFinal : 最终的参数设置， = 和:=的区别
jps命令 :查看java进程 jps -l 得到进程号 jinfo:正在运行Java的信息 jinfo -flag PrintGCDetails 进程号:代表的意思是查看某个Java进程关于打印垃圾回收的机制
java -XX:+PrintCommandLineFlags -version 可以查看垃圾回收器
-Xms -Xmx 如何解释这两个参数
-Xms:-XX:InitialHeapSize
-Xmx:-XX:MaxHeapSize
引用
引用计数算法
原理：给对象中每一个对象分配一个引用计数器，每当有地方引用该对象时，引用计数器的值加一，当引用失效时，引用计数器的值减一，不管什么时候，只要引用计数器的值等于0了，说明该对象不可能再被使用了。
优点：实现原理简单，而且判定效率很高。大部分情况下都是一个不错的算法。
缺点：很难解决对象之间相互循环引用的问题，例如:对象A和对象B都有instance字段，并且A.instance=B，并且B.instance=A，即使这两个对象再无任何其他引用，并且已经不可能再被访问，引用计数器的值也为0了，这两个对象也是不可能再被使用了，此时引用计数器算法也无法通知GC来回收这两个对象
枚举根节点做可达性分析
四种GCRoots对象：
- 虚拟机栈（栈帧中的局部变量区）
- 方法区中的类静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈JNI引用的对象
方法区的回收
垃圾收集主要回收两部分内容：废弃常量和无用的类 回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果在这时候发生内存回收，而且必要的话，这个“abc”常量就会被系统“请”出常量池。判定一个类是否是无用类，需要满足三个条件：
-
该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
-
加载该类的ClassLoader已经被回收。
-
该类对应的java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
强引用
默认支持 百分之九十五都是强引用，当内存不足，JVM开始垃圾回收 ，对于强引用的对象，就算是抛出OOM，也不会对该对象进行回收。强引用是造成Java内存泄露的最主要原因之一。
对于一个普通对象，如果没有其他引用关系，只要超过了引用的作用域（局部变量）或者显示的将相应的引用赋值为null，一般就认为可以被垃圾收集了。
软引用
内存充足 不回收，内存不足 回收，需要用java.lang.ref.SoftReference类实现 一般用来做缓存 内存够用 不回收 不够用就回收
使用场景：
假如一个应用需要读取大量的本地图片： -
如果每次读取图片都从硬盘读取，则会严重影响性能
-
如果一次性全部加载到内存中，有可能造成内存溢出
此时，可以使用软引用解决这个问题
设计思路：
用一个hashmap来保存图片的路径和相应图片对象关联的软引用之间的映射关系，在内存不足时，JVM会自动回收这些缓存图片对象所占用的空间，从而有效的避免OOM的问题。
Map<String,SoftReference> imageCache = new HashMap<String,SoftReference>();
弱引用
在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。需要用java.lang.ref.WeakReference类实现
虚引用
“虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。
虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列 （ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。
垃圾收集器的种类
-
串行垃圾回收器
一个单线程的收集器，在进行垃圾收集时候，必须暂停其他所有的工作线程直到它收集结束。不适合服务器环境。 -
并行垃圾回收器
指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。适用于科学计算，大数据处理等与前端弱交互的场景 -
并发垃圾收集器
指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替进行），不需要停顿用户线程，适用于互联网公司，对响应时间有要求 -
G1垃圾收集器
在G1中，堆被划分成 许多个连续的区域(region)。采用G1算法进行回收，吸收了CMS收集器特点。
特点：支持很大的堆，高吞吐量 -
支持多CPU和垃圾回收线程
-
在主线程暂停的情况下，使用并行收集
-
在主线程运行的情况下，使用并发收集
实时目标：可配置在N毫秒内最多只占用M毫秒的时间进行垃圾回收 通过JVM参数 -XX:+UseG1GC 使用G1垃圾回收器 -
查看服务器默认的垃圾收集器
JVM参数：java -XX:+PrintCommandLineFlags -version -
7个垃圾收集器
-
参数预先声明
- DefNew : Default New Generation
- Tenured : old
- ParNew : Parallel new Generation
- PSYoungGen : Parallel Scavenge
- ParOldGen : Parallel Old Generation
- 新生代GC之Serial收集器
Serial 收集器是最基本、发展历史最悠久的收集器，曾经(在JDK 13.1之前)是虚拟机新生代收集的唯一选择。 大家看名字就会知道，这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅说明它只会使用个CPU 或条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束CSopThe World"这个名字也许听起来很酷，但这项工作实际上是由虚拟机在后台自动发起和自动完成的，在用户不可见的情况下把用户正常工作的线程全部停掉，这对很多应用来说都是难以接受的
对应的JVM参数：-XX:+UseSerialGC
开启后会使用Serial(Young区用)+Serial Old(Old区用)的收集器组合
表示：新生代 老年代都会使用串行回收收集器，新生代使用复制算法，老年代使用标记-整理算法
-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseSerialGC
- 新生代GC之ParNew收集器
ParNew垃圾收集器是Serial收集器的多线程版本 ，会STW暂停其他所有的工作线程直到他收集结束
最常见的应用场景，是配合老年代的CMS GC工作，其余的行为和Serial收集器完全一样，ParNew垃圾收集器在垃圾收集过程中，同样也要暂停其他的工作线程，他是很多Java虚拟机运行在server模式下新生代默认的垃圾收集器。
JVN参数：-XX:+UseParNewGC 启用ParNew收集器，只影响新生代的收集，不影响老年代
开启后：young区：ParNew + old区：Serial old 新生代使用复制算法，老年代使用标记-整理算法
-XX:ParallelGCThreads：指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU的数量相同
警告：Using the ParNew young collector with the Serial old collector is deprecated and will likely beremoved in a future release
-Xms10m -Xmx10m -XX:+PrintGCDetails -XX:+PrintCommandLineFlags -XX:+UseParNewGC
扫一扫
1635
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
