jvmcms过程

1、jvm的内存模型中运行时常量池与Class文件结构中说的常量池是否是同一个？

老年代调整：
标记-清除(Mark - Sweep)算法
标记-压缩(Mark - Compact)算法

老年代调整参数：
-XX:PretenureSizeThreshold 控制直接升入老年代的对象大小，大于这个值的对象会直接分配在老年代中

FULL GC发生的概率比较低，发生的话操作时间特别长，严重影响程序的性能。

永久代（JDK1.8之后被废除了）
该区域中的对象不会被回收。当时简单的理解是方法区就是永久代，HotSpot虚拟机规范中是存在永久代概念的。
被元空间取代

JDK1.8之后，元空间取代永久代，元空间的本质就是本机的物理内存
OOM异常 可能分为
堆内存溢出（Java Heap space）：往往出现在FUll GC失败之后
永久代溢出（PermGen space）：一个方法中出现的内存溢出
元空间溢出（Metaspace）：分配的物理内存不足，或者数据量高于物理内存

垃圾的收集一定要分两个空间考虑：年轻代、老年代，老年代的内存空间要大于年轻待

可用GC方式：
新生代可用GC策略：
串行GC(Serial Copying)
并行回收GC(Parallel Scavenge):
复制(Copying)清理算法；
操作步骤：
在扫描和复制时均采用多线程方式处理，并行回收GC为空间较大的年轻代回收提供许多优化
优势：
在多CPU的机器上其GC耗时会比串行方式短，适合多CPU、对暂停时间要求较短的应用
并行GC(ParNew)：
复制(Copying)清理算法
操作步骤：
并行GC(ParNew)必须结合老年代，"cms GC"一起使用。因为年轻代如果发生了"Minor GC"时，老年代也需要使用"CMS GC"同时处理，
（并行回收GC并不会做这些）

CMS(Concurrent Mark-Sweep):是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上，这种垃圾回收器非常适用
老年代可用GC策略：
串行GC(Serial MSC)
算法：标记-清除-压缩（Mark-Sweep-Compact）
操作步骤：
扫描老年代中还存活的对象，并且对这些对象进行标记
遍历整个老年代的内存空间，回收所有未标记的对象内存
将所有存活对象都集中在一端，而后将所有回收对象的内存空间变为一块连续的内存空间
优缺点：串行执行的过程中为单线程，需要暂停应用并耗时较长
并行GC(Parallel MSC)
算法：标记-压缩（Mark-Compact）
操作步骤：
将老年代内存空间按照线程个数划分若干子区域；
多个线程并行对各自子区域内的存活对象进行标记
多个线程并行清除所有未标记的对象
多个线程并行将多个存活对象整理在一起，并将所有被回收的对象空间整合为一体
优缺点：
多个线程同时进行垃圾回收可以缩短应用的暂停时间，但是由于老年代的空间一般较大，所以在扫描和标记存活对象上需要花费较长时间。

与串行相比，就是多了一个多线程的支持，但是这样的暂停时间就会减少
并行GC(CMS)
算法：标记-清除（Mark-Sweep）
操作步骤：
初始标记（STW【Stop-The World】 Initial Mark）：虚拟机暂停正在执行的任务（STW）,由根对象扫描出所有的关联对象，并做出标记。此过程只会导致短暂的JVM暂停
并发标记（Concurrent Marking）：恢复所有暂停的线程对象，并且对之前标记过的对象进行扫描，取得所有跟标记对象有关联的对象
并发预处理（Concurrent Precleaning）：查找所有在并发标记阶段新进入老年代的对象（一些对象可能从新生代晋升到老年代，或者有一些对象被分配到老年代），通过重新扫描，减少下一阶段的工作
重新标记（STW Remark）：此阶段会暂停虚拟机，对在“并发标记”阶段被改变引用或新创建的对象进行标记
并发清理（Concurrent Sweeping）：恢复所有暂停的应用线程，对所有未标记的垃圾对象进行清理，并且会尽量将已回收对象的空间重新拼凑为一个整体。在此阶段收集器线程和应用程序线程并发执行
并发重置（Concurrent Reset）：重置CMS收集器的数据结构，等待下一次垃圾回收。
优缺点：
只有在第一次和重新标记阶段才会暂停整个应用，这样对应用程序所带来的影响非常的小、缺点是并发标记与回收线程会与应用线程争抢CPU资源，并且容易产生内存碎片。

常用GC策略：
运行环境 年轻代GC 老年代
单机程序（client） 串行GC(Serial Copying) 串行GC(Serial MSC)
服务器程序（Server） 并行回收GC(Parallel Scavenge) 并行GC(Parallel Mark Sweep、Parallel Compacting)

如果要向确认使用的GC处理，首先需要知道当前的主机上可以支持的处理进程数量
调参：
使用串行GC策略：-XX:+UseSerialGC
使用并行GC策略：-XX:+UseParNewGC
使用CMS：-XX:+UseConcMarkSweepGC
CMS会经历如下几个步骤：
"CMS-concurrent-mark-start"：CMS标记开始
"CMS-concurrent-mark"：表示开始进行标记，进入到了STW状态（暂停）
"CMS-concurrent-preclean-start"：预清理开始
"CMS-concurrent-sweep-start"：开始进行无用对象清理
CMS的处理适当性能会好一些，但是这所有的GC策略都是现在正在常用的策略，不过似乎都有缺陷。

总结：
实际开发之中对于GC的策略不建议手动修改，默认的一版比较好

G1收集器：
对Java服务器而言，如何去选择一个合适的配置呢？ 默认情况下，Java会为每一个线程分配1M的内存空间。如果现在电脑有32G的内存，最大可以分配30G的内存空间（理论）
理论上可以处理 30* 1024 个用户请求,所以一般的服务器处理个5000——10000基本上也就够了

G1的实现方案相当于将所有的子内存区域合并在一起，也不在进行任何的区分，这样就相当于所有的内存的区域都可以按照统一的方式进行统一规划处理
G1的最大特点就是避免了全内存扫描

G1在标记和清理的时候是按照区域完成的，这样不影响其他的区域的执行，除此之外，使用的形式和之前的CMS都是类似的操作方式。
调参使用G1收集器：-Xmx10m -Xms10m -XX:+PrintGCDetails -XX:+UseG1GC

G1的垃圾收集比传统的GC要快一些

引用类型概述：
对于垃圾的产生与回收的处理之中，要想进行更好的控制，就必须清楚的掌握JAVA中的四种引用方式：
1.强引用（Strong Reference）：即使进行了多次GC的回收，即使JVM的内存真的已经不够用了，最终不得以抛出了OOM错误，那么该引用继续抢占
2.软引用（Soft Reference）：当内存空间不足时，可以回收此内存空间。如果充足则不回收，可以用其完成一些缓存的处理操作开发
3.弱引用（Weak Reference）：不管内存是否紧张，只要一出现GC处理，则立即回收
4.幽灵引用（Phantom Reference）：和没有引用是一样的

强引用：
即使出现GC，即使内存不足，该引用的数据也不会被回收
强引用不是造成OOM的关键因素，正常来讲，你每一个用户（线程）操作完成后该对象都很容易进行回收。
软引用：
当内存空间不足时才进行GC的空间释放，但是如果想使用软引用必须单独使用特殊的处理类：
import java.lang.ref.SoftReference;
public class SoftReferenceTest {
public static void main(String[] args) {
String str = "www.cwnu.com";
//加入到软引用之中
SoftReference<String> stringReference = new SoftReference<String>(str);
//类似强引用端口连接
str = null;
//因为软引用空间还很富裕，所以不会释放
System.gc();
System.out.println(stringReference.get());

}
}
在开发中，可以利用软引用实现高速缓存组件
弱引用：
最大的特点：一旦发生GC操作，则保存的内容则立即释放
import java.lang.ref.WeakReference;
public class WeakReferenceTest {
public static void main(String[] args) {
String a = new String("www.cwnu.com");
WeakReference reference = new WeakReference<String>(a);
a = null;
System.gc();
System.out.println(reference.get());
}
}
在我们类集里面有一个与弱引用功能相似的Map集合，WeakHashMap<K,V>，它属于弱引用的一个实现
import java.util.*;
public class WeakReferenceTest {
public static void main(String[] args) {
Map<Integer,String> map = new WeakHashMap<Integer,String>();
map.put(new Integer(1),new String("a"));
map.put(new Integer(2),new String("b"));
System.gc();
System.out.println(map);
}
}
使用WeakHashMap好处是保存一些共享数据，如果长时间不使用则可以清空

引用队列：
如果要想清楚引用队列，则首先必须知道对象的引用的强度，如果说按照现在的理解来讲： 强引用 > 软引用 > 弱引用。

引用队列里面所保存的就是一个要准备被回收的对象的信息
import java.lang.ref.Reference;
import java.lang.ref.ReferenceQueue;
import java.lang.ref.WeakReference;

public class ReferenceQueueTest {
public static void main(String[] args) throws Exception{
String str = new String("www.cwnu.com");

ReferenceQueue<String> queue = new ReferenceQueue<String>();
WeakReference<String> weak = new WeakReference<String>(str,queue);
str = null;
System.out.println(weak.isEnqueued());
System.gc();
Thread.sleep(500);
System.out.println(weak.isEnqueued());
//观察队列是否有内容
System.out.println(queue.poll());
}
}
幽灵引用（虚引用）：
幽灵引用指的是什么都不保存，但是又看起来保存了似得。
import java.lang.ref.PhantomReference;
import java.lang.ref.ReferenceQueue;

public class PhantomReferenceTest {
public static void main(String[] args) throws Exception{
String str = new String("www.cwnu.com");

ReferenceQueue<String> queue = new ReferenceQueue<String>();
PhantomReference<String> ps = new PhantomReference<String>(str,queue);
str = null;
System.out.println(ps.isEnqueued());
System.gc();
Thread.sleep(500);
System.out.println(ps.isEnqueued());
//观察队列是否有内容
System.out.println(queue.poll());
}
}

幽灵引用直接把保存的内容保存在引用队列之中

关于逃逸分析：
在平时开发过程中就要可尽可能的控制变量的作用范围了，变量范围越小越好

建议去刷题，我运气好，简单的算法让我碰到了，一些快排，堆排，二叉树相关的，链表反转，成环，环节点，跳楼梯等常规的简单算法建议刷刷，双指针，dp，递归这些还是多找找感觉，大数据内存有限的场景的统计，有时间一些middle可以去试试，手写红黑树你要是可以，那我估计算法你稳了

堆栈相关：
1.寄存器：最快的存储区, 由编译器根据需求进行分配,我们在程序中无法控制.
2. 栈：存放基本类型的变量数据和对象的引用，但对象本身不存放在栈中，而是存放在堆（new 出来的对象）或者常量池中（字符串常量对象存放在常量池中。）
3. 堆：存放所有new出来的对象。
4. 静态域：存放静态成员（static定义的）
5. 常量池：存放字符串常量和基本类型常量（public static final）。
6. 非RAM存储：硬盘等永久存储空间

2、jvm cms stop the world进程什么意思

JVM有个叫做“安全点”和“安全区域”的东西，在发生GC时，所有的线程都会执行到“安全点”停下来。

在需要GC的时候，JVM会设置一个标志，当线程执行到安全点的时候会轮询检测这个标志，如果发现需要GC，则线程会自己挂起，直到GC结束才恢复运行。

体系结构：

每个Java程序都离不开Java虚拟机，Java程序的运行依靠具体的Java虚拟机实例。在Java虚拟机规范中，分别用子系统、内存区、数据类型以及指令这几个术语来描述的。这些组成部分一起展示出一个抽象化的虚拟机内部的抽象体系结构。

(2)jvmcms过程扩展资料：

内存管理：

对于Java运行时涉及到的存储区域主要包括程序计数器、Java虚拟机栈、本地方法栈、java堆、方法区以及直接内存等等。对于每个部分，都有其使用的条件。程序计数器主要是取下一条指令，在Java里面主要是取下一条指令的字节码文件。

Java虚拟机栈主要是利用栈先进后出的特性存储局部变量表，动态链接等，主要包括堆内存和栈内存，对于程序员内存分析而言是特别重要的。

本地方法栈与上边的栈基本作用差不多，只不过这里是为Java方法而服务。Java堆是内存管理中最大的一块，所有的线程共享这一块内容，同时该部分也是垃圾收集器的主要区域。

3、如何设置jvm启动参数

不管是YGC还是Full GC,GC过程中都会对导致程序运行中中断,正确的选择不同的GC策略,调整JVM、GC的参数，可以极大的减少由于GC工作，而导致的程序运行中断方面的问题，进而适当的提高Java程序的工作效率。但是调整GC是以个极为复杂的过程，由于各个程序具备不同的特点，如：web和GUI程序就有很大区别（Web可以适当的停顿，但GUI停顿是客户无法接受的），而且由于跑在各个机器上的配置不同（主要cup个数，内存不同），所以使用的GC种类也会不同(如何选择见GC种类及如何选择)。本文将注重介绍JVM、GC的一些重要参数的设置来提高系统的性能。
GC性能方面的考虑
对于GC的性能主要有2个方面的指标：吞吐量throughput（工作时间不算gc的时间占总的时间比）和暂停pause（gc发生时app对外显示的无法响应）。
1. Total Heap
默认情况下，vm会增加/减少heap大小以维持free space在整个vm中占的比例，这个比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。
一般而言，server端的app会有以下规则：
对vm分配尽可能多的memory；
将Xms和Xmx设为一样的值。如果虚拟机启动时设置使用的内存比较小，这个时候又需要初始化很多对象，虚拟机就必须重复地增加内存。
处理器核数增加，内存也跟着增大。
2. 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.
年老代大小选择
响应时间优先的应用:年老代使用并发收集器,所以其大小需要小心设置,一般要考虑并发会话率和会话持续时间等一些参数.如果堆设置小了,可以会造成内存碎 片,高回收频率以及应用暂停而使用传统的标记清除方式;如果堆大了,则需要较长的收集时间.最优化的方案,一般需要参考以下数据获得:
并发垃圾收集信息、持久代并发收集次数、传统GC信息、花在年轻代和年老代回收上的时间比例。
吞吐量优先的应用:一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代.原因是,这样可以尽可能回收掉大部分短期对象,减少中期的对象,而年老代尽存放长期存活对象.
较小堆引起的碎片问题
因为年老代的并发收集器使用标记,清除算法,所以不会对堆进行压缩.当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象.但是,当堆空间较小时,运行一段时间以后,就会出现"碎片",如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记,清除方式进行回收.如果出现"碎片",可能需要进行如下配置:
-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即可，第二个原因我的解决办法是设置为某个值（假设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:=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

值与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-/100)>=(Xmn-Xmn/(SurvivorRatior+2)) 进而推断出：
<=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100
例如：
当xmx=128 xmn=36 SurvivorRatior=1时 <=((128.0-36)-(36-36/(1+2)))/(128-36)*100 =73.913
当xmx=128 xmn=24 SurvivorRatior=1时 <=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…
当xmx=3000 xmn=600 SurvivorRatior=1时 <=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33
低于70% 需要调整xmn或SurvivorRatior值。