共计 1567 个字符，预计需要花费 4 分钟才能阅读完成。
先阐明下这里是测试环境试验, 并且 JVM 调优要依据我的项目和运行理论状况来进行调整, 极其状况不可循序渐进
测试环境如下:1 个 1 核 2 线程的 CPU(2 个逻辑 CPU)，8G 内存，JDK:1.7，tomcat:8.5.70，JVM 参数为默认
先在 catalina.sh 中增加参数打印 GC 信息到日志文件
JAVA_OPTS=”-XX:+PrintGCDetails -Xloggc:/opt/logs/gc.log”
优化项 1
默认状况堆最小空间和最大空间不统一，为了防止每次垃圾回收实现后 JVM 从新分配内存，调整为统一，默认最小为总内存 1 /64，最大为 1 /4 通过计算有肯定偏差, 手动设置为最小和最大都为 2G
JAVA_OPTS=”-Xms2G -Xmx2G -XX:+PrintGCDetails -Xloggc:/opt/logs/gc.log”
启动后通过 jstat -gc -h 10 pid 1s 查看 pid jvm 中各空间应用状况 1 秒刷新一次 保留 10 行
发现 S1 大小在 YOUNG GC 后会发生变化，通过材料查问发现可能是主动调整性能(猜想)
(猜想) S1 应用过程中, 将上一次复制过去的数据清理后存活的大小按肯定比例寄存, 即: 不占据过多空间。S0 应用过程中, 将 S1 扩容至 S0 大小, 避免 S0 和 Eden 数据复制过去再大幅度扩容
我增加了 -XX:SurvivorRatio=8 让 S0 和 S1 同样大小 占年老代 1 /10, 这样 young GC 后 S0 S1 容量不再发生变化, 便于调试变动的值
内存调配到这里完结了, 上面就是垃圾回收器的抉择, 官网 JDK7 这方面形容的比拟少, 这里参考 8 的官网文档摸索一下
垃圾回收器次要思考在老年代的回收, 因为青年代大部分不到 15 岁就被革除了(一次 young gc 算一岁, 默认 15 次)
CMS(Concurrent Mark Sweep) 次要用于老年代的垃圾回收, 年老代仍实用串行或并行的形式进行垃圾回收, 相比于并行收集器, 采纳并发标记来缩小 STW 工夫。但同样有肯定的毛病，比方老年代革除后有空间碎片，如果有一个大对象进入老年代，没有间断的空间进行过存储，将进行一次不必要的 Full GC, 而且在并行标记时也会占用更多的 CPU。
革除步骤如下：
- 初始标记（CMS initial mark）：独占 CPU，stop-the-world, 仅标记 GCroots 能间接关联的对象, 速度比拟快；
- 并发标记（CMS concurrent mark）: 能够和用户线程并发执行，通过 GCRoots Tracing 标记所有可达对象；
- 从新标记（CMS remark）：独占 CPU，stop-the-world, 对并发标记阶段用户线程运行产生的垃圾对象进行标记修改, 以及更新逃逸对象；
- 并发清理（CMS concurrent sweep）：能够和用户线程并发执行，清理在反复标记中被标记为可回收的对象。
CMS 收集器在并发收集周期中两次暂停应用程序。第一个暂停是将可从根间接拜访的对象（例如，来自应用程序线程堆栈和寄存器的对象援用、动态对象等）和堆中的其余中央（例如，年老代）标记为流动对象。第一次暂停称为初始标记。第二次暂停呈现在并发标记完结时，它会在 CMS 收集器实现并发标记后查找因为应用程序线程更新对象中的援用而被并发跟踪脱漏的对象叫做从新标记。
G1(Garbage-First) 垃圾收集器是一种服务器式垃圾收集器，针对具备大内存的多处理器机器。它试图以高概率满足垃圾收集 (GC) 暂停工夫指标，同时实现高吞吐量。全堆操作（例如全局标记）与应用程序线程同时执行。这能够避免与堆或实时数据大小成正比的中断。其余的垃圾回收相比, G1 弱化了分代的状况, 用了 Region 的构造来代替新生代年轻代。
材料：
JAVA7 官网 JVM 调优白皮书
JAVA7 官网 JVM 参数
JAVA 各版本官网文档
CMS 垃圾回收器
G1 垃圾回收期
借鉴了大神的 CMS 与 G1 区别
