JVM 扫盲

1.JVM中运行的进程状态信息
jps [options] [hostid]
需要将JAVA_HOME/bin加入到path中
jps命令用来输出JVM中运行的进程状态信息
参数说明：
-q 只显示pid，不输出类名、Jar名和传入main方法的参数
-m 输出传入main方法的参数，在嵌入式jvm上可能是null
-l 输出main类或Jar的全限名
-v 输出传入JVM的参数
2.JVM区域划分
1）JVM区域总体分两类heap区和非heap区
heap区包含：Eden Space（伊甸园）、Survivor Space（幸存者区）、Tenured Gen（老年代-养老区）
非heap区包含：Code Cache（代码缓存区）、Permanent Generation（永久代）、Jvm Stack（Java虚拟机栈）、Local Method Stack（本地方法栈）
2）原理：一个对象被new出来后，会在Eden Space区中，直到GC来询问其是否有别的对象引用此对象，没有引用直接GC掉；如果有引用，就会进入到Survivor Space区；进入Survivor Space区的对象并不一定会保存很久，因为GC会继续询问其是否有对象引用，没有直接GC掉；如果有引用，就会进入到Tenured Gen区，进入到该区后，基本就安全了，但是如果没有别的对象引用其，仍然会被GC掉。
3）分区的目的：新生区由于对象产生的比较多并且大都是朝生夕灭的，所以直接采用标记-清理算法。而养老区生命力很强，则采用复制算法，针对不同情况使用不同算法。
4）非heap区域中Perm Gen中放着类、方法的定义，jvm Stack区域放着方法参数、局域变量等的引用，方法执行顺序按照栈的先入后出方式。
5）Permanent Generation区存放着虚拟机自己的静态数据，例如类和方法对象。Java虚拟机共享这些类数据。这个区域被分割为只读的和只写的。
6）Code Cache区：Java虚拟机包括一个用于编译和保存本地代码（native code）的内存，叫做”代码缓存区“。
7）JVM回收过程
对象在Eden Space中创建，当Eden Space快满了的时候，GC就把所有在Eden Space中的对象扫描一次，把所有有效的对象复制到第一个Survivor Space，同时把无效的对象所占用的空间释放。当Eden Space再次变满了的时候，就启动移动程序把Eden Space中有效的对此昂复制到第二个Survivor Space，同时，也将第一个Survivor Space中的有效对象复制到第二个Survivor Space。如果填充到第二个Survivor Space中的有效对象被第一个Survivor Space或Eden Space中的对象引用，那么这些对象就是长期存在的，此时这些对象将被复制到Permanent Generation。若垃圾收集器依据这种小幅度的调整收集不能腾出足够的空间，就会运行Full GC，此时JVM GC停止所有在堆中运行的县城并执行清除动作。
3.JVM参数解析
JVM中最大堆大小有三方面限制：相关操作系统的数据模型（32位还是64位）限制；系统可用虚拟内存限制；系统可用物理内存限制。在32为系统下，一班限制为1.5G~2G；64位操作系统对内存无限制
1）堆设置：
-Xmx3550m：设置JVM最大可用内存为3550M；
-Xms3550m：设置JVM初始内存为3550M。此值可以设置与-Xmx相同，以避免每次垃圾回收完成户JVM重新分配内存；
-Xmn1280m：设置年轻代大小为1280M，此处大小是Eden Space（伊甸园）+ Survivor Space（幸存者区），整个堆大小=年轻代+老年代+持久代。增大年轻代后，会减少老年代的大小，官方推荐配置大小为整个堆的3/8。
-XX:PermSize：设置持久代（Permanent Generation）初始值，建议物理内存的1/64；
-XX:MaxPermSize：设置持久代的最大值，建议物理内存的1/4；
-Xss：设置每个线程的大小，以前每个线程堆栈的大小为256K，JDK5.0以后每个线程大小为1M。减少此值可以生成更多的线程，但是线程数有限制，3-5千。一般的应用256K够用；
-XX:NewRatio：年轻代和老年代的比值，如果值为3表示年轻代与老年代的比值为1:3，年轻代占整个堆栈的1/4，如果Xms=Xmx并且设置了Xmn的情况下，可以不设置此参数；
-XX:SurvivorRatio：Eden区与Survivor区的比值，设置为6，则表示两个Survivor区与一个Eden区的比值为2:6，一个Survivor区占整个年轻代的1/8；
-XX:LargePageSizeInBytes：指定Java heap的分页页面内存的大小，不可设置过大，会影响Permanent的大小，推荐128M；
-XX:+UseFastAccessorMethods：原始类型的快速优化，get和set方法转成本地代码；
-XX:+DisableExplicitGC：禁止Java程序中的Full GC，例如System.gc()的调用，加上可防止程序在代码里的误用；
-XX:MaxTenuringThreshold：指定一个对象在经历了几次Young GC后转移到老年代中，64位的操作系统默认值为15，表示经过15次GC后进入老年代，此值如果设置为0，则表示年轻代对象不经过Survivor区，直接进入老年代。
-XX:+AggressiveOpts：加快编译，提升性能，同时也需要考虑到性能提升所带来的不稳定风险；
-XX:+UseBiasedLocking：锁机制的性能改善，使得锁更偏爱上次使用到它的线程，在非竞争锁的场景下，即只有一个线程会锁定对象，可以实现近乎无所的开销；
-XX:PretenureSizeThreshold：对象超过多大值时，直接进入老年代，单位是字节；
-XX:TLABWasteTargetPercent：TLAB占eden区的百分比，Sun Hotspot JVM为了提升对象内存分配的效率，对于所创建的线程都会分配一块独立的空间，TLAB（Thread Local Allocation Buffer），其大小由JVM根据运行的情况计算而得，在TLAB上分配对象时不需要加锁，因此JVM在给线程的对象分配内存时会尽量的在TLAB上分配，在这种情况下JVM中分配对象内存的性能和C基本是一样高效的，但如果对象过大的话则仍然是直接使用堆空间分配，TLAB仅作用于新生代的Eden Space，因此在编写Java程序时，通常多个小的对象比大的对象分配起来更加高效；
-XX:+CollectGen0First：Full GC时，是否先Young GC；
2）收集器设置
-XX:+UseSerialGC：设置串行收集器
-XX:+UseParallelGC：设置并行收集器
-XX:+UseParalledlOldGC：设置并行年老代收集器
-XX:+UseConcMarkSweepGC：设置并发收集器，使用CMS内存收集器，CMS收集器是JAVA虚拟机中垃圾收集器的一种。它运行在JAVA虚拟机的老年代中。CMS是（Concurrent MarkSweep）的首字母缩写。CMS收集器是一种以获取最短回收停顿时间为目标的收集器。比较适用于互联网等场合，可能是互联网中最重要的收集器模式；
-XX:+CMSParallelRemarkEnabled：降低标记停顿，为了减少第二次暂停的时间，开启并行remark: -XX:+CMSParallelRemarkEnabled，如果Remark还是过长的话，可以开启-XX:+CMSScavengeBeforeRemark选项，强制Remark之前开始一次Minor GC，减少Remark的暂停时间，但是在Remark之后也将立即开始又一次Minor GC；
-XX:+UseCMSCompactAtFullCollection：使用并发收集器时,开启对年老代的压缩；
-XX:+UseCMSInitiatingOccupancyOnly：使用手动定义初始化定义开始CMS收集，禁止hotspot自动触发CMS GC；
-XX:CMSInitiatingOccupancyFraction=70：使用cms作为垃圾回收，70％后开始CMS收集，建议参照CMSInitiatingOccupancyFraction计算公式；
3）垃圾回收统计信息
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:filename
4）并行收集器设置
-XX:ParallelGCThreads=n：设置并行收集器收集时使用的CPU数。并行收集线程数。
-XX:MaxGCPauseMillis=n：设置并行收集最大暂停时间
-XX:GCTimeRatio=n：设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)
-XX:+CMSIncrementalMode：设置为增量模式。适用于单CPU情况。
4.调优总结
1）年轻代大小选择
响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。
2）年老代大小选择
响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：
并发垃圾收集信息
持久代并发收集次数
传统GC信息
花在年轻代和年老代回收上的时间比例
减少年轻代和年老代花费的时间，一般会提高应用的效率
3）吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。
4）较小堆引起的碎片问题
因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：
-XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
-XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩