JVM内存模型
线程独占:栈,本地方法栈,程序计数器
线程共享:堆,方法区
栈
方法栈,线程私有的,线程执行方法是都会创建一个栈阵,用来存储局部变量表,操作栈,动态链接,方法 出口等信息.调用方法时执行入栈,方法返回式执行出栈.
使用jclasslib工具可以查看class类文件的结构。
栈的大小可以是固定的，或者是动态扩展的。如果请求的栈深度大于最大可用深度，则抛出 stackOverflowError;如果栈是可动态扩展的，但没有内存空间支持扩展，则抛出 OutofMemoryError。
本地方法栈
与栈类似,也是用来保存执行方法的信息.执行Java方法是使用栈,执行Native方法时使用本地方法栈.
程序计数器
保存着当前线程执行的字节码位置,每个线程工作时都有独立的计数器,只为执行Java方法服务,执行 Native方法时,程序计数器为空.
堆
JVM内存管理最大的一块,对被线程共享,目的是存放对象的实例,几乎所欲的对象实例都会放在这里,当堆 没有可用空间时,会抛出OOM异常.根据对象的存活周期不同,JVM把对象进行分代管理,由垃圾回收器进行 垃圾的回收管理
若堆的空间不够实例分配，则 OutOfMemoryError。
方法区(1.8以后为元空间)
又称非堆区,用于存储已被虚拟机加载的类信息,常量,静态变量,即时编译器优化后的代码等数据.1.7的永久代和1.8的元空间都是方法区的一种实现
JVM 内存可见性
JMM是定义程序中变量的访问规则,线程对于变量的操作只能在自己的工作内存中进行,而不能直接对主 内存操作.由于指令重排序,读写的顺序会被打乱,因此JMM需要提供原子性,可见性,有序性保证.
类加载与卸载
加载过程
其中验证,准备,解析合称链接
- 加载：通过类的完全限定名,查找此类字节码文件,利用字节码文件创建Class对象.
- 验证：确保Class文件符合当前虚拟机的要求,不会危害到虚拟机自身安全.
- 准备：进行内存分配,为static修饰的类变量分配内存,并设置初始值(0或null).不包含final修饰的静态变量, 因为final变量在编译时分配.
- 解析：将常量池中的符号引用替换为直接引用的过程.直接引用为直接指向目标的指针或者相对偏移量等.
- 初始化：主要完成静态块执行以及静态变量的赋值.先初始化父类,再初始化当前类.只有对类主动使用时才会初始化.
触发条件包括,创建类的实例时,访问类的静态方法或静态变量的时候,使用Class.forName反射类的时候,
或者某个子类初始化的时候. Java自带的加载器加载的类,在虚拟机的生命周期中是不会被卸载的,只有用户自定义的加载器加载的类才可以被卸.
加载机制-双亲委派模式
双亲委派模式,即加载器加载类时先把请求委托给自己的父类加载器执行,直到顶层的启动类加载器.父类加载器能够完成加载则成功返回,不能则子类加载器才自己尝试加载.*
优点:
- 避免类的重复加载
- 避免Java的核心API被篡改
|
输出结果//输出结果
Exception in thread "main" java.lang.SecurityException: Prohibited package name: java.lang
ClassLoader
所有的类加载器（除了根类加载器）都必须继承java.lang.ClassLoader。它是一个抽象类，主要的方法如下：
- loadClass：这里就是双亲委托模式的代码实现。只有父类加载器加载不到类时，会调用findClass方法进行类的查找，所以，在定义自己的类加载器时，不要覆盖掉该方法，而应该覆盖掉findClass方法。
- findClass：在自定义类加载器时，一般我们需要覆盖这个方法，且ClassLoader中给出了一个默认的错误实现。
- defineClass：用来将byte字节解析成虚拟机能够识别的Class对象。defineClass()方法通常与findClass()方法一起使用。在自定义类加载器时，会直接覆盖ClassLoader的findClass()方法获取要加载类的字节码，然后调用defineClass()方法生成Class对象。
- resolveClass：连接指定的类，类加载器可以使用此方法来连接类。
URLClassLoader
JDK提供了一个更加易用的类加载器URLClassLoader，它扩展了ClassLoader，能够从本地或者网络上指定的位置加载类。我们可以使用该类作为自定义的类加载器使用。
public URLClassLoader(URL[] urls): 指定要加载的类所在的URL地址，父类加载器默认为系统类加载器。public URLClassLoader(URL[] urls, ClassLoader parent)：指定要加载的类所在的URL地址，并指定父类加载器。
自定义类加载器
我们如果需要自定义类加载器，只需要继承ClassLoader类，并覆盖掉findClass方法即可。public class MyFileClassLoader extends ClassLoader {
private String directory;//被加载的类所在的目录
/**
* 指定要加载的类所在的文件目录
* @param directory
*/
public MyFileClassLoader(String directory,ClassLoader parent){
super(parent);
this.directory = directory;
}
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
//把类名转换为目录
String file = directory+File.separator+name.replace(".", File.separator)+".class";
//构建输入流
InputStream in = new FileInputStream(file);
//存放读取到的字节数据
ByteArrayOutputStream baos = new ByteArrayOutputStream();
byte buf[] = new byte[1024];
int len = -1;
while((len=in.read(buf))!=-1){
baos.write(buf,0,len);
}
byte data[] = baos.toByteArray();
in.close();
baos.close();
return defineClass(name,data,0,data.length);
} catch (IOException e) {
throw new RuntimeException(e);
}
}
public static void main(String[] args) throws Exception {
MyFileClassLoader myFileClassLoader = new MyFileClassLoader("d:/");
Class clazz = myFileClassLoader.loadClass("com.itheima.Demo");
clazz.newInstance();
}
}
类的显式与隐式加载
类的加载方式是指虚拟机将class文件加载到内存的方式。
- 显式加载是指在java代码中通过调用ClassLoader加载class对象，比如Class.forName(String name)；this.getClass().getClassLoader().loadClass()加载类。
- 隐式加载指不需要在java代码中明确调用加载的代码，而是通过虚拟机自动加载到内存中。比如在加载某个class时，该class引用了另外一个类的对象，那么这个对象的字节码文件就会被虚拟机自动加载到内存中。
线程上下文类加载器
在Java中存在着很多的服务提供者接口SPI，全称Service Provider Interface，是Java提供的一套用来被第三方实现或者扩展的API，这些接口一般由第三方提供实现，常见的SPI有JDBC、JNDI等。这些SPI的接口（比如JDBC中的java.sql.Driver）属于核心类库，一般存在rt.jar包中，由根类加载器加载。
而第三方实现的代码一般作为依赖jar包存放在classpath路径下，由于SPI接口中的代码需要加载具体的第三方实现类并调用其相关方法，SPI的接口类是由根类加载器加载的，Bootstrap类加载器无法直接加载位于classpath下的具体实现类。
由于双亲委派模式的存在，Bootstrap类加载器也无法反向委托AppClassLoader加载SPI的具体实现类。在这种情况下，java提供了线程上下文类加载器用于解决以上问题。
线程上下文类加载器可以通过java.lang.Thread的getContextClassLoader()来获取，或者通过setContextClassLoader(ClassLoader cl)来设置线程的上下文类加载器。如果没有手动设置上下文类加载器，线程将继承其父线程的上下文类加载器，初始线程的上下文类加载器是系统类加载器（AppClassLoader），在线程中运行的代码可以通过此类加载器来加载类或资源。
显然这种加载类的方式破坏了双亲委托模型，但它使得java类加载器变得更加灵活。
我们以JDBC中的类为例做一下说明。在JDBC中有一个类java.sql.DriverManager，它是rt.jar中的类，用来注册实现了java.sql.Driver接口的驱动类，而java.sql.Driver的实现类一般都是位于数据库的驱动jar包中的。
分代回收
分代回收基于两个事实:大部分对象很快就不使用了,还有一部分不会立即无用,但也不会持续很长时间.
| 堆分代 | |||
|---|---|---|---|
| 年轻代 | Dden | Survivor1 | Survivor2 |
| 老年代 | Tenured | Tenured | Tenured |
| 永久代 | Prem/MetaSpcae | Prem/MetaSpcae | Prem/MetaSpcae |
回收算法
1.G1算法
1.9后默认的垃圾回收算法,特点保持高回收率的同时减少停顿.采用每次只清理一部分,而不是清理全部的 增量式清理,以保证停顿时间不会过长
其取消了年轻代与老年代的物理划分,但仍属于分代收集器,算法将堆分为若干个逻辑区域(region),一部分 用作年轻代,一部分用作老年代,还有用来存储巨型对象的分区.
同CMS相同,会遍历所有对象,标记引用情况,清除对象后会对区域进行复制移动,以整合碎片空间.
年轻代回收:并行复制采用复制算法,并行收集,会StopTheWorld.
老年代回收:会对年轻代一并回收
初始标记完成堆root对象的标记,会StopTheWorld.
并发标记 GC线程和应用线程并发执行.
最终标记完成三色标记周期,会StopTheWorld.
复制/清楚会优先对可回收空间加大的区域进行回收
2.ZGC算法
前面提供的高效垃圾回收算法,针对大堆内存设计,可以处理TB级别的堆,可以做到10ms以下的回收停顿时间.
什么时候会触发FullGC
-
除直接调用System.gc外，触发Full GC执行的情况有如下四种。
1. 旧生代空间不足
旧生代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误:java.lang.OutOfMemoryError: Java heap space 为避免以上两种状况引起的FullGC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。
2. Permanet Generation空间满
PermanetGeneration中存放的为一些class的信息等，当系统中要加载的类、反射的类和调用的方法较 多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下会执行Full GC。如果经 过Full GC仍然回收不了，那么JVM会抛出如下错误信息:java.lang.OutOfMemoryError: PermGen space为避免Perm Gen占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。
3. CMS GC时出现promotion failed和concurrent mode failure
对于采用CMS进行旧生代GC的程序而言，尤其要注意GC日志中是否有promotion failed和concurrent mode failure两种状况，当这两种状况出现时可能会触发Full GC。
promotionfailed是在进行Minor GC时，survivor space放不下、对象只能放入旧生代，而此时旧生代 也放不下造成的;concurrent mode failure是在执行CMS GC的过程中同时有对象要放入旧生代，而此 时旧生代空间不足造成的。 应对措施为:增大survivorspace、旧生代空间或调低触发并发GC的比率，但在JDK 5.0+、6.0+的版本 中有可能会由于JDK的bug29导致CMS在remark完毕后很久才触发sweeping动作。对于这种状况，可 通过设置-XX:CMSMaxAbortablePrecleanTime=5(单位为ms)来避免。
4. 统计得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间
这是一个较为复杂的触发情况，Hotspot为了避免由于新生代对象晋升到旧生代导致旧生代空间不足的 现象，在进行Minor GC时，做了一个判断，如果之前统计所得到的Minor GC晋升到旧生代的平均大小 大于旧生代的剩余空间，那么就直接触发Full GC。 例如程序第一次触发MinorGC后，有6MB的对象晋升到旧生代，那么当下一次Minor GC发生时，首先 检查旧生代的剩余空间是否大于6MB，如果小于6MB，则执行Full GC。 当新生代采用PSGC时，方式稍有不同，PS GC是在Minor GC后也会检查，例如上面的例子中第一次 Minor GC后，PS GC会检查此时旧生代的剩余空间是否大于6MB，如小于，则触发对旧生代的回收。 除了以上4种状况外，对于使用RMI来进行RPC或管理的Sun JDK应用而言，默认情况下会一小时执行一 次Full GC。可通过在启动时通过- java-Dsun.rmi.dgc.client.gcInterval=3600000来设置Full GC执行的 间隔时间或通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。
JVM加载class文件的原理机制
- 当Java程序需要使用某个类时，JVM会确保这个类已经被加载、连接(验证、准备和解析)和初始化。类的加载是指把类的.class文件中的数据 读入到内存中，通常是创建一个字节数组读入.class文件，然后产生与所加载类对应的Class对象。加载 完成后，Class对象还不完整，所以此时的类还不可用。
- 当类被加载后就进入连接阶段，这一阶段包括 验证、准备(为静态变量分配内存并设置默认的初始值)和解析(将符号引用替换为直接引用)三个步骤。
- 最后JVM对类进行初始化，包括:1)如果类存在直接的父类并且这个类还没有被初始化，那么就先 初始化父类;2)如果类中存在初始化语句，就依次执行这些初始化语句。
- 类的加载是由类加载器完成的,类的加载首先请求父类加载器加载，父类加载器 无能为力时才由其子类加载器自行加载。
Java对象创建过程
- JVM遇到一条新建对象的指令时首先去检查这个指令的参数是否能在常量池中定义到一个类的符号引用。然后加载这个类(类加载过程在后边讲)
- 为对象分配内存。一种办法“指针碰撞”、一种办法“空闲列表”，最终常用的办法“本地线程缓冲分配(TLAB)”
- 将除对象头外的对象内存空间初始化为0
- 对对象头进行必要设置
类的生命周期
- 加载，查找并加载类的二进制数据，在Java堆中也创建一个java.lang.Class类的对象
- 连接，连接又包含三块内容:验证、准备、初始化。
- 1)验证，文件格式、元数据、字节码、符号 引用验证;
- 2)准备，为类的静态变量分配内存，并将其初始化为默认值;
- 3)解析，把类中的符 号引用转换为直接引用
- 初始化，为类的静态变量赋予正确的初始值
- 使用，new出对象程序中使用
- 卸载，执行垃圾回收
Java的对象结构
Java对象由三个部分组成:对象头、实例数据、对齐填充。
- 对象头由两部分组成，第一部分存储对象自身的运行时数据:哈希码、GC分代年龄、锁标识状态、线 程持有的锁、偏向线程ID(一般占32/64 bit)。第二部分是指针类型，指向对象的类元数据类型(即对 象代表哪个类)。如果是数组对象，则对象头中还有一部分用来记录数组长度。
- 实例数据用来存储对象真正的有效信息(包括父类继承下来的和自己定义的)
- 对齐填充:JVM要求对象起始地址必须是8字节的整数倍(8字节对齐)
垃圾收集算法
GC最基础的算法有三种: 标记 -清除算法、复制算法、标记-压缩算法，我们常用的垃圾回收器一般都采用分代收集算法。
- 标记 -清除算法，“标记-清除”(Mark-Sweep)算法，如它的名字一样，算法分为“标记”和“清除”两 个阶段:首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。
- 复制算法，“复制”(Copying)的收集算法，它将可用内存按容量划分为大小相等的两块，每次只 使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已 使用过的内存空间一次清理掉。
- 标记-压缩算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清 理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存
- 分代收集算法，“分代收集”(Generational Collection)算法，把Java堆分为新生代和老年代，这 样就可以根据各个年代的特点采用最适当的收集算法。
调优命令
- jps，JVM Process Status Tool,显示指定系统内所有的HotSpot虚拟机进程。
- jstat，JVM statistics Monitoring是用于监视虚拟机运行时状态信息的命令，它可以显示出虚拟机 进程中的类装载、内存、垃圾收集、JIT编译等运行数据。
- jmap，JVM Memory Map命令用于生成heap dump文件
- jhat，JVM Heap Analysis Tool命令是与jmap搭配使用，用来分析jmap生成的dump，jhat内置了 一个微型的HTTP/HTML服务器，生成dump的分析结果后，可以在浏览器中查看
- jstack，用于生成java虚拟机当前时刻的线程快照。
- jinfo，JVM Configuration info 这个命令作用是实时查看和调整虚拟机运行参数。
调优工具
常用调优工具分为两类,jdk自带监控工具:jconsole和jvisualvm，第三方有:MAT(Memory Analyzer Tool)、GChisto。
- jconsole，Java Monitoring and Management Console是从java5开始，在JDK中自带的java监控 和管理控制台，用于对JVM中内存，线程和类等的监控
- jvisualvm，jdk自带全能工具，可以分析内存快照、线程快照;监控内存变化、GC变化等。
- MAT，Memory Analyzer Tool，一个基于Eclipse的内存分析工具，是一个快速、功能丰富的Java heap分析工具，它可以帮助我们查找内存泄漏和减少内存消耗
- GChisto，一款专业分析gc日志的工具
JVM性能调优
设定堆内存大小
- -Xmx:堆内存最大限制。
设定新生代大小。 新生代不宜太小，否则会有大量对象涌入老年代 - -XX:NewSize:新生代大小
- -XX:NewRatio 新生代和老生代占比
- -XX:SurvivorRatio:伊甸园空间和幸存者空间的占比
设定垃圾回收器 年轻代用
- -XX:+UseParNewGC
年老代用
- -XX:+UseConcMarkSweepGC
PermSpace 和 MetaSpace
-
JDK 1.8后用元空间替代了 Perm Space;字符串常量存放到堆内存中。
MetaSpace大小默认没有限制，一般根据系统内存的大小。JVM会动态改变此值。
- -XX:MetaspaceSize:分配给类元数据空间(以字节计)的初始大小(Oracle逻辑存储上的初始高水位，the initial high-water-mark)。此值为估计值，MetaspaceSize的值设置的过大会延长垃圾回收时间。垃圾回收过后，引起下一次垃圾回收的类元数据空间的大小可能会变大。
- -XX:MaxMetaspaceSize:分配给类元数据空间的最大值，超过此值就会触发Full GC，此值默认没有限制，但应取决于系统内存的大小。JVM会动态地改变此值。