jvm专栏

把新生代的内存区域分为2部分，然后只使用其中一块，待内存快满的时候，就把里面存活的对象转移到另一块内存区域，保证没有内存碎片，接着回收原来那块内存区域的垃圾对象，再次空出来一块内存区域，两块内存区域重复循环使用

缺点:内存使用率太低，每次只使用其中一半

复制算法优化

标记哪些对象是可以被垃圾回收的，直接对那块内存区域的对象进行回收

缺点：存活对象再内存区域一个东一个西，产生大量的内存碎片，内存浪费

产生的问题

1.首先标记出来老年代存活的对象，这些对象可能东一个西一个

2.把这个存活的对象再内存中移动，尽量挪到一边去，让存活对象紧凑的靠在一起，避免垃圾回收后产生内存碎片

对象每次再新生代里躲过一次GC被转移到一块S区，此时他的年龄就增长一岁，默认的设置下，当对象的年龄为15的时候就会进入老年代 jvm参数设置-XX:MaxTenuringThreshold

就是当前放对象的S区，一批对象的总大小大于了这块S区域的内存大小的50%，那么此时大于等于这批对象的年龄的对象就进入老年代

规则：年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区
域的50%，此时就会把年龄n以上的对象都放入老年代。

一次达到Survivor 100%不会立马触发动态年龄判定机制，需要下一次GC的时候看你还是超过Survivor 50%，才会进行动态年龄判定

实战：为了避免动态年龄判断把S区的对象直接进入老年代，如果新生代的内存有限，可以调整jvm参数"-
XX:SurvivorRatio=8" 默认Eden区80%，也可以降低Eden区的内存大小，给S区更多的内存，然后让每次Minor gc存活下来的对象进入S区

jvm参数

假设Minor Gc后，eden区有150M的存活对象，S区放不下，就直接进入老年代

原因

流程

jvm参数设置

1.再minor gc 之前，很可能Minor gc后要进入老年代的对象太多了，老年代放不下，此时需要提前进行full gc,然后再进行minor gc

2.再minor gc之后，存活的对象老年代放不下了

3.老年代可以设置一个阈值，一旦老年代内存使用达到这阈值，就会触发full gc

当新生代的Eden区和其中一个Survivor区空间不足时。

Serial回收年轻代，Seraial Old回收老年代

原理：单线程运行，垃圾回收的时候会停止我们系统的其他线程的工作，让我们的系统直接卡死，然后让他们垃圾回收，我们几乎不用

回收新生代，采用的是复制算法

流程：把Eden区的存活对象标记出来，全部转移到S1区，然后一次性清空Eden区的垃圾对象，当Eden区再次满的时候，触发minor gc, 去标记Eden区和S1区的存活对象，一次性转移到S2区，然后清空Eden区和S1区。

jvm参数

回收老年代，采用的是标记清除算法，会占用CPU资源

Concurrent Mode Failure问题

内存碎片问题

流程

可以同时回收新生代和老年代，算法性能更好 ， 特点就是把java堆内存拆分成多个大小相等的region,最大的特点就是设置垃圾回收预期停顿时间。其实我们对内存合理分配和参数优化就是为了减少minor gc 和full gc,尽量减少gc带来的系统停顿，避免影响系统请求

parNew和cms的痛点：stop the world

默认新生代最多只能占据堆内存60%的Region

GC时机

在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%，比如按照上面算的，每个Region是2MB，只要一个大对象超过了1MB，就会被放入大对象专门的Region中。而且一个大对象如果太大，可能会横跨多个Region来存放

核心设计思路

流程

再垃圾回收的时候，尽可能的让垃圾回收器专心致志的工作，不能随便让我们的系统再创建新的对象，所以此时jvm会再后台进入 stop the world 状态，这样的话我们系统暂停运行，不再创建新的对象，同时就是让垃圾回收线程尽快完成垃圾回收工作，一旦垃圾回收完毕，就可以继续恢复我们系统的运行了

首先你的代码中包含“main()”方法的主类一定会在JVM进程启动之后被加载到内存，开始执行你的“main()”方法中
的代码。接着遇到你使用了别的类，比如“ReplicaManager”，此时就会从对应的“.class”字节码文件加载对应的类到内存里来。

就是根据java虚拟机的规范，来校验你加载进来的class文件内容是否符合指定的规范。如果你的class文件被人篡改，jvm是没法执行的，所以加载.class文件到内存后，必须先验证一下，然后才能交给jvm运行

其实就是给这个ReplicaManager分配内存，然后给static修饰的变量(类变量)赋默认的初始值

符合引用替换成直接引用的过程

再这个阶段，就会执行类的初始化代码，准备的阶段的时候只是分配的内存和给个初始值0，初始化阶段是完成配置项的读取，然后在赋值。如果发现父类还没加载和初始化，先加载父类和初始化父类然后再初始化子类

它负责加载我们机器安装的java目录下的核心类，一旦jvm启动，首先会依托启动类加载器去加载你java目录下的lib目录中的核心类库

你的java目录有一个lib\ext目录，里面有写类是需要这个加载器加载的，支撑你的系统运行

这个加载器是负责加载指定classpth环境变量所指定的路径中的类。大概就是去加载你写好的代码，这个加载器就负责把你写好的代码加载到内存中

根据你自己的需求去加载类

jvm的加载器是有亲子层级的，第一层是启动类加载器，第二层是扩展类加载器，第三层是应用类加载器，自定义加载器再最下层

流程：

好处:

存放各种类的信息

记录当前执行字节码指令的位置

保存每个方法的局部变量。如果线程执行了一个方法，就会对这个方法创建一个栈帧。栈帧包括局部变量表，操作数栈，动态链接，方法出口等等

存放创建的各种对象

1.jvm启动，先加载你的kafka类到内存，然后有个main方法，开始执行你的main方法，main线程的关联了程序计数器的，会记录你执行到哪一行指令

2.main线程再执行main方法的时候，会再main线程关联的java虚拟机栈里，会压入一个main方法的栈帧，接着发现需要创建ReplicaManger类的实例对象，会加载这个类到内存中。然后对象实例分配再堆内存中，并再main方法的栈帧的局部变量表引入一个replicaManager变量。让他引用ReplicaManager这个对象再堆内存中的地址

3.main线程就执行ReplicaManager中的方法，会依次把执行到的方法对应的栈帧压入自己的虚拟机栈，执行完之后再把对应方法的栈帧从java虚拟机栈中出栈

java堆内存大小

初始化堆大小

java堆内存的最大大小

java堆内存的新生代大小，扣除新生代的就是老年代的大小

永久代大小（方法区）1.8以后 -XX:MetaspaceSize

永久代最大大小 1.8以后 和-XX:MaxMetaspaceSize

每个线程的栈内存大小

打印详细的gc日志

打印每次gc发生的时间

指定垃圾回收器

指定使用G1垃圾回收器，此时会自动用堆大小除以2048

最大停顿时间 默认值是200ms

老年代使用了多少比例的内存，就开始full gc, 默认92%

每次full gc之后，都需要内存碎片整理

执行多少次Full GC之后再执行一次内存碎片整理的工作，默认
是0，意思就是每次Full GC之后都会进行一次内存整理。

最大分代年龄 ，默认15

大对象直接进入老年代

默认值是5%

他的默认值是85%，意思就是确定要回收的Region的时候，必须是存
活对象低于85%的Region才可以进行回收

再CMS垃圾回收的初始标记阶段开启多线程并发执行，减少stop the world时间

再CMS的重新标记阶段之前，先尽量执行一次young gc

好处：先执行一次young gc就会回收掉一些年轻代没有人引用的对象，那么再CMS重新标记阶段就可以少扫描一些对象，提示CMS重新标记阶段的性能，减少他的耗时

禁止显示执行gc .比如System.gc()

-Xms512M -Xmx512M -Xmn256M -Xss1M -XX:PermSize=128M -XX:MaxPermSize=128M

“-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:PermSize=256M -XX:MaxPermSize=256M -
XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M -XX:+UseParNewGC -
XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFaction=92 -XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSParallelinitialMarkEnabled -XX:+CMSScavengeBeforeRemark”

1个变量引用一个对象，只要是强引用对象，垃圾回收的时候绝对不会回收这个对象

1个对象被“SoftReference”软引用类型的对象包裹起来了。正常垃圾回收是不会回收软引用的对象的，但是垃圾回收之后发现内存空间不够存放新的对象，内存快要溢出了，就会把这些软引用到的对象回收。也就是能存活到下一次垃圾回收的时候

弱引用就和没引用一起，垃圾回收的时候就会把这个对象回收

很少用

对象分配失
败。

1.指定的ParNew垃圾回收器执行GC

2.  4608K也就是4.5M，Eden+1个S的大小

3. 4030K->512K 对年轻代执行了一次GC，GC之前使用了4030K，但是GC之后只有512K的对象存活下来

4. 0.0015734 secs  本次Gc耗费的时间，大概1.5ms,仅仅回收3M的对象

9728K(9.5M) 堆内存的总可用空间， 其实就是年轻代4.5M+老年代5M，然后GC之前整个堆内存使用了4030K，GC后java堆内存使用了574K

ParNew垃圾回收器负责的年轻代总共有4608k(4.5M)可用内存，目前使用了2601K（2.5M）

Eden区有4M的内存，被使用了51%

from survivor区，512K是100%使用率

to survivor区， 512K是0%使用率

concurrent Mark  Sweep(CMS)垃圾回收器,管理老年代的内存空间一共是5M，此时使用了62K

老年代从8m对象的占用变成了6M 的对象占用

S0C

S1C

S0U

S1C

EC

EU

OC

OU

MC

MU

YGC

YGCT

FGC

FGCT

GCT

你只要再线上linux机器上运行：jstat -gc pid 10 每隔1秒更新出来最新的一行jstat统计信息，一共执行10次jstat统计 jstat -gc PID 1000 1000 每隔1秒钟打印一次，连续打印1000次

例子:比如第一秒显示eden区使用了200M内存，第二秒显示出来的统计信息里发现Eden区使用了205M，第三秒发现Eden区使用了209M内存，依次类推，推断出来这个系统每秒新增5M左右的对象

比如Eden有800M内存，发现高峰期每秒新增5M对象，大概高峰期3分钟会触发一个young gc. 日常期每秒新增0.5M对象，那么日常期大概需要半个小时才会触发一次young gc

jstat会告诉你迄今为止系统发生了多少次young gc和这些young c的耗时。 比如系统运行24小时发生了260次young gc ,总耗时20s.那么平均下来每次young gc大概就耗时几十毫秒

之前我们推算出来高峰期的时候多久发生异常young gc,比如3分钟会有一次，那么我们执行 jstat -gc pid 180000 10.就相当于每隔3分钟执行一次统计，连续执行10次。此时大家可以观察，每隔3分钟之后发生了一次young gc，此时Eden，Surivivor 老年代的对象变化。正常情况下，老年代的增长不可能快速的，如果你发现每次young gc后，每次老年代新增几十M，很有可能young gc存活的对象太多了。

比如老年代的总内存800M，每隔3分钟新增50M对象，大概1个小时就会触发full gc。可以根据jstact可以知道full gc的次数以及总耗时，比如full gc执行了10次，总共耗时30s,大概每次full gc的时间3s左右

jmap -heap PID

jmap -histo PID

使用jmap生成堆内存转储快照

尽量让每次young gc后的存活对象小于Survivor区域的50%, 都留存在年轻代里，尽量别让对象进入老年代，尽量减少full gc的频率， 避免频繁full gc对jvm性能的影响