八股文----JVM调优

JVM 调优小结JVM参数调优实际上没有具体的答案，要根据不同的实战场景进行对应的设置，还需要不断的调试和磨合，设置的不好，JVM不断执行Full GC，导致整个系统变得很慢，网站停滞时间能达10秒以上，这种情况如果没隔几分钟就来一次，自己都受不了。这种停滞在测试的时候看不出来，只有网站pv达到数十万/天的时候问题就暴露出来了。
所以对于JVM调优的话术，我们可以这么说，结合我们公司之前的经验，对于JVM调优我们可以从下面方向进行分析：
互联网项目 64 Linux Centos6.5 8GB

1：如果服务器硬件性能足够，建议采用64位操作系统，Linux下64位的jdk比32位jdk要慢一些，但是吃得内存更多，吞吐量更大。

2：XMX和XMS设置一样大，MaxPermSize和MinPermSize设置一样大，这样可以减轻伸缩堆大小带来的压力。

3: -Xmn年轻代的大小， 并行：吞吐量 并发：低延迟
-XX:NewRadio年轻代和年老代的比值，
Sun建议 年轻代与年老代的比例：3/8


4: 垃圾回收器的选择：

响应时间优先的应用:并发收集器 ParNew + CMS（老年代） 或者 G1
+ Serial Old (STW)

吞吐量优先的应用：并行收集器 Parallel Scavenge + Parallel Old
使用并发收集器，肯定就是追求最小的响应时间，所以应该减少年轻代，加大年老代，这样可以利用年老代的并发CMS收集器来减少响应时间。
使用并发收集器，一般是最求吞吐量优先的应用，会加大年轻代，缩小年老代。这样可以在年轻代回收掉大部分短期对象，减少中期对象，而老年代只存少部分长时间存活的对象。
（年老代的并发收集器使用标记,清除算法,所以不会对堆进行压缩.当收集器回收时,他会把相邻的空间进行合并,这样可以分配给较大的对象.但是,当堆空间较小时,运行一段时间以后,就会出现"内存碎片",如果并发收集器找不到足够的空间,那么并发收集器将会停止,然后使用传统的标记,清除方式进行回收.如果出现"碎片",可能需要进行如下配置:
-XX:+UseCMSCompactAtFullCollection:使用并发收集器时,开启对年老代的压缩.
-XX:CMSFullGCsBeforeCompaction=0:上面配置开启的情况下,这里设置多少次Full GC后,对年老代进行压缩
）

5：调试的时候设置一些打印参数
如： -XX:+PrintClassHistogram
-XX:+HeapOnOutOfMerroryError
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintHeapAtGC
-Xloggc:log/gc.log
这样可以让jvm虚拟机打印出类加载的情况，堆转储的快照，GC的详细回收日志 等等日志信息

6：当系统发生停顿的时候可能是GC的问题也可能是程序的问题，还有内存飙高，系统响应慢的时候，多利用jvm的监控工具实时注意jvm虚拟机的情况。 如可以通过jmap转储堆内存情况，通过jstack可以打印出线程的快照，在通过JProfiler或者JVisoulVM的分析工具进行分析。 – 这里可以加入JVM调优案例

7：仔细了解自己的应用，如果用了缓存，那么年老代应该大一些

8：垃圾回收时promotion failed是个很头痛的问题，一般可能是两种原因产生
第一个原因是救助空间不够，救助空间里的对象还不应该被移动到年老代，但年轻代又有很多对象需要放入救助空间；第二个原因是年老代没有足够的空间接纳来自年轻代的对象；这两种情况都会转向Full GC，网站停顿时间较长。
第一个原因我的最终解决办法是去掉救助空间，
设置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可

第二个原因我的解决办法是设置CMSInitiatingOccupancyFraction为某个值（假设70），这样年老代空间到70%时就开始执行CMS，年老代有足够的空间接纳来自年轻代的对象。
服务器服务器： centos 6.4 linux64位操作系统 8G内存： 70~80

B/S 低延迟 并发垃圾收集 CMS

每日百万PV，无压力：

$JAV{A}_{A}RGS.="-Dresin.home=$SERVER_ROOT
-server
-Xms6000M //堆初始值内存
-Xmx6000M //堆的最大内存 8G 70%
-Xmn500M //新生代内存 CMS 老年代 3 / 8
-XX:PermSize=500M //永久代初始值 M
-XX:MaxPermSize=500M //永久代最大值
-XX:SurvivorRatio=65536 //新生代救助区和Eden区比值这么设置实际上是去掉救助区
-XX:MaxTenuringThreshold=0 //新生代对象晋升老年的代年龄，设置0
-Xnoclassgc //不开启class收集
-XX:+DisableExplicitGC //禁止 System.gc()显示调用，防止手残党
-XX:+UseParNewGC //年轻代垃圾收集器 ParNewGC
-XX:+UseConcMarkSweepGC //年老代垃圾收集器 CMS
// ParNew + CMS (老年代) + Serial Old (担保) STW
// CMS 无法收集时 会使用串行收集器
// 标记 清除 会产生内存碎片
-XX:+UseCMSCompactAtFullCollection //开启内存压缩功能
-XX:CMSFullGCsBeforeCompaction=0 // 几次FullGC后出发碎片清理
-XX:+CMSClassUnloadingEnabled //开启永久代回收
-XX:-CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=80 //老年代占用多少时 进行老年代回收
// 调优参数的打印
-XX:+PrintClassHistogram //打印class加载信息
-XX:+PrintGCDetails //打印GC详细信息
-XX:+PrintGCTimeStamps //打印GC时间戳信息
-XX:+PrintHeapAtGC //打印GC 堆的信息
-Xloggc:log/gc.log "; // GC的日志的地址

综合浏览量（PV）：即Page View, 即页面浏览量或点击量，用户每次刷新即被计算一次。
并发连接数 = PV / 统计时间 * 页面衍生连接次数 * http响应时间 * 因数 / web服务器数量
页面衍生连接次数: 一个HTML页面可能会请求好几次http连接，如外部的css, js,图片等,可以估算一下，或者用10,可根据实际情况改变
http响应时间: 可以使用1秒或更少,可根据实际情况改变
因数: 一般使用5即可,可根据实际情况计算后推出
web服务器数量: web服务器数量

(1000000PV / 86400秒 * 5个派生连接数 * 2秒内响应 * 5倍峰值) / 1台Web服务器 约 600左右并发~1000

有没有在生产环境下进行过JVM调优，说说过程?

基于 jps + jmap + jprofiler 内存溢出问题排查, 使用 -Xmx -Xms设置调整堆大小
基于 Jps + jstack + jconsole cpu飙高问题排查, 通过对栈快照定位代码问题
TOP
TOP -p java进程ID H
jstack 通过上面查询的线程ID定位到出现问题的线程
基于 JVM 参数调优

常用的 JVM 性能监控的工具？

JDK 自带了很多监控工具，都位于 JDK 的 bin 目录下，其中最常用的是 jconsole 和 jvisualvm 这两款视图监控工具。
jps jinfo jstat jmap jstack
jconsole：用于对 JVM 中的内存、线程和类等进行监控；
jvisualvm：JDK 自带的全能分析工具，可以分析：内存快照、线程快照、程序死锁、监控内存的变化、gc 变化等
idea + jprofiler内存分析

常用的 JVM 调优的参数都有哪些？

-Xms2g：初始化推大小为 2g；
-Xmx2g：堆最大内存为 2g；
-Xmn500M 设置年轻代为500m;
-XX:PermSize=500M ； 1.8之后采用 MetaspaceSize
-XX:MaxPermSize=500M ； 1.8之后采用 MaxMetaspaceSize
-XX:NewRatio=4：设置年轻的和老年代的内存比例为 1:4；
-XX:SurvivorRatio=8：设置新生代 Eden 和 Survivor 比例为 8:2；
–XX:+UseParNewGC：指定使用 ParNew + Serial Old 垃圾回收器组合；
-XX:+UseParallelOldGC：指定使用 ParNew + ParNew Old 垃圾回收器组合；
-XX:+UseConcMarkSweepGC：指定使用 CMS + Serial Old 垃圾回收器组合；
-XX:+PrintGC：开启打印 gc 信息；
-XX:+PrintGCDetails：打印 gc 详细信息。
-XX:MaxDirectMemorySize : 设置直接内存的大小