JVM口述JVM的组成首先JVM的组成分为几大块类加载器运行时数据区执行引擎本地方法接口然后运行时数据区又分为方法区栈堆程序计数器本地方法栈。首先是类加载器它负责帮我们的class文件加载到JVM当中去它又分为启动类加载器主要是加载jdk里的包扩展类加载器主要加载jdk一些扩展类jar包应用类加载器主要加载我们写的java代码跟引入的相关依赖自定义类加载器。提到了类加载器它有一个双亲委派机制和沙箱安全机制简单来说就是类加载器加载文件的时候会先看他的父类有没有加载过如果加载过就不会在加载了。这样就保证了我们系统的安全性跟类的唯一性。其次是方法区它是所有线程共享的存的主要是类信息、常量、静态变量、即时编译后的代码然后就是栈它是我们方法执行的一个容器遵循先进后出的原则。还有就是本地方法栈它主要是一些调用native修饰的方法进栈主要是调用一些操作系统层面的语言c/c 比如说开启一个新的线程然后就是堆堆的话就是我们对象存储的地方它又分为新生代和老年代新生代又分为eden区和幸存者0和幸存者1 内存比例主要是8:1:1一个初始的对象都会先进入eden区然后在经历一次垃圾回收之后就会到幸存者0区幸存者0区垃圾回收又回到幸存者1区反复15次以后的对象都没有被垃圾回收的话就会进入我们的老年代新生代的gc又叫yangGc老年代的gc叫fullGc。我们在应用开发和监控的时候应该避免频繁的fullGc。这里gc的算法有复制算法标记清除法标记整理法。gc的类型有parallelGc serialGc CMS G1 ZGc。程序计数器主要是线程上下文切换的时候由于主要记录的是我们线程执行到哪了提到JVM它里面分为了很多块…1.我们的类加载器是我们JVM的入口负责把我们的class文件写入到jvm内存里面去到方法区形成大CLASS对象链接-为类对象分配内存,并设置类变量的默认初始值,final修饰的变量在编译的时候就初始化好了,这时会给其赋值。初始化-就是执行类构造器方法classinit 主要是给类变量初始化值。2. 执行引擎是我们jvm的出口他负责jvm与我们操作系统的交互。3. 方法区主要是存放类的信息然后就是我们本地方法栈(里面存储着java执行不了的方法用native修饰)和本地方法接口(这里指的是操作系统的接口)调用过程中如果需要第三方类库的支持那么久需要本地方法库。那么我们的java栈就是存储我们的实例的引用8种数据类型方法进栈。栈里面有个程序计数器(主要是记录栈里方法出栈下一个执行什么方法)。方法区和堆看下面详细介绍。类加载器优先级1~4Bootstrap Classloader : 启动类加载器,用来加载 %JAVA_HOME%/jre/lib 下的rt.jar中的class文件 或者 xbootclassoth选项指定的jar包Extension Classloader : 扩展类加载器 , 用来加载 %JAVA_HOME%/jre/lib/*.jar 中的class文件 或者 -Djava.ext.dirs指定目录下的jar包Application Classloader : 应用类加载器 , 用来加载classpath下的class文件Custom Classloader : 用户自定义类加载器,用来加载自定义内容.此加载器需要用户自己继承Classloader类双亲委派机制:当某个类加载器需要加载某个.class文件时它首先把这个任务委托给他的上级类加载器递归这个操作如果上级的类加载器没有加载自己才会去加载这个类。作用:1、防止重复加载同一个.class。通过委托去向上面问一问加载过了就不用再加载一遍。保证数据安全。2、保证核心.class不能被篡改。通过委托方式不会去篡改核心.clas即使篡改也不会去加载即使加载也不会是同一个.class对象了。不同的加载器加载同一个.class也不是同一个Class对象。这样保证了Class执行安全。沙箱安全机制沙箱安全机制是基于双亲委派机制的前提下 String 的类,由于双亲委派机制的原理,此请求会先交给启动类加载器尝试加载,但是Bootstrap在加载类时首先通过包和类名查找rt.jar中有没有该类,有则优先加载rt.jar包中的类,因此就保证了java的运行机制不会被破坏.方法区方法区是被所有的线程共享所有定义方法的信息都保存在该区域此区属于共享区间。静态变量常量类信息构造方法/接口定义运行时常量池存在方法区中 but 实例变量存在堆内存中和方法区无关栈先进后出每个线程有独立的栈。他的生命周期跟随我们线程的生命周期8种基本类型的变量对象引用的变量实例方法都是在函数的栈内存中分配。StackOverflowerError本地方法栈:主要是jvm执行不了的方法 在们的代码中用native标记的方法只有声明却没有实现方法这时就到我们本地方法栈中通过调用本地方法接口执行方法(c语言实现的第三方函数库)。如我们的开启线程就是这样子实现的。程序计数器里面记录着我们栈里面方法调用和执行的情况类似于我们的一个排班表。堆一个JVM里面只有一个堆内存堆内存的大小是可以调节的我们的类加载器读取了类文件后需要把类方法常态量放到堆内存中保存所有引用类型的真实信息以方便执行器执行堆内存分为三个部分 1.新生区Eden,S0,S1三个区 8:1:1的比例大概 2.养老区 3.永久区(就是我们的方法区) 默认堆内存 内存/64。 最大 内存/4有关GC当经过一定次数(默认是15次)的GC会从新生区转移到老年区。当养老区的内存满的话就会在进行一次Full GC 还是内存满的话就会抛出OutOfMemoryError**jvm常用的参数**OutOfMemoryError:java heap space1.调整堆内存的大小 通过参数 -Xms.Xmx来调整如-Xms1024m -Xmx1024m -XX:printGCDetails初始化容量大小为1G 最大为1G 并打印分配的详细信息。2.代码中创建了大量的大对象并且长时间存在被引用不能被GC回收GC垃圾回收常见垃圾回收的算法引用计数(一般不用) 较难处理循环引用。复制 (伊甸区-幸存者0-幸存者1) 有一部分内存空间始终不能被使用标记清除有大片的内存碎片标记整理 Java堆中老年代的垃圾回收算法内存没有随便化清理完比较规整三色标记法 用可达性分析算法把对象分为几种颜色。主要是CMS垃圾回收器使用白色没碰过灰色我看过你但你的小弟还没看完黑色我和你的小弟全部看完如何定位对象是否需要被回收1.引用计数法(有弊端) 有变量指向对象 则计数1 但是对象之间变量的循环引用无法记录。存在内存泄露的问题2.可达性分析算法将“GC Roots” 对象作为起点从这些节点开始向下搜索引用的对象找到的对象都标记为非垃圾对象其余未标记的对象都是垃圾对象GC Roots根节点线程栈的本地变量、静态变量、本地方法栈的变量等等打破双亲委派机制自己建一个类加载器 集成ClassLoad重写loadClass方法把双亲委派那段代码删了然后改良一下沙箱安全机制逃逸分析如果一个方法里的对象 没有返回。那么这个对象不会分配在堆空间而是分配在栈空间随着方法的结束这个对象也就销毁了TLAB堆空间内多个线程并发分配地址会产生阻塞问题。1.首先TLAB是线程缓冲区每个线程都有Thread-local allocation buffer。默认设定为占用Eden Space的1%。在Java程序中很多对象都是小对象且用过即丢它们不存在线程共享也适合被快速GC所以对于小对象通常JVM会优先分配在TLAB上并且TLAB上的分配由于是线程私有所以没有锁开销。因此在实践中分配多个小对象的效率通常比分配一个大对象的效率要高。2.如果遇到大对象 在线程缓冲区里放不下。那么就会用cas的方法为这个对象分配内存空间。为什么要指针压缩堆内存越大越好吗1.在64位平台的HotSpot中使用32位指针内存使用会多出1.5倍左右使用较大指针在主内存和缓存之间移动数据占用较大宽带同时GC也会承受较大压力2.为了减少64位平台下内存的消耗启用指针压缩功能3.在jvm中32位地址最大支持4G内存(2的32次方)可以通过对对象指针的压缩编码、解码方式进行优化使得jvm只用32位地址就可以支持更大的内存配置(小于等于32G)4.堆内存小于4G时不需要启用指针压缩jvm会直接去除高32位地址即使用低虚拟地址空间5.堆内存大于32G时压缩指针会失效会强制使用64位(即8字节)来对java对象寻址这就会出现1的问题所以堆内存不要大于32G为好G1 垃圾回收器初始标记STW标记 GC Roots 直接可达对象。并发标记用户线程与 GC 并发遍历对象图采用三色标记 SATB 原始快照解决漏标。重新标记STW修正并发阶段引用变化。筛选回收拷贝✅STW。根据停顿预期挑选垃圾最多的 Region把存活对象复制拷贝到空闲 Region。JAVA_MEM_OPTS“-server-Xms4096M-Xmx4096M-XX:UseG1GC-XX:MaxGCPauseMillis200-XX:ParallelGCThreads2-XX:-OmitStackTraceInFastThrow-XX:UnlockExperimentalVMOptions-XX:UnlockDiagnosticVMOptions-XX:PrintGCDetails-XX:PrintAdaptiveSizePolicy-XX:PrintGCDateStamps-XX:PrintReferenceGC-XX:HeapDumpOnOutOfMemoryError-XX:HeapDumpPathlogdir/javaHeapDump.hprof−verbose:gc−Xloggc:{log_dir}/java_HeapDump.hprof -verbose:gc -Xloggc:logd​ir/javaH​eapDump.hprof−verbose:gc−Xloggc:{log_dir}/gc.log”