这里有个有趣的始建波动发生在循环6那里：实际上那是因为Hotspot的动态反优化启动。然后时间波动回到原来状态，优化结束。
Hotspot已经被全世界的开发者和拥趸支持了近十年，Java 4, 5, 6之间的提升让人印象深刻。每一次它的升级，性能都会有很多提升，它真是的是JVM的一大利器。
垃圾回收Garbage Collection (GC)
Java开发者花费大量时间来调试、测试、提高他们的VM，单是Garbage Collection的开发和维护就持续了15个年头，由此可见它的性能！而且JVM发布了多个垃圾回收器，所以这样一来即使加载的负荷超过了JVM中一个Garbage Collection，JVM也还可以允许你使用其他的Garbage Collection。因此，你可以自己调整任何你所使用的Garbage Collection，使之符合你的应用。
各种各样的回收站发挥着不同的作用。它们全部是压缩过的，所以不必担心存储的问题。它们都是增量型的（incremental）以缩短GC停滞的时间；它们还是分代的（generational），所以短时对象（short-lived object）回收得更快。有些是并行的，从而回收工作可以在多个核上分开运行；甚至还有同时发生的Garbage Collection，这样就没有了停滞时间。JRuby可以免费得到这些，现在的Java 7以及Java 6的u12，甚至还有一个新的G1回收站。
关于GC和JVM还有两个很巧妙的地方，从中可以获悉GC运行虚拟化和信息的情况。第一个是-J-verbose:gc flag，从中可以得到回收事件发生的时间、数量以及花费的时间，这可以让我们获悉垃圾回收器处理工作负载的好坏状况：
你可以记录这些事件并且计算出清理垃圾所需的总时间，还可以计算出你加载的工作负荷是否超过了回收器的能力，这可以帮助改变你的设计并通过调节堆栈大小来适配回收器。
第二个是通过jconsole查询JVM状况。Jconsole可以从许多角度查看系统，而且有一个很棒的memory tab来展示GC的运行状况，如下：
在右下角你可以看到绿色的框格，从中可以看到不同的生成占存储的多少。比如说你看到一个近乎满的survivor 生成，那意味着慢的满GC收集时刻，那么意思就是说这个应用可能不是很健全。这里有个有趣的始建波动发生在循环6那里：实际上那是因为Hotspot的动态反优化启动。然后时间波动回到原来状态，优化结束。
Hotspot已经被全世界的开发者和拥趸支持了近十年，Java 4, 5, 6之间的提升让人印象深刻。每一次它的升级，性能都会有很多提升，它真是的是JVM的一大利器。
垃圾回收Garbage Collection (GC)
Java开发者花费大量时间来调试、测试、提高他们的VM，单是Garbage Collection的开发和维护就持续了15个年头，由此可见它的性能！而且JVM发布了多个垃圾回收器，所以这样一来即使加载的负荷超过了JVM中一个Garbage Collection，JVM也还可以允许你使用其他的Garbage Collection。因此，你可以自己调整任何你所使用的Garbage Collection，使之符合你的应用。
各种各样的回收站发挥着不同的作用。它们全部是压缩过的，所以不必担心存储的问题。它们都是增量型的（incremental）以缩短GC停滞的时间；它们还是分代的（generational），所以短时对象（short-lived object）回收得更快。有些是并行的，从而回收工作可以在多个核上分开运行；甚至还有同时发生的Garbage Collection，这样就没有了停滞时间。JRuby可以免费得到这些，现在的Java 7以及Java 6的u12，甚至还有一个新的G1回收站。
关于GC和JVM还有两个很巧妙的地方，从中可以获悉GC运行虚拟化和信息的情况。第一个是-J-verbose:gc flag，从中可以得到回收事件发生的时间、数量以及花费的时间，这可以让我们获悉垃圾回收器处理工作负载的好坏状况：
你可以记录这些事件并且计算出清理垃圾所需的总时间，还可以计算出你加载的工作负荷是否超过了回收器的能力，这可以帮助改变你的设计并通过调节堆栈大小来适配回收器。
第二个是通过jconsole查询JVM状况。Jconsole可以从许多角度查看系统，而且有一个很棒的memory tab来展示GC的运行状况，如下：
在右下角你可以看到绿色的框格，从中可以看到不同的生成占存储的多少。比如说你看到一个近乎满的survivor 生成，那意味着慢的满GC收集时刻，那么意思就是说这个应用可能不是很健全。 移植性
无论是GC还是Hotspot都可以用在任何Java可用的地方。比方说，JRuby可以运行在其他平台上，Rails应用就可以运行在IBM主机上的JRuby上，而且这台IBM主机运行的是CP/CMS。
实际上，由于Java和OpenJDK项目的开源，我们正在看到越来越多的平台的衍生，因此JVM的移植性也将越来越棒。
成熟
JVM已有超过15年的历史，在过去的这些年里，许多开发者为它做出了许多贡献，使得它的性能一次又一次地提升，让JVM变得更加稳定、快速和广泛。
覆盖面
JRuby和JVM上的其他语言项目已经被开发者所承认，一个典型的例子是invokedynamic specification (aka JSR292)。JSR越来越配合新的语言，JVM已不再是Java一个人定制规则。JVM正在构建成为类如JRuby等项目的优良平台。
还有一个MLVM（multiple language VM）项目，好比是新特性的清算机构，是一个许多企业应用的开发者试图添加应用的地方，而这些应用正是他们想在JVM中看到的。而且JVM开发者互相协作、彼此影响，无疑这有利于JVM新特性的诞生。
这些细节都可以看到JVM正在关注开发者的需求，扩大他的覆盖面。
总之，JVM已经成为技术界越来越稳定的产品，Oracle/Sun的合并以及其他可能的商业闹剧都不会影响这一点。许多技术大鳄级公司（如Oracle、IBM、HP、SAP）已经为编写JVM的中间软件花了如此多的钱以至于在下个十年里他们可能不会再为JVM的发展做太大的贡献。
