1.JVM命令行选项：
HotSpot VM运行时系统解析命令行选项，并据此配置HotSpot VM，
HotSpot的命令行选项主要有3类：
A. 标准选项：
JVM规范要求所有的JVM都必须实现的选项，它们在发行版之间保持稳定，但也可能在后续的发行版中被废除。如：-client，-server等等。
B. 非标准选项：
以”-X”为前缀，不保证、也不强制所有JVM实现都必须支持，它可能未经通知就在发行版之间发生改变。如：-Xms，-Xmx等等。
C. 非稳定选项：
以”-XX”为前缀，通常是为了特定需要而对JVM的运行进行校正，并且可能需要有系统配置参数的访问权限，也可能不经通知就在发行版之间发生变动。如：-XX:+DisableExplicitGC，-XX:+AggressiveOpts等等。
命令行选项用于控制HotSpot VM的内部变量，每个变量都有类型和默认值。对于内部变量为布尔类型的选项来说，只要在HotSpot VM命令行上添加或去掉它就可以控制这些变量。对于带有布尔标记的非稳定选项来说，选项名前面的”+”或”-”表示true或false。
对于形如-XX:OptionName=<N>的非稳定选项来说，几乎所有附加选项为整数的选项，整数后面都可以接后缀k、m、g，表示千、百万和十亿。
2.32位与64位JVM：
早期的HotSpot VM是32位JVM，内存地址空间限制为4G，但是实际java堆的大小还进一步受限于底层操作系统，随着服务器系统的内存越来越大，64位HotSpot VM应运而生，它可以突破内存地址空间为4G的限制，可以使JVM使用更多的内存，但是随之而来的是64位JVM也带来了性能损失：HotSpot VM内部java对象表示(称为普通对象指针，Ordinary Object Pointers，oops)的长度从32位变为64位，导致CPU高速缓存行(CPU Cache Line)中可用的oops变少，从而降低了CPU缓存命中率，因此导致64位JVM性能通常比32位JVM性能下降约8%~15%。
为了改善64位JVM性能，OpenJDK和HotSpot VM添加了称为压缩指针(Compressed oops)的新特性，使用-XX:CompressedOops命令行选项开启，使得64位JVM性能等于甚至高于32位JVM。
压缩指针是通过对其(Alignment)和偏移量(Offset)将64位指针压缩为32位，即使用了更小更节省空间的压缩指针代替完整长度的64位指针，使得CPU缓存使用率得以提高，从而提高了性能。
此外，在某些平台上(Intel或AMD x64)，64位JVM可以使用更多的CPU寄存器，避免寄存器卸载(当活跃状态即变量数目超过CPU寄存器时，多出的活跃状态只能存放在内存中，被称为寄存器卸载)，由于CPU寄存器的访问速度高于内存，因此避免寄存器卸载可以让程序运行的更快。
3.CMS垃圾收集过程：
CMS(Concurrent Mark-Sweep GC)是HotSpot VM中的Mostly-Concurrent垃圾收集器，它管理新生代的方式与Parallel收集器和Serial收集器相同，而它在老年代则是尽可能并发执行，每个垃圾收集周期只有两次短的停顿。CMS垃圾收集器分为以下阶段：
A.初始标记：
标记从GC Roots直接可达的老年代对象，需要短暂停顿。
B.并发标记：
标记从初始标记标记的老年代对象可达的存活对象。
C.并发预清除：
为了减少重新标记工作量，完成一些原本在重新标记阶段完成的工作，即重新遍历那些在标记期间因并发而被改掉的对象，可以非常有效地减少重新标记的停顿。
D.重新标记：
因为在并发标记期间应用可能正在运行并更新引用，所以到并发标记结束时，未必所有的存货对象都能确保被标记，因此需要重新标记，即重新遍历所有在并发标记期间有变动的对象并进行最后的标记，追踪更改的对象可以重用数据结构卡表，因为重新标记比初始标记更为重要，因此并发执行以提高效率，需要短暂停顿。
E.并发清除：
清除整个java堆，释放没有迁移的垃圾对象。
4.Throughput垃圾收集器输出日志详解：
使用Throughput垃圾收集器(JVM命令行选项：-XX:+UseParallelGC或-XX:+UseParallelOldGC -XX:+PrintGCDetails -verbose:gc)，垃圾收集器输出日志格式化如下：
(1).Minor GC日志详解：
[GC
[PSYoungGen: 15424K->640K(17280K)]
26822K->19050K(35712K), 0.0260617 secs]
[Times: user=0.06 sys=0.00, real=0.03 secs]
A.标签GC说明这是Minor GC的日志输出.
B.第2行[PSYoungGen: 15424K->640K(17280K)]是新生代信息，PSYoungGen表示新生代使用的是多线程垃圾收集器Parallel Scavenge(使用-XX:+UseParallelGC或-XX:+UseParallelOldGC自动开启)，”->”左边的26822K是垃圾收集前新生代的占用量，”->”右边的640K是垃圾收集后新生代的占用量。新生代进一步被分为Eden和2块Survivor，因为Minor GC之后Eden为空，所以此处的630K也是Survivor的占用量，括号中的17280K是Eden和一块正被占用的Survivor的和。
C.第3行26822K->19050K(35712K)是垃圾收集前后java堆(新生代和老年代的占用量总和)的使用情况，以及java堆的大小(新生代和老年代的总和)。”->”左边的26822K是垃圾收集前java堆的占用量，”->”右边的19050K是垃圾收集后java堆的占用量，括号中的35712K是java堆总量。
通过java堆大小和新生代大小可以计算出老年代大小，例如新生代大小为17280K，堆大小为35712K，则老年代大小=35712K - 17280K = 18432K.
D.第4行[Times: user=0.06 sys=0.00, real=0.03 secs] 是CPU使用时间，user是垃圾收集使用的用户态CPU时间，sys是垃圾收集使用的系统态CPU时间，real是垃圾收集实际执行时间。
(2).Full GC日志详解：
[Full GC
[PSYoungGen: 640K->615K(17280K)]
[PSOldGen: 18410K->18432K(32704K)]
19050K->19047K(49984K)
[PSPermGen: 2148K->2148K(12288K)], 0.0379846 secs]
[Times: user=0.03 sys=0.00, real=0.03 secs]
A.标签Full GC说明这是Full GC的日志输出。
B.第2行的PSYoungGen是新生代的信息，Full GC会对新生代、老年代和永久代都进行垃圾收集。
C.第3行的PSOldGen: 18410K->18432K(32704K)是老年代信息，PSOldGen表明老年代使用的是多线程垃圾收集器Parallel Old(通过-XX:+UseParallelOldGC开启),”->”左边的18410K是垃圾收集前老年代占用量，”->”右边的18432K垃圾收集后老年代占用量，括号中的32704K是老年代大小。
D.第4行19050K->19047K(49984K)是java堆的使用情况，与之前Minor GC的含义相同。
E.第5行PSPermGen: 2148K->2148K(12288K)]是永久代信息，PSPermGen表明永久代使用的是多线程垃圾收集器Parallel Old，”->”左边的2148K是垃圾收集前永久代占用量，”->”右边的2148K垃圾收集后永久代占用量，括号中的12288K是永久代大小。
F.第6行是垃圾收集CPU使用时间，与之前Minor GC的含义相同。
