Java虚拟机JVM性能优化（一）:JVM知识总结

Java应用程序是运行在JVM上的，但是你对JVM技术了解吗？这篇文章（这个系列的第一部分）讲述了经典Java虚拟机是怎么样工作的，例如：Java一次编写的利弊，跨平台引擎，垃圾回收基础知识，经典的GC算法和编译优化。之后的文章会讲JVM性能优化，包括最新的JVM设计——支持当今高并发Java应用的性能和扩展。

如果你是一个开发人员，你肯定遇到过这样的特殊感觉，你突然灵光一现，所有的思路连接起来了，你能以一个新的视角来回想起你以前的想法。我个人很喜欢学习新知识带来的这种感觉。我已经有过很多次这样的经历了，在我使用JVM技术工作时，特别是使用垃圾回收和JVM性能优化时。在这个新的Java世界中，我希望和你分享我的这些启发。希望你能像我写这篇文章一样兴奋的去了解JVM的性能。

这个系列文章，是为所有有兴趣去学习更多JVM底层知识，和JVM实际做了什么的Java开发人员所写的。在更高层次，我将讨论垃圾回收和在不影响应用运行的情况下，对空闲内存安全和速度上的无止境追求。你将学到JVM的关键部分：垃圾回收和GC算法，编译优化，和一些常用的优化。我同样会讨论为什么Java标记这样难，提供建议什么时候应该考虑测试性能。最后，我将讲一些JVM和GC的新的创新，包括Azul's Zing JVM, IBM JVM, 和Oracle's Garbage First (G1) 垃圾回收中的重点。

我希望你读完这个系列时对Java可扩展性限制的特点有更深的了解，同样的这样限制是如何强制我们以最优的方式创建一个Java部署。希望你会有一种豁然开朗的感受，并且能激发了一些好的Java灵感：停止接受那些限制，并去改变它！如果你现在还不是一个开源工作者，这个系列或许会鼓励你往这方面发展。

JVM性能和“一次编译，到处运行”的挑战

我有新的消息告诉那些固执的认为Java平台本质上是缓慢的人。当Java刚刚做为企业级应用的时候，JVM被诟病的Java性能问题已经是十几年前的事了，但这个结论，现在已经过时了。这是真的，如果你现在在不同的开发平台上运行简单静态和确定的任务时，你将很可能发现使用机器优化过的代码比使用任何虚拟环境执行的要好，在相同的JVM下。但是，Java的性能在过去10年有了非常大的提升。Java产业的市场需求和增长，导致了少量的垃圾回收算法、新的编译创新、和大量的启发式方法和优化，这些使JVM技术得到了进步。我将在以后的章节中介绍一些。

JVM的技术之美，同样是它最大的挑战：没有什么可以被认为是“一次编译，到处运行”的应用。不是优化一个用例，一个应用，一个特定的用户负载，JVM不断的跟踪Java应用现在在做什么，并进行相应的优化。这种动态的运行导致了一系列动态的问题。当设计创新时（至少不是在我们向生产环境要性能时），致力于JVM的开发者不会依赖静态编译和可预测的分配率。

JVM性能的事业

在我早期的工作中我意识到垃圾回收是非常难“解决”的，我一直着迷于JVMs和中间件技术。我对JVMs的热情开始于我在JRockit团队中时，编码一种新的方法用于自学，自己调试垃圾回收算法（参考 Resources）。这个项目（转变为JRockit一个实验性的特点，并成为Deterministic Garbage Collection算法的基础）开启了我JVM技术的旅程。我已经在BEA系统、Intel、Sun和Oracle（因为Oracle收购BEA系统，所以被Oracle短暂的工作过）工作过。之后我加入了在Azul Systems的团队去管理Zing JVM，现在我为Cloudera工作。

机器优化的代码可能会实现较好的性能（但这是以牺牲灵活性来做代价的），但对于动态装载和功能快速变化的企业应用这并不是一个权衡选择它的理由。大多数的企业为了Java的优点，更愿意去牺牲机器优化代码带来的勉强完美的性能。

1.易于编码和功能开发（意义是更短的时间去回应市场）
2.得到知识渊博的的程序员
3.用Java APIs和标准库更快速的开发
4.可移植性——不用为新的平台去重新写Java应用

从Java代码到字节码

做为一个Java程序员，你可能对编码、编译和执行Java应用很熟悉。例子：我们假设你有一个程序（MyApp.java），现在你想让它运行。去执行这个程序你需要先用javac（JDK内置的静态Java语言到字节码编译器）编译。基于Java代码，javac生成相应的可执行字节码，并保存在相同名字的class文件:MyApp.class中。在把Java代码编译成字节码后，你可以通过java命令（通过命令行或startup脚本，使用不使用startup选项都可以）来启动可执行的class文件，从而运行你的应用。这样你的class被加载到运行时（意味着Java虚拟机的运行），程序开始执行。