共计 2935 个字符，预计需要花费 8 分钟才能阅读完成。
深刻了解 JVM – 阶段总结与回顾（一）
前言
这篇文章不写新内容，而是回顾之前的文章内容。
为什么开设专栏
开设这个专栏的目标毫无疑问是给集体的成长做一个记录和归档，因为这段时间下来发现学货色肯定要零碎并且有目标循序渐进的学才有更快的成长，JVM 的内容和细节是学不完的，所以要分明学这个货色的作用是什么很要害，集体学这个货色无非就是为了面试以及理解底层原理，同时本着书到用时方恨少的准则编写专栏。
系列文章阶段总结：
专栏地址：深刻了解 JVM 虚拟机
第一篇：深刻了解 JVM 虚拟机 – JVM 的初步理解
系列的开篇，在第一篇专栏咱们须要理解 JVM 到底是个什么货色，他对于 JAVA 开发者而言的重要意义，同时咱们编写的代码是如何通过 JVM 运行并且实现咱们想要的成果的，重点在于 JAVA 加载到 JVM 的工作流程。
这里也讲述了 JVM 的双亲委派模型和 Tomcat 的双亲委派模型是如何突破他的，类加载器也是 JVM 的一个核心内容。
第二篇：深刻了解 JVM 虚拟机 – 虚拟机的倒退历史
根本就是《深刻了解 JVM 虚拟机》的笔记了，当然很多博客也介绍了。
第三篇：深刻了解 JVM – 分代的基本概念
讲述了 JVM 的传统分代模型的特点，以及新生代和老年代的划分，重点是新生代如何进入老年代，须要的条件以及相干的参数设置也是面试高频点。最初介绍了 JVM 的调优参数。
第四篇：深刻了解 JVM 虚拟机 – jvm 的对象调配策略
这篇文章集体认为值得关注的点是理论的 JVM 测试后果和书外面不一样！同时能够发现新版本当中的 Parnew 会在间断调配大对象的时候让对象间接进入老年代，真的很奇怪！还是倡议学这些货色肯定本人尝试，花点工夫换来的收益是你动向不到的！
第五篇：深刻了解 JVM – 垃圾回收算法
和题目一样，介绍 JVM 的垃圾回收算法以及新生代老年代是如何使用算法进行回收的，须要留神的是这些垃圾算法没有好坏之分，所有看理论垃圾收集器开发者的设计理念。比方 CMS 还是典型的标记 - 革除，然而到了 G1 就是标记整顿了。
第六篇：深刻了解 JVM – CMS 收集器
讲述 CMS 收集器的手机细节，以及 CMS 的好搭档 ParNew 的一些解决细节，CMS+ParNew 置信还是少数公司的首选垃圾收集器。毕竟不是谁都有那么宏大的用户量或者大我的项目这种。
第七篇：深刻了解 JVM – 实战老年代优化
无需多介绍，内容和题目相似。
第八篇：深刻了解 JVM – G1 收集器
性能和应用看似都非常简略，然而内含的原理十分复杂，次要也是解说 G1 收集器的一些性能和细节点。
同时是否须要钻研原理这就看集体需要了，当然多懂点总是坏事。
第九篇：深刻了解 JVM – G1 调优简述
感觉齐全是水了一篇，能够不看，因为集体目前没遇到须要用上 G1 去调优的场景（=-=）
相干探讨
回收的说法我混同了？
Minor gc：中文翻译是主要 GC，主要这两个字很容易混同，然而少数状况是 新生代回收
Young gc：新生代回收
Full gc：少数人会认为是老年代回收，然而实际上和这个单词的含意不同，所以 full GC 应该相似于 全堆回收
Old gc：毫无疑问就是老年代回收
Major gc：重要 GC，当然这个词用的不多，如果不晓得的状况下默认为老年代 GC 即可。
Mixed gc：混合 GC，这个概念最开始应该是在 G1 才提到，值得是老年代和新生代以及大对象一起回收
零碎真正怕的是什么？
垃圾收集的 stop world 操作，然而能够显著的发现，新生代的回收简直是没有影响了，有 20ms 没法操作系统，简直没有几个人能够感知，就连咱们连一个网页都不止几秒的工夫，更不要说这渺小的感知了。
然而老年代的回收就不一样了，咱们假如老年代回收的工夫须要新生代的 10 倍，那就是 200ms，如同也是没啥感觉哈，然而如果是 2000ms，那问题就很大了，CPU 的处理速度如果须要进展 2S 那根本会让人误以为是程序出了问题，所以老年代的进展是不可容忍的。
零碎内存过大的问题：
如果采纳传统的分代模型作用于当初动辄上百 G 的服务，那么假如新老年代须要几十个 G 的内存，那么一次进展的工夫大略到了一分钟了，因为对象太多了，回收的效率直线降落。
因而超大内存的呈现也是 G1 收集器呈现的一个起因之一。
如何解决大内存零碎的垃圾回收问题？
应用 G1 收集器，该收集器首先会判断新生代是否占用的比率合乎进展模型的参数，此时须要依据参数判断是否须要进行解决，如果须要解决，则依据最大进展工夫进行垃圾回收、
其实实质上就是把原本触发条件回收变成了定时判断是否合乎垃圾回收的条件，有一点垃圾就回收一点，这样零碎能够失常运行，垃圾回收也能够尽可能的回收内存，并且只有垃圾回收的速度赶上调配速度，那么整个零碎是基本上不会有任何 JVM 问题的！
要命的老年代回收！
老年代回收必定是因为新生代出了问题，因为对象没有中央放得时候老年代必定就会执行了，老年代回收原本就比新生代慢十倍，加上频繁的老年代更加容易让零碎卡顿，让用户体验变得十分差。
之前总结过老年代回收的一些条件：
- 动静对象年龄判断：如果老年代的可用对象大于新生代，那么根本没有问题，然而一旦小于这个值，就须要校验一下老年代的最大间断空间是否大于历代降职老年代的均匀大小，如果是则执行 mior gc，如果不是此时老年代必定是放不下则须要进行 Full Gc 了，的。
- 对象年龄超过阈值：个别是 1 -15，留神也只有 1 -15，没有 23，25，26，30 这些参数，因为 Marking word 对象头只给了 4 位 1111 示意对象的年龄！
- 对象回收之后，存活的对象在老年代放不下了。
- CMS 并发回收的过程中一旦残余空间无奈调配，会呈现 concurrent mode fail 并且开启 Serrial 进行 Full gc。
如何抉择 cms+Parnew 还是 g1？
Parnew+cms：个别中小型的零碎对于零碎的性能要求不是很高，同时也不须要高同步和实时特色的时候应用
G1 收集器：如果是超大内存的零碎适宜应用 g1 的收集器。
什么时候触发永恒代回收？
永恒代回收的空间无限，少数状况下寄存了类变量和一些动态的常量或者.class 对象的援用信息，须要留神的是反射和动静代理对象是最容易引发永恒代溢出的，特地是古代框架少数应用反射加载对象，导致办法区一直呈现对象占用。办法去一旦回收根本都是 OOM.
一直创立动静代理对象也是测试方法区溢出成果的最好方法。
简直没有影响 young gc?
假如一个业务零碎是初期阶段，用户量不是很大，每秒大略也就 500 次申请，生产的对象大略也就是 50M 左右，假如大略 3 分钟就能把新生代填满，同时频繁的 young gc，然而会发现这一次 young gc 也就花了 20ms 简直是无奈被用户感知的。
然而少数状况下业务初期基本不须要调优 JVM。
另外，调优不要为了调优而调优，本人做的开源我的项目能够乱搞，然而公司拿来赚钱的我的项目是须要多方面思考的，切记。
系统升级后垃圾收集器的影响
假如一台小机器系统升级到 32 核 16G, 老年代和新生代占用 6G 左右，这时再应用分代回收的形式效率非常低了，所以咱们应用 G1 收集器进行垃圾的回收的工作并且让回收操作提前完成也是保障后续的计算工作不会造成卡顿或者阻塞。
写在最初
一直温习和回顾总结，常识能力学得更加可靠！
