java-jvm

1：jvm体系总体分四大块

1：jvm体系总体分四大块

类的加载机制
jvm内存结构
GC算法垃圾回收
GC分析命令调优

1.类的加载机制

1.1 编译

Java代码的编译和执行的整个过程大概是：开发人员编写Java代码(.java文件)，然后将之编译成字节码(.class文件)，再然后字节码被装入内存，一旦字节码进入虚拟机，它就会被解释器解释执行，或者是被即时代码发生器有选择的转换成机器码执行。
(1) Java代码编译是由Java源码编译器来完成，也就是Java代码到JVM字节码（.class文件）的过程。流程图如下所示：

大概过程：
1：分析和输入到符号表
2：注解处理
3：语义分析和生产class文件

1.2 class 跨平台

编译生产的class 文件一次编译可以跨平台运行。

1.3 class 怎么被JVM加载

1：加载时机，五种情况会立即初始化

创建类的实例(new 的方式)。访问某个类或接口的静态变量，或者对该静态变量赋值，调用类的静态方法
反射的方式
初始化某个类的子类，则其父类也会被初始化
Java虚拟机启动时被标明为启动类的类，直接使用java.exe命令来运行某个主类（包含main方法的那个类）
当使用JDK1.7的动态语言支持时(….)

java 类加载是动态的，并不是所有的类都会在初始化的时候被加载，而是保证程序运行的基础类（基类）会被加载到内存当中，其他类则是在使用的时候被初始化，节省了内存的开销。
2：加载过程
类加载器：

java 默认类加载器有三种 + 自定义类加载器
1) Bootstrap ClassLoader：负责加载$JAVA_HOME中jre/lib/rt.jar里所有的class，由C++实现，不是ClassLoader子类
2) Extension ClassLoader：负责加载java平台中扩展功能的一些jar包，包括$JAVA_HOME中jre/lib/ext/.jar或-Djava.ext.dirs指定目录下的jar包
3) *App ClassLoader：负责记载classpath中指定的jar包及目录中class

类加载器的工作原理如下：
1、当AppClassLoader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器ExtClassLoader去完成。
2、当ExtClassLoader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader去完成。
3、如果BootStrapClassLoader加载失败（例如在$JAVA_HOME/jre/lib里未查找到该class），会使用ExtClassLoader来尝试加载；
4、若ExtClassLoader也加载失败，则会使用AppClassLoader来加载
5、如果AppClassLoader也加载失败，则会报出异常ClassNotFoundException

其实这就是所谓的双亲委派模型。简单来说：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上。
好处: 防止内存中出现多份同样的字节码(安全性角度)

类加载器在成功加载某个类之后，会把得到的 java.lang.Class类的实例缓存起来。下次再请求加载该类的时候，类加载器会直接使用缓存的类的实例，而不会尝试再次加载。

类加载详细过程
加载器加载到jvm中，接下来其实又分了好几个步骤：

加载，查找并加载类的二进制数据，在Java堆中也创建一个java.lang.Class类的对象
连接，连接又包含三块内容：验证、准备、初始化。
- 1)验证，文件格式、元数据、字节码、符号引用验证；
  - 2)准备，为类的静态变量分配内存，并将其初始化为默认值；
  - 3)解析，把类中的符号引用转换为直接引用
初始化，为类的静态变量赋予正确的初始值。

1.4 JIT (Just In Time)即时编辑器

jvm 在加载这些class文件编译成字节码后，并不会马上解析这些字节码（就是把这些Java字节码重新编译优化，生成机器码，让CPU直接执行。这样编出来的代码效率会更高。），如果这样效率就比较低。
解决 JIT：
编译也是要花费时间的，我们一般对热点代码做编译，非热点代码直接解析就好了。
热点代码解释：一、多次调用的方法。二、多次执行的循环体
使用热点探测来检测是否为热点代码，热点探测有两种方式：

采样
计数器

目前HotSpot使用的是计数器的方式，它为每个方法准备了两类计数器：

方法调用计数器（Invocation Counter）
回边计数器（Back EdgeCounter）。
在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阈值，当计数器超过阈值溢出了，就会触发JIT编译。

2.jvm内存结构

java 加载这些类后，怎么存储到JVM中，以及存储的数据结构。如图。

运行时常量池：
　　Java语言并不要求常量一定只能在编译期产生，运行期间也可能产生新的常量，这些常量被放在运行时常量池中。
　　类加载后，常量池中的数据会在运行时常量池中存放！
　　这里所说的常量包括：基本类型包装类（包装类不管理浮点型，整形只会管理-128到127）和String（也可以通过String.intern()方法可以强制将String放入常量池）

字符串常量池：
　　HotSpot VM里，记录interned string的一个全局表叫做StringTable，它本质上就是个HashSet。注意它只存储对java.lang.String实例的引用，而不存储String对象的内容

class文件里常量池里大部分数据会被加载到“运行时常量池”。但String不是。例子中的”Hello”的一个引用会被存到同样在Non Heap区的字符串常量池（String Pool）里。而“Hello”本体还是和所有对象一样，创建在Heap堆区。R大的文章里，测试的结果是在新生代的Eden区。但因为一直有一个引用驻留在字符串常量池，所以不会被GC清理掉。这个Hello对象会生存到整个线程结束。字符串常量池的具体位置是在过去说的永生代里，方法区的外面。

这只是在Test类被类加载器加载时候的情形。主线程中的s变量这时候都还没有被创建，但Hello的实例已经在Heap里了，对它的引用也已经在字符串常量池里了。
等主线程开始创建str变量的时候，虚拟机就会到字符串常量池里找，看有没有能equals(“Hello”)的String。如果找到了，就在栈区当前栈帧的局部变量表里创建str变量，然后把字符串常量池里对Hello对象的引用复制给str变量。找不到的话，才会在heap堆重新创建一个对象，然后把引用驻留到字符串常量区。然后再把引用复制栈帧的局部变量表。

2.1.Java堆（Heap）

   存放对象实例，几乎所有的对象实例都在这里分配内存，以及字符串常量池，运行常量池<br />最小1/64最大 1/4

2.2方法区（Method Area）

   存储已被虚拟机加载的类元数据信息(元空间)

2.3程序计数器（Program Counter Register）

 当前线程所执行的字节码的行号指示器<br />    记录程序运行的位置过程，记录运行轨迹。

2.4虚拟机栈

1M 默认大小
虚拟机栈描述的是Java方法执行的内存结构：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存储当前线程的要执行的方法的局部变量表、操作栈、动态链接、方法出口等信息

栈帧就是一个方法调用时封装的一个入栈的对象
栈帧：

2.5本地方法栈（Native Method Stacks）

   本地方法栈则是为虚拟机使用到的Native方法服务。

2.6实例分析

看下面实例分析类加载过程：使用git 命令编译源码查看汇编源码

javap -c TestJVM.class > test.txt


public class TestJVM {
    public static void main(String[] args) {
        User1 user = new User1();
        user.setName("meikb");
        fun1();
    }
    /**
     * 
     * git 命令   javap -c TestJVM.class >-test.txt
     * 
     * 0: iconst_1
       1: istore_0
       2: iconst_2
       3: istore_1
       4: iload_0
       5: iload_1
       6: iadd
       7: istore_2
       8: getstatic     #32                 // Field java/lang/System.out:Ljava/io/PrintStream;
      11: iload_2
      12: invokevirtual #38                 // Method java/io/PrintStream.println:(I)V
      15: return
     */
    public static void fun1() {
        /**
         * iconst_1 (int型常量值1进栈)
         * istore_0 (将栈顶int型数值存入第一个局部变量)
         */
        int i = 1;
        /**
         * iconst_2 (int型常量值2进栈)
         * istore_1 (将栈顶int型数值存入第二个局部变量)
         */
        int k = 2;
        /**
         * iload_0  第一个int型局部变量进栈
         * iload_1  第二个int型局部变量进栈
         * iadd 加法
         */
        int a = i + k;
        System.out.println(a);
    }
}
class User1{
    private String name;
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
}

1：首先 java 文件会变编译成 .class 文件，运行 TestJVM 时会被加载到JVM中，元空间存储着类的信息(包括类的名称、方法信息、字段信息..)。
2：然后JVM找到TestJVM的主函数入口(main)，为main函数创建栈帧，开始执行main函数
3：main函数的第一条命令是User1 user = new User1();就是让JVM创建一个User1对象，但是这时候方法区中没有User1类的信息，所以JVM马上加载User1类，把User1类的类型信息放到方法区中(元空间)
4：加载完User1类之后，Java虚拟机做的第一件事情就是在堆区中为一个新的User1实例分配内存, 然后调用构造函数初始化User1实例，这个User1实例持有着指向方法区的User1类的类型信息（其中包含有方法表，java动态绑定的底层实现）的引用
5：当使用user.setName(“meikb”);的时候，JVM根据user引用找到user对象，然后根据user对象持有的引用定位到方法区（元空间）中user类的类型信息的方法表，获得setName()函数的字节码的地址.
6 : 为setName()函数创建栈帧，开始运行setName()函数

过程 4 ：就是在栈中会存放这个对象User1的实例的引用，对象实例存储在堆中，那么这个对象在堆中具体的存储数据结构是怎么样的呢，如下。

解释：对象头包含markword 和class point ,占用 8 + 4 个字节，实例数据为空 0 ，补齐4（所构建的数据结构要被8整除，方便计算），总共 16字节。

如果有 int 类型，string 类型两个常量，那么就应该是 12 + 4+ 4 +4（前面是三个求和20不能整除） = 24

markword 结构:

小结：
1. 创建的对象的在堆的数据结构最少是16个字节，然后根据的你对象的内容进行扩充，但是总的字节数是8的倍数。
2.在markword大小是8个字节，也就是64位，其中中间有31位存放是hashcode 如果用调用，后面三位是锁信息。
也就是说我们调用new Object方法会根据我们Object的内容进行存储，可能有会调用hashcode 方法可能会加锁等等。

pom

<!-- https://mvnrepository.com/artifact/org.openjdk.jol/jol-core -->
        <dependency>
            <groupId>org.openjdk.jol</groupId>
            <artifactId>jol-core</artifactId>
            <version>0.9</version>
        </dependency>

public class TestObj {
    public static void main(String[] args) {
        Object o = new Object();
        System.out.println(ClassLayout.parseInstance(o).toPrintable());
    }
}

输出如下：

3.GC算法垃圾回收

1:垃圾回收器算法

	定义	备注
标记-清除算法	首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象	1: 效率不高; 2: 产生碎片
复制算法	内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块内存用完了，就将还存活着的对象复制到另外一块上，然后再把已经使用过的内存空间一次清理掉	对象存活高不适合,适合回收新生代
标记-整理算法	标记过程仍然和标记-清除一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理端边界以外的内存.	适合老年代
分代收集算法	Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代，每次垃圾收集时都发现大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率较高，没有额外的空间对它进行分配担保，就必须使用”标记-清理“和”标记-整理“算法来进行回收。	并用

2:常用垃圾回收器

Serial 串行收集器	单线程，一个CPU或一条收集线程去完成垃圾收集工作，收集时必须暂停其他所有的工作线程，直到它结束。虽然如此，它依然是虚拟机运行在Client模式下的默认新生代收集器。简单而高效。
Parallel Scavenge JVM 默认收集器	JDK6版本之后引入，Parallel Scavenge作为年轻代回收器，Parallel Old作为老年代回收器，在JDK6之前，Parallel Scavenge只能适配Serial Old，现在是JDK7,JDK8的默认组合。特点上面说了就是适应最大吞吐量。
CMS 收集器	CMS(Concurrent Mark Sweep) 收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类尤其重视服务的响应速度，希望系统停顿时间最短。CMS收集器就非常符合这类应用的需求。
G1 Garbage First JVM推荐	G1最大的特点是引入分区的思路，弱化了分代的概念，合理利用垃圾收集各个周期的资源，解决了其他收集器甚至CMS的众多缺陷。

4.GC分析命令调优

过程分析：1.Eden : from : to 8:1:1,如果内存不够进入老年代。
1: new 出来的对象都在Eden 中，第一次，扫描Eden 和from的幸存者，复制到to.然后清空 from 和Eden,然后把to再给from,但是加上一次计数，如此反复，直到15，也就是发生了15次youngGC（minorgc），进入老年代，等到老年代满的时候发生FullGC。

GC : youngGC FullGC
jvm 调优其实就是减少fullCG 频率和时间。

jvm参数

参数名称	含义	默认值
-Xms	初始堆大小	1/64	默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制.
-Xmx	最大堆大小	1/4	默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制
-Xmn	年轻代大小(1.4or lator)		注意：此处的大小是（eden+ 2 survivor space).与jmap -heap中显示的New gen是不同的。

整个堆大小=年轻代大小 + 年老代大小 + 持久代大小.

一般小的应用，如果栈不是很深，应该是128k够用的大的应用建议使用256k。这个选项对性能影响比较大，需要严格的测试。（校长）

和threadstacksize选项解释很类似,官方文档似乎没有解释,在论坛中有这样一句话:””

-Xss is translated in a VM flag named ThreadStackSize”

一般设置这个值就可以了。 | | -
XX:ThreadStackSize | Thread Stack Size | | (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.] | | -XX:NewRatio | 年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代) | | -XX:NewRatio=4表示年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5

并行收集器相关参数

| -XX:+UseParallelGC | Full GC采用parallel MSC

(此项待验证) | | 选择垃圾收集器为并行收集器.此配置仅对年轻代有效.即上述配置下,年轻代使用并发收集,而年老代仍旧使用串行收集.(此项待验证) | | —- | —- | —- | —- | | -XX:+UseParNewGC | 设置年轻代为并行收集 | | 可与CMS收集同时使用

CMS相关参数

-XX:+UseConcMarkSweepGC	使用CMS内存收集		测试中配置这个以后,-XX:NewRatio=4的配置失效了,原因不明.所以,此时年轻代大小最好用-Xmn设置.???
-XX:+AggressiveHeap			试图是使用大量的物理内存

长时间大内存使用的优化，能检查计算资源（内存，处理器数量）

至少需要256MB内存

辅助信息

-XX:+PrintGC			输出形式: [GC 118250K->113543K(130112K), 0.0094143 secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]
-XX:+PrintGCDetails			输出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
-XX:+PrintGCTimeStamps
-XX:+PrintGC:PrintGCTimeStamps			可与-XX:+PrintGC -XX:+PrintGCDetails混合使用

GC性能方面的考虑
对于GC的性能主要有2个方面的指标：吞吐量throughput（工作时间不算gc的时间占总的时间比）和暂停pause（gc发生时app对外显示的无法响应）。
1. Total Heap
默认情况下，vm会增加/减少heap大小以维持free space在整个vm中占的比例，这个比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。
一般而言，server端的app会有以下规则：

对vm分配尽可能多的memory；
将Xms和Xmx设为一样的值。如果虚拟机启动时设置使用的内存比较小，这个时候又需要初始化很多对象，虚拟机就必须重复地增加内存。
处理器核数增加，内存也跟着增大。

The Young Generation
另外一个对于app流畅性运行影响的因素是young generation的大小。young generation越大，minor collection越少；但是在固定heap size情况下，更大的young generation就意味着小的tenured generation，就意味着更多的major collection(major collection会引发minor collection)。
NewRatio反映的是young和tenured generation的大小比例。NewSize和MaxNewSize反映的是young generation大小的下限和上限，将这两个值设为一样就固定了young generation的大小（同Xms和Xmx设为一样）。
如果希望，SurvivorRatio也可以优化survivor的大小，不过这对于性能的影响不是很大。SurvivorRatio是eden和survior大小比例。
一般而言，server端的app会有以下规则：

首先决定能分配给vm的最大的heap size，然后设定最佳的young generation的大小；
如果heap size固定后，增加young generation的大小意味着减小tenured generation大小。让tenured generation在任何时候够大，能够容纳所有live的data（留10%-20%的空余）。

经验&&规则

年轻代大小选择
- 响应时间优先的应用:尽可能设大,直到接近系统的最低响应时间限制(根据实际情况选择).在此种情况下,年轻代收集发生的频率也是最小的.同时,减少到达年老代的对象.
- 吞吐量优先的应用:尽可能的设置大,可能到达Gbit的程度.因为对响应时间没有要求,垃圾收集可以并行进行,一般适合8CPU以上的应用.
- 避免设置过小.当新生代设置过小时会导致:1.YGC次数更加频繁 2.可能导致YGC对象直接进入旧生代,如果此时旧生代满了,会触发FGC.
年老代大小选择
1. 响应时间优先的应用:年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数.如果堆设置小了,可以会造成内存碎片,高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间.最优化的方案,一般需要参考以下数据获得:
  并发垃圾收集信息、持久代并发收集次数、传统GC信息、花在年轻代和年老代回收上的时间比例。
2. 吞吐量优先的应用:一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代.原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象.
较小堆引起的碎片问题
因为年老代的并发收集器使用标记,清除算法,所以不会对堆进行压缩.当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象.但是,当堆空间较小时,运行一段时间以后,就会出现”碎片”,如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记,清除方式进行回收.如果出现”碎片”,可能需要进行如下配置:
-XX:+UseCMSCompactAtFullCollection:使用并发收集器时,开启对年老代的压缩.
-XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下,这里设置多少次Full GC后,对年老代进行压缩
用64位操作系统，Linux下64位的jdk比32位jdk要慢一些，但是吃得内存更多，吞吐量更大
XMX和XMS设置一样大，MaxPermSize和MinPermSize设置一样大，这样可以减轻伸缩堆大小带来的压力
使用CMS的好处是用尽量少的新生代，经验值是128M－256M，然后老生代利用CMS并行收集，这样能保证系统低延迟的吞吐效率。实际上cms的收集停顿时间非常的短，2G的内存，大约20－80ms的应用程序停顿时间
系统停顿的时候可能是GC的问题也可能是程序的问题，多用jmap和jstack查看，或者killall -3 java，然后查看java控制台日志，能看出很多问题。(相关工具的使用方法将在后面的blog中介绍)
仔细了解自己的应用，如果用了缓存，那么年老代应该大一些，缓存的HashMap不应该无限制长，建议采用LRU算法的Map做缓存，LRUMap的最大长度也要根据实际情况设定。
采用并发回收时，年轻代小一点，年老代要大，因为年老大用的是并发回收，即使时间长点也不会影响其他程序继续运行，网站不会停顿
JVM参数的设置(特别是 –Xmx –Xms –Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold等参数的设置没有一个固定的公式，需要根据PV old区实际数据 YGC次数等多方面来衡量。为了避免promotion faild可能会导致xmn设置偏小，也意味着YGC的次数会增多，处理并发访问的能力下降等问题。每个参数的调整都需要经过详细的性能测试，才能找到特定应用的最佳配置。

promotion failed:
垃圾回收时promotion failed是个很头痛的问题，一般可能是两种原因产生，第一个原因是救助空间不够，救助空间里的对象还不应该被移动到年老代，但年轻代又有很多对象需要放入救助空间；第二个原因是年老代没有足够的空间接纳来自年轻代的对象；这两种情况都会转向Full GC，网站停顿时间较长。
解决方方案一：
第一个原因我的最终解决办法是去掉救助空间，设置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，第二个原因我的解决办法是设置CMSInitiatingOccupancyFraction为某个值（假设70），这样年老代空间到70%时就开始执行CMS，年老代有足够的空间接纳来自年轻代的对象。
解决方案一的改进方案：
又有改进了，上面方法不太好，因为没有用到救助空间，所以年老代容易满，CMS执行会比较频繁。我改善了一下，还是用救助空间，但是把救助空间加大，这样也不会有promotion failed。具体操作上，32位Linux和64位Linux好像不一样，64位系统似乎只要配置MaxTenuringThreshold参数，CMS还是有暂停。为了解决暂停问题和promotion failed问题，最后我设置-XX:SurvivorRatio=1 ，并把MaxTenuringThreshold去掉，这样即没有暂停又不会有promotoin failed，而且更重要的是，年老代和永久代上升非常慢（因为好多对象到不了年老代就被回收了），所以CMS执行频率非常低，好几个小时才执行一次，这样，服务器都不用重启了。

-Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

CMSInitiatingOccupancyFraction值与Xmn的关系公式
上面介绍了promontion faild产生的原因是EDEN空间不足的情况下将EDEN与From survivor中的存活对象存入To survivor区时,To survivor区的空间不足，再次晋升到old gen区，而old gen区内存也不够的情况下产生了promontion faild从而导致full gc.那可以推断出：eden+from survivor < old gen区剩余内存时，不会出现promontion faild的情况，即：
(Xmx-Xmn)(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2)) 进而推断出：
CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)100
例如：
当xmx=128 xmn=36 SurvivorRatior=1时 CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)100 =73.913
当xmx=128 xmn=24 SurvivorRatior=1时 CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)100=84.615…
当xmx=3000 xmn=600 SurvivorRatior=1时 CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33
CMSInitiatingOccupancyFraction低于70% 需要调整xmn或SurvivorRatior值。

调优步骤：

1：添加日志输出

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:./gc.log

实例配置：

nohup java -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:./gc.log -jar zallsteel-agent.jar --spring.profiles.active=stage > log.file 2>&1 &

2 : 分析日志得到关键指标

吞吐量、最大停顿、平均停顿、youngGC 、fullGC 等。

3：调整参数

1 : 比如修改 matespace(元空间)大小

-XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M

2 : 增大年轻代动态扩容增量（默认 20%），可以减少YGC -XX:YoungGenerationSizeIncrement=30

3：修改收集器 -XX:+UseG1GC

-XX:+UseG1GC

https://gceasy.io/ 分析地址
测试结果：

配置	吞吐量	最大停顿	平均停顿	YGC	FGC
默认	98.075％	270ms	29.1ms	44	3
修改元空间 256M	98.825%	260 ms	21.2 ms	41	2
G1	97.129％	40.0 ms	17.6 ms	97	0

通过第一次修改元空间大小，可提看出提高了吞吐量，最大停顿平均停顿减少， YGC和FGC的次数都减少了。
使用G1 一般情况是不会发生FGC, 上面实验结果可以看出，最大停顿和平均停顿降下了，YGC 提高了，吞吐量略微下降。

针对8G内存的使用配置：

-Xms6000M -Xmx6000M -Xmn500M -XX:PermSize=500M -XX:MaxPermSize=500M -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 -Xnoclassgc -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=90 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

5.java 引用

强引用、软引用、弱引用、虚引用
在Java中，虽然不需要程序员手动去管理对象的生命周期，但是如果希望某些对象具备一定的生命周期的话（比如内存不足时JVM就会自动回收某些对象从而避免OutOfMemory的错误）就需要用到软引用和弱引用了。
从Java SE2开始，就提供了四种类型的引用：强引用、软引用、弱引用和虚引用。Java中提供这四种引用类型主要有两个目的：第一是可以让程序员通过代码的方式决定某些对象的生命周期；第二是
有利于JVM进行垃圾回收。

5.1 强引用

之前我们使用的大部分引用实际上都是强引用，这是使用最普遍的引用。比如下面这段代码中的object和str都是强引用：

Object object = new Object();
String str = "StrongReference";

如果一个对象具有强引用，那就类似于必不可少的物品，不会被垃圾回收器回收。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不回收这种对象。

public class StrongReference {
    public static void main(String[] args) {
        new StrongReference().method1();
    }
    public void method1(){
        Object object=new Object();
        Object[] objArr=new Object[Integer.MAX_VALUE];
    }
}

当运行至Object[] objArr = new Object[Integer.MAX_VALUE]时，如果内存不足，JVM会抛出OOM错误也不会回收object指向的对象。不过要注意的是，当method1运行完之后，object和objArr都已经不存在了，所以它们指向的对象都会被JVM回收。
如果想中断强引用和某个对象之间的关联，可以显示地将引用赋值为null，这样一来的话，JVM在合适的时间就会回收该对象。
比如ArraryList类的clear方法中就是通过将引用赋值为null来实现清理工作的

public void clear() {
      modCount++;
      // Let gc do its work
      for (int i = 0; i < size; i++)
          elementData[i] = null;
      size = 0;
}

在ArrayList类中定义了一个私有的变量elementData数组，在调用方法清空数组时可以看到为每个数组内容赋值为null。不同于elementData=null，强引用仍然存在，避免在后续调用 add()等方法添加元素时进行重新的内存分配。使用如clear()方法中释放内存的方法对数组中存放的引用类型特别适用，这样就可以及时释放内存。

5.2软引用

软引用是用来描述一些有用但并不是必需的对象，在Java中用java.lang.ref.SoftReference类来表示。对于软引用关联着的对象，只有在内存不足的时候JVM才会回收该对象。因此，这一点可以很好地用来解决OOM的问题，并且这个特性很适合用来实现缓存：比如网页缓存、图片缓存等。

软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被JVM回收，这个软引用就会被加入到与之关联的引用队列中。

import java.lang.ref.SoftReference;
public class SoftRef {  
    public static void main(String[] args){  
        System.out.println("start");            
        Obj obj = new Obj();            
        SoftReference<Obj> sr = new SoftReference<Obj>(obj);  
        obj = null;  
        System.out.println(sr.get());  
        System.out.println("end");     
    }       
}  
class Obj{  
    int[] obj ;  
    public Obj(){  
        obj = new int[1000];  
    }  
}

5.3弱引用

ThreadLocal
弱引用也是用来描述非必需对象的，当JVM进行垃圾回收时，无论内存是否充足，都会回收被弱引用关联的对象。在java中，用java.lang.ref.WeakReference类来表示。

弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。所以被软引用关联的对象只有在内存不足时才会被回收，而被弱引用关联的对象在JVM进行垃圾回收时总会被回收。

public class WeakRef {
    public static void main(String[] args) {
        WeakReference<String> sr = new WeakReference<String>(new String("hello"));
        System.out.println(sr.get());
        System.gc();                //通知JVM的gc进行垃圾回收
        System.out.println(sr.get());
    }
}

在使用软引用和弱引用的时候，我们可以显示地通过System.gc()来通知JVM进行垃圾回收，但是要注意的是，虽然发出了通知，JVM不一定会立刻执行，也就是说这句是无法确保此时JVM一定会进行垃圾回收的。
弱引用还可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。

Object o = new Object(); //只要o还指向对象就不会被回收
WeakReference<Object> wr = new WeakReference<Object>(o);

当要获得weak reference引用的object时, 首先需要判断它是否已经被回收，如果wr.get()方法为空, 那么说明weakCar指向的对象已经被回收了。

应用场景：如果一个对象是偶尔的使用，并且希望在使用时随时就能获取到，但又不想影响此对象的垃圾收集，那么应该用 Weak Reference 来记住此对象。或者想引用一个对象，但是这个对象有自己的生命周期，你不想介入这个对象的生命周期，这时候就应该用弱引用，这个引用不会在对象的垃圾回收判断中产生任何附加的影响。

5.4 虚引用

虚引用和前面的软引用、弱引用不同，它并不影响对象的生命周期。在java中用java.lang.ref.PhantomReference类表示。如果一个对象与虚引用关联，则跟没有引用与之关联一样，在任何时候都可能被垃圾回收器回收。虚引用主要用来跟踪对象被垃圾回收的活动。

虚引用必须和引用队列关联使用，当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。如果程序发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。

public class PhantomRef {
    public static void main(String[] args) {
        ReferenceQueue<String> queue = new ReferenceQueue<String>();
        PhantomReference<String> pr = new PhantomReference<String>(new String("hello"), queue);
        System.out.println(pr.get());
    }
}

引用类型	被回收时间	用途	生存时间
强引用	从来不会	对象的一般状态	JVM停止运行时
软引用	内存不足时	对象缓存	内存不足时
弱引用	jvm垃圾回收时	对象缓存	gc运行后
虚引用	未知	未知	未知

在实际程序设计中一般很少使用弱引用与虚引用，使用软引用的情况较多，这是因为软引用可以加速JVM对垃圾内存的回收速度，可以维护系统的运行安全，防止内存溢出（OutOfMemory）等问题的产生
利用软引用和弱引用解决OOM问题：假如有一个应用需要读取大量的本地图片，如果每次读取图片都从硬盘读取，则会严重影响性能，但是如果全部加载到内存当中，又有可能造成内存溢出，此时使用软引用可以解决这个问题。
设计思路是：用一个HashMap来保存图片的路径和相应图片对象关联的软引用之间的映射关系，在内存不足时，JVM会自动回收这些缓存图片对象所占用的空间，从而有效地避免了OOM的问题。