制约程序性能的根源

常用的性能评估指标

并发：同一时间多少请求访问：如同一时间10个用户请求，并发就是10
TPS：transaction per second：相当于写操作
QPS：query per second：相当于读请求，从数据库读出写到缓存一般认为是QPS
耗时：
端到端耗时,从发起到结束，影响用户体验的耗时，包含了网络耗时；
服务端耗时，出去了公网的网络带宽，是机房内网串联的耗时；
应用程序耗时，摒弃了外围的存储，外围的数据库和外围的一些系统，单纯的应用程序的耗时，最小原子化耗时
95线：95%的请求落在什么范围内
99线：99%的请求落在什么范围内

制约程序性能的根源到处都在，可以分为以下几部分

网络
应用本身
数据库
缓存
消息
操作系统
内存
IO
CPU
程序计数器（线程私有，每个线程均有一个自己的程序计数器）
记录虚拟机字节码指令的地址（当前指令的地址，记录当前线程运行到了哪里）
java虚拟机栈
线程私有，每个方法（public,private等等）在执行的时候也会创建一个栈帧，存储了局部变量，操作数，动态链接，方法返回地址；靠入栈和出栈来完成
本地方法栈
和虚拟机栈类似，主要为虚拟机使用到的Native方法服务
堆
被所有线程共享的一块区域内存，在虚拟机启动的时候创建，用于存放对象实例（所有new的对象）。
方法区
用于存储已经被虚拟机加载的类信息class，常量，静态变量等
元数据区
替代永久代，类信息class，常量，静态变量等，字符串在1.7开始放到了堆中

GC算法

1.算法本质

标记-清除
优点：简单
缺点：碎片化，导致可能某一大对象可以存放，而被碎片化之后不能存放了
复制
优点：吞吐量高，无碎片化
缺点：空间利用率低
标记-整理
优点：兼顾了时间和空间问题
缺点：效率非最优
2.算法策略

分代GC回收算法

年轻代：复制算法
1.Eden（1个，新生代区），新创建对象首先放这里，达到一定阈值触发GC，首次GC把有引用的复制到随机一个Survivor区域如1，清空Eden； ,第二次触发GC时会把使用的Survivor1和Eden在使用的复制到另一个Survivor2中清空前一个有数据的Survivor1，第三次时会把Eden和第二次有数据的Survivor2复制到前面清空的Survivor1，然后清空Survivor2
2.Survivor（两个，幸存者区）
老年代：标记整理算法，15次的垃圾回收仍存活会从年轻代进入老年代。老年代快满之后会触发老年代的GC；老年代和年轻代同时快满时会触发FullGC
串行Serial,并行Parallel
CMS(Concurrent Mark-Sweep Collector)
1.Initial Mark初始标记：标记可直达的存活对象
2.Concurrent Mark并发标记：通过遍历第一阶段（Initial Mark）标记出来的存活对象继续递归遍历老年代，并标记可直接或间接达到的所有老年代存活对象
3.Concurrent Preclean并发预清理：将会重新扫描前一个阶段标记的Dirty对象直接或间接引用的对象，然后清除Card标识
4.Concurrent Abortable Preclean可中止的并发预处理：尽可能承担更多的并发预处理工作，从而减轻在Final Remark阶段的Stop-the-world,处理from和to区的对象，标记可达的老年代对象，并处理Dirty对象
5.Final Remark重新标记：重新扫描之前并发处理阶段的所有残留更新对象
6.Concurrent Sweep并发清理：清理所有未被标记的死亡对象，回收被占用的空间
7.Concurrent Reset并发重置：清理并恢复在CMS GC过程中的各种状态，重新初始化CMS相关数据结构
G1,jdk1.9默认
类似CMS的实现，保留了Initial Mark和Final Remark的两次Stop-the-world；内存空间默认做了优化，分单元区块，会去评审每一块区域的回收价值，确定那一块回收收益最高，控制垃圾回收的时间；每个区块都有rememberedSet(记忆集合) 管理自己区块所有内存使用的GCroot的状态即在做内存分配时就已经知道了内存内的现状，每个对象分别指向了什么对象，在做Final Remark时不需要跨区，减少路径扫描的时耗同事能更快的决策知道每个对象的分布

内存大小的取舍

1.扩大内存可以更少的触发GC
2.内存太大触发GC时候的停顿时间会长

因此要根据实际的业务场景设置一个“合适”的值，并配合压测和线上环境的实际情况不断调优；
达到：吞吐量=花在非GC停顿时间上的工作时间/总时间 >=95%

-Xms 启动JVM时堆内存的大小
-Xmx 堆内存最大限制
两者需要设置一样，防止扩缩容；

-XX:NewSize 年轻代大小,比老年代稍微大些
-XX:MaxNewSize 最大年轻代大小
两者需要设置一样，防止扩缩容；

-XX:SurvivorRatio 表示Eden survivor占比，默认为8，Eden 至少是survivor的两倍
Eden需要比Survivor尽可能的大，防止多次触发young gc导致年龄快速增长到可以进入老年代的case

-XX:MetaspaceSize元空间初始空间大小
-XX:MetaspaceSizey元空间最大空间，默认是没有限制的，不建议设置

GC优化

1.将进入老年代的对象减少到最低：可通过调整新生代的大小
2.young gc： 40ms以内
3.major gc：stop-the-world时间总和100ms以内：如果触发的不是特别频繁，可放到200ms甚至500ms以内
4.full gc ：尽可能少，且时间在1s内
除了cms和g1外其余的串行或并行的GC major gc=full gc

GC策略开启参数

jdk1.9之前建议使用cms;1.9之后默认G1
在这里插入图片描述

CMS变成Full GC条件，尽可能的减少

promotion failure ：由于内存碎片导致的晋升空间不足，发生在新生代往来年代晋升时
Concurrent mode failed：还未完成cms又触发了下一次major gc，发生在内存分配的速度比cms执行速度更短时

cms调优，整个调优看实验情况，具体使用如下参数之间取舍

-XX:ParallelGCThreads=N设置年轻代的并行收集线程数，避免docker踩坑；如果不配置JVM会获取当前主机上的CPU的核数来决策放多少线程数合适，早起版本在docker中读取的是物理机的并非是docker的核
-XX:ParallelCMSThreads=N设置cms的并行收集线程数，避免docker踩坑；清除老年代的并发的线程数，如果指定了上一个参数，这个参数可以根据第一个参数做线性调整，往往不需要设置此参数
-XX:+UseCMSCompactAtFullCollection FullGC情况下的Initial remark 或者Final remark都整理内存碎片
-XX:+CMSFullGCsBeforeCompaction=4 两次FullGC情况下的Initial remark 或者Final remark 4次后才整理内存碎片，与上一个参数配合使用，更好的权衡性能和内存的关系
-XX:+UseCMSInitiatingOccupancyOnly 让阈值驱动cms触发时机
-XX:+CMSInitiatingOccupancyFraction=70 表示老年代70%占满才触发cms；往往与上一个放一起使用，需要上一个参数开启使用防止jvm瞎搞，70较合理
-XX:+CMSParallelRemarkEnabled ：final remark阶段并行remark
-XX:+CMSScavengeBeforeRemark remark前先做一次major gc，为了将younggc的内容释放一部分