jvm面试大全

类的加载过程

类加载器分为三种

引导类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如 rt.jar、charsets.jar等，c语言实现的引导类加载器

扩展类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR 类包 应用程序类加载器：负责加载ClassPath路径下的类包，主要就是加载你自己写的那 些类 自定义加载器：负责加载用户自定义路径下的类包

c语言创建引导类加载器 然后通过引导类加载器 把扩展类加载器和应用程序类加载器创建出来

最后通过应用程序类加载器吧我们的类加载到jvm方法区中

对象创建过程

 

类加载检查

虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。

分配内存

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类 加载完成后便可完全确定，为对象分配空间的任务等同于把 一块确定大小的内存从Java堆中划分出来。

怎样去划分内存

“指针碰撞”（Bump the Pointer）(默认用指针碰撞) 如果Java堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离。 “空闲列表”（Free List） 如果Java堆中的内存并不是规整的，已使用的内存和空 闲的内存相互交错，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记 录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录

解决并发问题的内存分配

CAS

虚拟机采用CAS配上失败重试的方式保证更新操作的原子性来对分配内存空间的动作进行同步处理。

去做cas占用空间，如果失败了将重新获取指针位置再去通过cas做空间占用

本地线程分配缓冲

jvm默认使用的方法

为了避免线程争抢支援，会预先在Eden区中划分几个区域，线程一去一区域，线程二去二区域。

把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存。

如果当前线程所存放的区域存不下了，就会执行cas去Eden

初始化

内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头）

设置对象头

初始化零值之后，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头Object Header之中。

对象头包括两部分信息，第一部分用于存储对象自身的运行时数据， 如哈希码(HashCode)、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时 间戳等。对象头的另外一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

执行init方法

将成员变量赋值，和执行构造方法

java对象的指针压缩

.jdk1.6 update14开始，在64bit操作系统中，JVM支持指针压缩 默认开启

为什么要进行指针压缩？

为了减少64位平台下内存的消耗，假如再64位操作系统下不开启压缩指针 每个对象都是以64个字节也就是8个bit位存储，无形的给jvm堆内存增加了压力，如果堆内存没有大于32g，对于对象来说32字节就够用了，在jvm中，32位地址最大支持4G内存寻址(2的32次方) 堆内存小于4G时，不需要启用指针压缩，jvm会直接去除高32位地址，即使用低虚拟地址空间 可以通过对对象指针的压缩编码、解码方式进行优化，使得jvm 只用32位地址就可以支持更大的内存配置(小于等于32G)

对象内存分配

对象栈上分配

我们通过JVM内存分配可以知道JAVA中的对象都是在堆上进行分配，当对象没有被引用的时候，需要依靠GC进行回收内存，如果对象数量较多的时候，会给GC带来较大压力，也间接影响了应用的性能。为了减少临时对象在堆内分配的数量，JVM通过逃逸分析确定该对象不会被外部访问。如果不会逃逸可以将该对象在栈上分配内存，这样该对象所占用的内存空间就可以随栈帧出栈而销毁，就减轻了垃圾回收的压力。

对象逃逸分析：就是分析对象动态作用域，当一个对象在方法中被定义后，它可能被外部方法所引用，例如作为调用参数传递到其他地方中。

标量替换：通过逃逸分析确定该对象不会被外部访问，并且对象可以被进一步分解时，JVM不会创建该对象，而是将该对象成员变量分解若干个被这个方法使用的成员变量所代替，这些代替的成员变量在栈帧或寄存器上分配空间

标量与聚合量：标量即不可被进一步分解的量，而JAVA的基本数据类型就是标量（如：int，long等基本数据类型以及reference类型等），标量的对立就是可以被进一步分解的量，而这种量称之为聚合量。而在JAVA中对象就是可以被进一步分解的聚合量。

栈上分配依赖于逃逸分析和标量替换

栈中如果没有没有一大块连续空间导致对象内存不够分配 将会执行标量替换

大对象直接进入老年代

大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。

大到Eden区和s0和s1装不下 直接去老年代

JVM参数 -XX:PretenureSizeThreshold 可以设置大对象的大小，如果对象超过设置大小会直接进入老年代，不会进入年轻代

为了避免为大对象分配内存时的复制操作而降低效率。

长期存活的对象将进入老年代

既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这一点，虚拟机给每个对象一个对象年龄（Age）计数器。 如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor空间中，并将对象年龄设为1。对象在 Survivor 中每熬过一次 MinorGC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁，CMS收集器默认6岁，不同的垃圾收集器会略微有点不同），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。

为了避免对象分配内存时的复制操作而降低效率。

自己估算大概对象经过3次Minor GC就会被回收，没回收的大概会长期存在，可以设置分带年龄为8，减少分带

对象动态年龄判断

虚拟机并不是永远地要求对象的年龄必须达到了默认的15次才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor(s0，s1)空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到要求的年龄。

避免了设置过⼤的分代年龄导致⼤量对象⽆法晋升，survivor区占用率非常高了，但是就不晋升，导致明明老年代还有空间，但是对象就停留在年轻代

老年代空间分配担保机制

可以配置是否担保

年轻代每次minor gc之前JVM都会计算下老年代剩余可用空间如果这个可用空间小于年轻代里现有的所有对象大小之和(包括垃圾对象) 就会看看老年代的可用内存大小，是否大于之前每一次minor gc后进入老年代的对象的平均大小。如果小于就直接fullGc 从而减少minorGc后又fullGc的场景

对象内存回收

堆中几乎放着所有的对象实例，对堆垃圾回收前的第一步就是要判断哪些对象已经死亡（即不能再被任何途径使用的对象）。

引用计数法

给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加1；当引用失效，计数器就减1；任何时候计数器为0的对象就是不可能再被使用的。

这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间相互循环引用的问题。

可达性分析算法

将“GC Roots” 对象作为起点，从这些节点开始向下搜索引用的对象，找到的对象都标记为非垃圾对象，其余未标记的对象都是垃圾对象

如何将一个无用的类救活

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一

个对象死亡，至少要经历再次标记过程。

标记的前提是对象在进行可达性分析后发现没有与GC Roots相连接的引用链。

1. 第一次标记并进行一次筛选。

筛选的条件是此对象是否有必要执行finalize()方法。

当对象没有覆盖finalize方法，对象将直接被回收。

2. 第二次标记

如果这个对象覆盖了finalize方法，finalize方法是对象脱逃死亡命运的最后一次机会，如果对象要在finalize()中成功拯救自己，只要重新与引用链上的任何的一个对象建立关联即可，譬如把自己赋值给某个类变量或对象的成员变量，那在第二次标记时它将移除出“即将回收”的集合。如果对象这时候还没逃脱，那基本上它就真的被回收了。

注意：一个对象的finalize()方法只会被执行一次，也就是说通过调用finalize方法自我救命的机会就一次。

双亲委派机制

加载某个类时会先委托父加载器寻找目标类，找不到再委托上层父加载器加载，如果所有父加载器在自己的加载类路径下都找不到目标类，则重新向下去找

为什么要设计双亲委派机制？

沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样便可以防止核心 API库被随意篡改

因为首先是通过应用程序类加载器向上委托到扩展类加载器再向上委托到引导类加载器，引导类加载器就会去判断当前类是否被加载引导类没有被加载就去这个时候就会扫描到原生的String.class已经被加载了，从而不会加载自己定义的String类避免类的重复加载 保证被加载类的唯一性

为什么不直接从上至下加载

因为大部分要加载的包都是应用程序类加载器中的类，前期是需要麻烦点从上至下，到后面就只需要经过应用程序类加载器加载就可以了

打破双亲委派机制

可以自定义自己的双亲委派机制 重写loadClass 将自己不想委托给父加载器直接到自己定义的位置去找

比如tomcat就是打破了双亲委派机制使一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是 独立的，保证相互隔离。

部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程 序，那么要有10份相同的类库加载进虚拟机。

web容器也有自己依赖的类库，不能与应用程序的类库混淆。基于安全考虑，应该让容器的 类库和程序的类库隔离开来。

tomcat 为了实现隔离性，没有遵守双亲委派机制，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。自己war包没有的就向上去找

jvm内存模型

堆

堆分为 年轻代Eden区 和s0区 s1区 老年代；

当Eden区满了后会触发minorGC(麦了) 扫描Eden；将gcroot在使用的都放入s0中，然后将Eden区中的对象全部清空

当Eden区第二次满的时候会扫描Eden和s0 将gcroot在使用的Eden区和s0区在使用的都放入s1中，然后将Eden区和s0中的对象全部清空

默认迭代15次时还存活的对象进入老年代 当老年代满了后触发fullGc Full GC同时作用于新生代和老年代 再生产环境要避免频繁的fullGc 因为执行fullGc时会Stop-The-World(STW) Java将暂停所有其他的线程

jvm性能调优一般就是去减少gc 每次gc都会引起STW minorgc引起非常短，而fullgc会很长，在调优时尽量去减少fullgc的一个次数

JVM为什么要设计STW

如果不停止工作线程，那么是有可能有存活对象进入老年代的。这时候就要有预留的空间给这些存活对象。所以，老年代回收时，不是等老年代满了才回收的。比如我们预留了10%空间，那么老年代使用率达到90%的时候，就会进行垃圾回收(老年代垃圾回收的情况不止这种，比如还有老年代空间担保机制，也可能会触发垃圾回收的)。 另外，如果在垃圾回收的时候，有新存活对象进入老年代，并且总大小超过了10%时，这时候放不下了！要怎么办？这个时候，是会触发 Concurrent Mode Failure 的。就是回收失败。之后，就会退化为 Serial old 垃圾回收器进行回收。会停止工作线程。重新标记，再回收。

等等原因，这些底层收集垃圾的过程太复杂，所以直接停止

栈

当一个线程开始运行马上会在内存栈中分配一小块专属区域(线程栈)栈帧，用来放当前线程自己的局部变量，不同的线程有不同的栈，两个线程运行同一个方法内部的代码是互不干涉的；

栈帧中又有 程序计数器 局部变量表 操作数栈 动态链接 方法出口

程序计数器：记入当前线程所执行到的位置

局部变量表：当前方法存储的变量，值等

操作数栈：在程序运行过程中，做操作或者运算的一块零时的中转区

当执行int a = 1; 时 先将1压入操作数栈,然后再局部变量表中创建a,再将1从操作数栈中出栈 赋值给局部变量表中的a。

执行int c = (a + b) * 10； 时 先将a的值1入栈到操作数栈，再将b的值2放进去，然后操作数执行+号操作，操作数栈就只剩一个3，然后再将10入栈，进行相乘，操作数栈剩一个30，最后将30出栈赋值给c

动态链接： 将方法中的符号解析成地址 ( public对应什么地址或操作 int 对应什么 将符号去解析)

方法出口： main方法运行过去到compute()-栈帧中需要记录运行compute方法后回到main方法的什么地方

本地方法栈

用于java调用c语言的一个实现，比如调用某个java内部方法的时候，那个方法是由c语言实现，会由它的字节码引擎直接解析找到这个方法对应的xxx.dll文件，运行类型这种情况也是需要内存的，就会由本地方法栈中来运行。

方法区

与Java堆类似,是各个线程共享的内存区域。一般存放类信息

程序计数器

jvm是如何运行的

先将java文件编译成class字节码文件，然后通过类加载机制加载到方法区(元空间)，然后再java线程栈中开辟一块栈帧，字节码执行引擎执行到int i = 0；后将这一行代码的字节码通过解析执行器翻译成汇编指令，汇编指令转换成二进制码，交给cpu去执行，当这个线程被cpu调度到后执行，将i=0压入main方法栈帧中的操作数栈

垃圾回收算法

标记-复制算法

将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。

 

效率比下面两种快10倍

标记-清除算法

算法分为“标记”和“清除”阶段：标记存活的对象， 统一回收所有未被标记的对象(一般选择这种)；也可以反过来，标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象 。

1. 效率问题 (如果需要标记的对象太多，效率不高)

2. 空间问题（标记清除后会产生大量不连续的碎片）

 

标记-整理算法

标记出存活的对象，然后向一段整理，如果那个位置有垃圾对象，会直接覆盖

 

而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。

垃圾收集器

Serial收集器

3

这个收集器思路很简单 要收集垃圾的时候stw所有线程，然后单线程的去处理垃圾回收，完成后再取消stw

新生代采用复制算法，老年代采用标记-整理算法。

 

Parallel Scavenge收集器

派v楼

Parallel收集器其实就是Serial收集器的多线程版本 除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和Serial收集器类似

新生代采用复制算法，老年代采用标记-整理算法。

 

ParNew收集器

ParNew收集器其实跟Parallel收集器很类似，区别主要在于它可以和CMS收集器配合使用。

新生代采用复制算法，老年代采用标记-整理算法。

 

CMS收集器

整个收集的过程时间大于parallel收集器，因为并发收集的时候分了很多资源给用户线程；但是stw小于parallel收集器，并且stw还是拆分开来的，对于用户的体验是非常好的

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

初始标记： 暂停所有的其他线程(STW)，并记录下gc roots直接能引用的对象，速度很快。

并发标记： 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程， 这个过程耗时较长但是不需要停顿用户线程， 可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。 占整个垃圾收集过程百分之75左右

重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到三色标记里的增量更新算法(见下面详解)做重新标记。

并发清理： 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑 色不做任何处理(见下面三色标记算法详解)。

并发重置：重置本次GC过程中的标记数据。

 

缺点：

1.对CPU资源敏感（会和服务抢资源）；

2.无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)；

3.它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数

-XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理

4.执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并

发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent

mode failure"，此时会进入stop the world，用serial old垃圾收集器来回收

什么是三色标记

三色标记是用来标记不被清理的对象的，把gcroot通过可达分析算法向下去标记被应用的对象为黑色

黑色： 黑色的对象代表已经扫描 过， 它是安全存活的

灰色： 表示对象已经被垃圾收集器访问过， 但这个对象上至少存在一个引用还没有被扫描过。

白色： 表示对象尚未被垃圾收集器访问过。 显然在可达性分析刚刚开始的阶段， 所有的对象都是白色的， 若在分析结束的阶段， 仍然是白色的对象， 即代表不可达。

再并发清理的时候 又有垃圾进来默认为黑色

多标

标记gcroot当前不为垃圾，然后并发的去标记当前gcroot的子对象的时候，这个线程执行完毕当前为垃圾了，但是已经被标记成不为垃圾，这为浮动垃圾，下次gc的时候会处理

漏标

出现再并发阶段没有被标记的对象,本应该是被gc清理掉 但是某种情况又让这个对象指向了其他被黑色标记的对象

漏标会导致被引用的对象被当成垃圾误删除，这是严重bug，必须解决，有两种解决方案： 增量更新（IncrementalUpdate） 和原始快照（Snapshot At The Beginning，SATB） 。

增量更新：黑色对象一旦新插入了指向白色对象的引用之后， 它就变回灰色对象了 然后再重新标记阶段再次被扫描

其并发标记时对漏标的处理方案如下： CMS：写屏障 + 增量更新

读写屏障

写屏障

所谓的写屏障，其实就是指在赋值操作前后，加入一些处理（可以参考AOP的概念）：

写屏障实现增量更新

读屏障

G1收集器

G1将Java堆划分为多个大小相等的独立区域（Region【瑞均】）JVM最多可以有2048个Region。

​​​​​​​

 

一般Region大小等于堆大小除以2048

G1保留了年轻代和老年代的概念，但不再是物理隔阂了，它们都是（可以不连续）Region的集合。

G1解决了大对象直接进入老年代 G1有专门分配 大对象的Region叫Humongous区，而不是让大对象直接进入老年代的Region中。在G1中，大对象的判定规则就是一 个大对象超过了一个Region大小的50%而且一个大对象如果太大，可能会横跨多个Region来存放。 Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开销

初始标记（initial mark，STW）：暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快 ；

并发标记（Concurrent Marking）：同CMS的并发标记

最终标记（Remark，STW）：同CMS的重新标记

筛选回收（Cleanup，STW）：筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划

可以通过设置指定gc时间 如果指定的时间不足以回收所有垃圾 G1会优先挑选性价比高的Region区域去回收

不管是年轻代或是老年代，回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中

如果stw设置的时间不够回收要回收的所有的对象，g1会进行一个优先的回收算法，将region中存储较少的先回收，这样可以空出来的空间较多；假如有100个region要回收，其中一个region装满了回收需要200ms，这样就只能清理一块空间出来；其他99个region中只装了一点点对象，200ms计算以最多回收多个region来回收

可预测的停顿：这是G1相对于CMS的另一个大优势

什么场景适合使用G1

垃圾回收时间特别长，超过1秒

大对象较多的情况

每秒几十万并发的系统如何优化JVM

Kafka类似的支撑高并发消息系统大家肯定不陌生，对于kafka来说，每秒处理几万甚至几十万消息时很正常的，一般来说部署kafka需要用大内存机器(比如64G)，也就是说可以给年轻代分配个三四十G的内存用来支撑高并发处理，这里就涉及到一个问题了，我们以前常说的对于eden区的young gc是很快的，这种情况下它的执行还会很快吗？很显然，不可能，因为内存太大，处理还是要花不少时间的，假设三四十G内存回收可能最快也要几秒钟，按kafka这个并发量放满三四十G的eden区可能也就一两分钟吧，那么意味着整个系统每运行一两分钟就会因为young gc卡顿几秒钟没法处理新消息，显然是不行的。那么对于这种情况如何优化了，我们可以使用G1收集器，设置 -XX:MaxGCPauseMills 为50ms，假设50ms能够回收三到四个G内存，然后50ms的卡顿其实完全能够接受，用户几乎无感知，那么整个系统就可以在卡顿几乎无感知的情况下一边处理业务一边收集垃圾。

G1天生就适合这种大内存机器的JVM运行，可以比较完美的解决大内存垃圾回收时间过长的问题。

ZGC收集器

ZGC是一款JDK 11中新加入的

ZGC收集器是一款基于Region内存布局的， 暂时不设分代的， 颜色指针等技术来实现可并发的标记-整理算法的

颜色指针

ZGC的核心设计之一

以前的垃圾回收器的GC信息都保存在对象头中，而ZGC的GC信息保存在指针中。

无需进行对象访问就可以获得 GC 信息，这大大提高了 GC 效率

以前是需要通过指针找到对象，通过对象信息获取Gc信息，ZGC直接通过指针获取到Gc信息 但是颜色指针不支持指针压缩，简单来说颜色指针再64位环境下 ，将指针用不到的地方存储gc信息 适合高并发大内存的垃圾回收器

ZGC采用了完全不同的方案读屏障，这个是ZGC一个非常重要的特性。在标记和移动对象的阶段

如果程序再做读操作的时候对象在GC时被移动了，接下来JVM就会加上一个读屏障，这个屏障会把读出的指针更新到对象的新地址上，并且把堆里的这个指针“修正”到原本的字段里。这样就算GC把对象移动了，读屏障也会发现并修正指针，于是应用代码就永远都会持有更新后的有效指针，而且不需要STW。

利用颜色指针判断对象是否被移动过

ZGC触发时机

定时触发，默认为不使用，可通过ZCollectionInterval参数配置。 预热触发，最多三次，在堆内存达到10%、20%、30%时触发，主要时统计GC时间，为其他GC机制使用。

如何选择垃圾收集器

优先调整堆的大小让服务器自己来选择

如果响应时间最重要，并且不能超过1秒，使用并发收集器

4G以下可以用parallel，4-8G可以用ParNew+CMS，8G以上可以用G1，几百G以上用ZGC

JDK 1.8默认使用 Parallel(年轻代和老年代都是) JDK 1.9默认使用 G1

GC时机 ----- 安全点与安全区域

安全点就是指代码中一些特定的位置,当线程运行到这些位置时它的状态是确定的,这样JVM就可以安全的进行一些操作,比如GC等，所以GC不是想什么时候做就立即触发的，是需要等待所有线程运行到安全点后才能触发。 这些特定的安全点位置主要有以下几种:

1方法返回之前

2调用某个方法之后

3抛出异常的位置

jvm内存监控和问题排查

jdk bin目录下自带的jvisualvm(jvjvm) 有图形化界面

阿里巴巴开源的 Arthas(阿萨斯)

Jmap

此命令可以用来查看内存信息，实例个数以及占用内存大小 堆内存信息

jmap -histo 19752 > ./log.txt(当前目录导出这个内存信息) 此命令可以用来查看内存信息，实例个数以及占用内存大小

jmap -heap 19752 查看堆内存使用信息

jmap ‐dump:format=b,file=eureka.hprof 19752 将现在堆中的使用情况，导出一个快照 eureka.hprof 可以使用visualVM装入快照

Jstack

cpu飙升的查找问题的方法

用jstack加进程id查找死锁

jstack找出占用cpu最高的线程堆栈信息

Jinfo

查看jvm的参数

Jstat

jstat命令可以查看堆内存各部分的使用量，以及加载类的数量

比如年轻代老年代占用内存使用情况 元空间等 还有垃圾回收次数

年轻代对象增长的速率

Young GC的触发频率和每次耗时

每次Young GC后有多少对象存活和进入老年代

Full GC的触发频率和每次耗时

系统频繁Full GC导致系统卡顿是怎么回事

元空间不够导致的多余full gc

内存泄露到底是怎么回事

一般电商架构可能会使用多级缓存架构，就是redis加上JVM级缓存，大多数同学可能为了图方便对于JVM级缓存就简单使用一个hashmap，于是不断往里面放缓存数据，但是很少考虑这个map的容量问题，结果这个缓存map越来越大，一直占用着老年代的很多空间，时间长了就会导致full gc非常频繁，这就是一种内存泄漏，对于一些老旧数据没有及时清理导致一直占用着宝贵的内存资源，时间长了除了导致full gc，还有可能导致OOM。这种情况完全可以考虑采用一些成熟的JVM级缓存框架来解决，比如ehcache等自带一些LRU数据淘汰算法的框架来作为JVM级的缓存。

GC日志详解

java应用我们可以通过一些配置把程序运行过程中的gc日志全部打印出来，然后分析gc日志得到关键性指标，分析 GC原因，调优JVM参数。