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堆，释放没有迁移的垃圾对象。
