在VMware vSphere上优化企业Java应用的最佳实践和实用技巧。书中提供了高价值的优化技巧，可以运用于物理环境、虚拟环境和两者相结合的环境。介绍了如何合理地控制现有Java基础设施的规模，如何为新的应用提供现代化的体系结构，如何系统化基准测试，以及如何改进虚拟化Java性能的方方面面。

VMware公司首席架构师亲笔撰写，全方位解读在VMWare vSphere上优化企业级Java应用的最佳技术实践和实用技巧
从计算机硬件体系结构到Java虚拟机的内存管理优化，从内存数据库的设计到整个应用分层的部署，详细讨论Java平台虚拟化和调优的原则、策略和技巧，包含大量实例

后
Virtualizing and Tuning Large-Scale Java Platforms

现在企业已经不再询问“Java能不能虚拟化”这样的问题，而是“我们能够将虚拟化的Java应用平台扩展到多大？又该如何有效地对其进行调优？”在本书中，顶尖的Java虚拟化专家回答了这些问题，并提供了详尽的技术信息，你可以将这些技术信息用于任何生产或QA/测试环境。
最近9年以来，本书作者一直在虚拟化VMWare自身的企业级应用和300个VMWare重要客户的项目，这些项目的类型和规模各异——从100个JVM到10 000个以上JVM，堆内存从1GB到360GB，其中包括构建在集群JVM上的大数据应用。基于所有这些经验，作者展示了如何成功地划分和优化Java工作负载。
本书包含富有极高价值的优化技巧，可以将这些技巧应用于物理环境、虚拟化环境，或者两者组合的环境之中。你能够学到如何合理地扩展已有的Java应用基础设施，如何为新的应用提供现代化架构，如何进行系统的基准测试并在各个方面提升虚拟化Java的性能。
通过阅读本书，你将学到：
大规模Java平台相关的性能问题，包括合并、弹性和灵活性
Java平台中理论限制和物理限制的技术考量
使用VMWare　vFabric SQLFire构建水平的内存数据库，以提升可扩展性和响应时间
使用吞吐/并行GC和并发标记清除（CMS）技术优化大规模Java系统
设计和划分新的Java环境
从物理化部署环境迁移到虚拟化时，设计并划分新的大规模Java平台
为延迟敏感的内存数据库设计并划分Java平台
现实世界中的性能案例：SQLFire与RDBMS对比、基于Spring的Java应用、vFabric SpringTrader、应用层、数据层等
ESXi 3、4.1以及5的性能差异
每类工作负载的最佳实践：架构、性能、设计、大小划分以及高可用性
在负载均衡器层、Web服务器层、Java应用服务器层或DB服务器层识别瓶颈
借助esxtop解决复杂的vSphere Java性能问题
有关性能的FAQ：企业级用户所提问题的答案

前
本书由VMware公司首席架构师亲笔撰写，全方位解读在VMWare vSphere上优化企业级Java应用的最佳技术实践和实用技巧。作者通过丰富的实例，详细讨论分区设置以及大、小规模虚拟化Java平台的调优，可帮助vSphere和Java管理员快速理解并有效运用设计和优化策略。
本书共7章：第1章定义三类大规模Java平台并描述一些技术性考量因素；第2章介绍vFabric SQLFire的特性，详细描述现代化数据平台是如何构造的；第3章探讨如何最好地优化延迟敏感的JVM；第4章探讨设计和划分大规模Java平台的各种方式，包括借助纵向和横向测试确定最佳的Java平台规模；第5章通过一些性能研究案例，表明虚拟化Java平台可以在一个很大的规模上运行； 第6章介绍将大规模Java应用部署到VMware上的最佳实践，包括架构、性能、设计和规模划分，以及高可用性方面的最佳实践；第7章主要介绍在虚拟化Java平台中帮助你进行监控和问题排查的重要工具。附录中包含很多VMware客户所提出的问题，通读附录有助于读者快速提高技术水平。

后
作者简介
Emad Benjamin　VMware公司首席架构师，过去9年来一直关注VMWare vSphere、vFabric GemFire和SQLFire环境上的Java。Benjamin有20余年IT行业经验，其中包括16年使用Java的经验。他在虚拟化和Java的交叉领域有着深厚的背景知识，曾参与撰写《Enterprise Java Application Architecture on VMware》，并曾在VMWorld、SpringOne、UberConf和NFJS上发表过与Java虚拟化相关的演讲。

译者简介
张卫滨　毕业于天津大学，现为软件工程师、InfoQ社区编辑，熟悉Java语言，对Java开源框架（如Spring、Hibernate、Eclipse等）有一定的研究，目前主要致力于企业级软件的开发以及流程优化。译著有《Spring实战（第3版）》《Java应用架构设计：模块化模式与OSGi》和《Spring Data实战》。

文建国　系统架构设计师、高级项目经理、PMP，精通Spring等优秀开源技术在企业中的应用，主要研究方向为云计算、大数据、业务基础平台、分布式等技术。他曾参与中国电信ITSP3.0技术架构规范编写，有着多个大型云计算项目的架构和管理经验。他目前致力于移动互联网社区O2O平台的架构和研发。译著有《Spring Data实战》。

本书是9年来我在VMware vSphere上运行Java应用的经验结晶，这些经验来源于VMware本身以及VMware的众多客户。实际上，很多VMware客户都在VMware vSphere上运行企业级的核心Java应用，并取得了效果更好的总拥有成本（total cost of ownership，TCO）以及服务水平协议（service level agreement，SLA）。我的第一本书是《Enterprise Java Applications Architecture on VMware》（VMware上的企业级Java应用架构），在那本书中很好地阐述了Java虚拟化的主题，其中既包括高层次的架构视角，也包括深入介绍分区大小设置和最佳实践的技术章节。为了保证第一本书在价格上更为实惠，我将一部分章节放到了第二本书，也就是你现在读到的这本书中。这两本书在很多方面都是互补的。在第一本书中有一些高屋建瓴的章节，是针对架构师、工程师以及管理者的，他们第一次考虑虚拟化方案并且可能会问“为什么这样做”的问题。而本书是关于如何做和做什么才能调整至最佳性能的。
限制第一本书的范围是个不错的主意，这样能让第一次构建Java虚拟化项目的人快速读完该书。第一本书出版至今已经有近2年的时间了，从那时到现在，我已经收到了近300条读者的反馈，这些反馈有助于进一步分析书中所给出的指导建议。其中有些反馈涉及大规模的Java平台，这些反馈极大地丰富了本书中的细节。本书会详细讨论分区设置以及小规模和大规模虚拟化Java平台的调优—从100个Java虚拟机（Java Virtual Machine，JVM）到10 000个JVM，JVM堆的大小从1GB到128GB。我最近的经验以及过去15年来优化Java平台所取得的经验都包含在本书中，我将这些经验进行了总结，以一种最实用并且能够立即应用于多种Java负载类型的形式进行了阐述。你可以改进本书所给出的建议、部署配置以及垃圾收集（garbage collection，GC）的优化知识来应对糟糕的GC行为，或者在整体上设计并确定Java平台的规模。本书中所强调的最佳实践可以应用于物理环境、虚拟化环境或者两者组合的环境之中。
撰写本书的动力
在过去的9年中，我在VMware担任不同的职位以确保所有内部的企业级Java应用都被虚拟化，以此向VMware的客户展现这种方式所能带来的收益。就在那个时候，我开始相信我们在生产环境下根据试验数据所得到的最佳实践应该分享给VMware社区。我收到了很多的反馈，要求我将在VMware上运行企业级Java应用方面所学到的经验以及获取成功的各种技巧进行文档化。这就是写作第一本书《Enterprise Java Applications Architecture on VMware》（https://www.createspace.com/3632131）的动力。
延续了写作第一本书的动力，本书（也就是第二本书）主要关注要调整什么、能调整到什么程度以及大型虚拟化Java平台该是什么样子的。实际上，第一本书的内容回答了“为什么虚拟化”以及“要做什么/如何来实现虚拟化”的问题。而本书探讨了“你能虚拟化多大规模的应用以及你对平台能够优化到什么程度”。
写作第一本书是非常令人兴奋的，因为我们试图让VMware的广大用户群了解Java虚拟化是完全可行的并且能够带来很明显的收益。在这本书中，我们将为一些客户提供帮助，这些客户的诉求可能是“现在请帮助我们将规模提升到一个新的水平”。在过去的2年间，我们帮助客户虚拟化了很多大规模的JVM平台，有些甚至达到10 000个JVM，有些涉及大数据平台领域（在一组集群JVM之中，将多个TB的数据存放于内存之中）。在你深入学习本书之前，需要记住的一点是：尽管本书中展现了很多的最佳实践，这些实践代表了最佳的配置指导，但是这些并不是强制性的要求。按照经验，我们发现大多数企业级Java应用的虚拟化很容易，并不需要担心太多的特定配置。实际上，在各种类型的企业级产品化应用之中，Java应用是进行虚拟化的最佳候选，因为它很容易取得成功。通过分享我们的经验，希望能够帮助你避免在虚拟化大规模Java平台时我们曾经遇到过的陷阱。
为了阐述在虚拟化环境中部署Java平台有多么棒（同时也为了消除虚拟化平台会成为问题的误解），我们构建了同时适用于物理化与虚拟化环境的最佳实践。在设计上，本书包含了针对物理化和虚拟化Java平台的最佳实践，所以能够帮助读者在进行虚拟化之前，纠正他们在物理化Java平台中所遇到的问题。当然，这并不是强制性的要求，在迁移到虚拟化的时候，客户可以选择继续保留物理化Java部署时的遗留问题。但是，他们至少能够意识到其物理化Java平台在设计和部署上的不足，这是他们希望将来要进行修正的。
这样的经历是很重要的一个历练过程，能够让我们清楚地认识到：问题实际上存在于客户自己的物理化环境中。因此，客户能够理解维护物理化Java平台上遗留问题的成本。例如，我们经常发现很多Java物理化平台有着糟糕的架构和错误的拓扑结构，很多有着上千个混乱且不必要的JVM。当我们与这些客户交流时，不管他们是将Java应用部署在物理环境中还是迁移到虚拟化环境中，我们都会带领他们了解这些最佳实践并确保这些环境要进行正确地规模划分和调优。再强调一遍，客户可以忽视我们所给出的建议，对代码和平台不做太多的修改或变更就将遗留的Java物理化平台部署到对等的虚拟化环境之中。但是，在迁移到虚拟化平台时，客户最近越来越认识到我们（以及其他人）所给出的最佳实践对于提升Java部署范式的价值。
我们学到的经验教训分为以下几类：
在生产环境下，肯定会出错，出错只是一个时间问题。所以，你必须要一丝不苟地考虑哪里可能会出错并制定前滚（roll-forward）和回滚（rollback）计划。这个计划中的练习过程有助于进一步强化QA（质量保证）的测试计划。要注意的一点是，这并不是虚拟化环境所特有的。实际上，不管你处理的是物理化的还是虚拟化的基础设施，这都是同等严格的需求。但实际情况是，虚拟化为你提供了一种快速处理问题的机制（与之形成对比的是，在物理化场景下，你所能取得的灵活性会受到一定的限制，你必须围绕你所拥有的计算资源规划灵活性）。
当进行虚拟化的时候，企业级Java应用是最容易取得成功的。
每个人都在Java的各个分层中工作，这些分层了形成各种筒仓（silo），人们在技术和组织流程方面说着不同的术语。显然这是老式物理化（非虚拟化）范式下的做法，这些技术和组织上的筒仓是过去10多年来所形成的。但是，在VMware上虚拟化Java时，很重要的一个方面就是跨团队协作，它会驱动很多团队互相交流以促成最佳的设计。来自开发和运维的团队会多次坐到桌边进行讨论。
客户有时候会为其环境中遗留的问题进行辩解。由此导致的结果就是，客户需要付出额外的成本来管理物理环境中庞杂的JVM，如果不进行及时补救，这些成本也将会带到虚拟化系统中。例如，你真的需要5000个具备1GB堆空间的JVM吗？它们能够进行合并吗？它们绝对可以合并，我们将向你展示如何通过减少许可证成本以及提高管理效率（因为你需要管理的JVM更少）实现费用的节省。
性能问题。客户经常盲目地将所有问题都归咎于虚拟化或GC的问题。但实际上，虚拟化并不是什么问题，而GC有时候的确会成为问题。如果存在GC问题，这并不是虚拟化所特有的，实际上这样的问题通常在物理化部署环境中同样存在。
在物理化Java平台中，使用大内存数据库是否可行（确实可以达到1TB的内存集群）？绝对是可以的，如果主要的目标是不惜任何代价实现事务，同时还要实现尽可能快的速度，那么对你来说这是正确的架构。我发现很多客户对此持怀疑的态度。他们在对这些类型的环境进行规模划分时并没有考虑底层的平台，对于他们来说这是一个糟糕的开始。当对这些数据平台进行规模划分（稍后会进行讨论）时，你必须关注服务器的机器架构。在有些客户那里，我看到另外一个糟糕的实践就是他们试图将环境划分为30个左右的JVM。这并不是正确的方式，因为让众多JVM相互之间以较高的速度频繁交流可能会导致整体延迟更多。显然，这些都是对延迟敏感且依赖内存（memory-bound）的负载，使用数量更少且内存更大的JVM部署模式所取得的效果会更好。如果比较两种不同部署方式的内存数据库性能，其中一种使用30个JVM，另一种使用8个更大的JVM，你会发现8个更大JVM的配置方案会更好一些。当然，这里要提示的一点是，更大的JVM要针对NUMA进行正确的规模划分，并且要进行恰当的GC调优。
当虚拟化的时候，大的内存数据库方案真的可行吗？在过去的几年间，我们发现在客户中有一种日渐增长的趋势就是虚拟化Java应用服务器。具体来讲，就是具有几千个JVM的大规模平台正在被虚拟化。有一种特殊的负载类型，那就是内存数据管理系统，它需要TB级别的内存并且对延迟是敏感的。对于这些内存集群，我们发现尽管JVM的数量更少了，但它们会有较大的堆空间，通常JVM的大小是8～128GB（JVM的数量通常会少于12）。当然，12这个数字本身并没有什么魔力，少的话可以是3个，而多的话可以达到30个。但是，你所拥有的JVM越多，在延迟性方面出现风险的可能性就越大，这是因为会出现额外的网络传输。在本书后面，你会学习如何对这种负载进行规模划分和调优。
很多Java应用开发人员很了解开发过程，他们知道如何编写Java代码以及如何对JVM进行调优。但是，这些信息通常只存留在开发人员那里，并没有分享（或传递）给应用的管理人员。通常，运行Java平台所需要的技能在开发人员和管理人员之间是分割的，没有一个人能够完全理解这两个方面。但是，这种孤立式的理解正在发生着变化，因为有更多的人开始去理解如何编写和部署Java代码、调优JVM并认识虚拟化的各个方面和复杂的服务器硬件架构。所以本书的另外一个目标就是，当读者学习这些技能时，鼓励他们遵循这样的职业发展路径。
我非常真诚地希望本书能够帮助那些具有Java开发、基础设施运维以及虚拟化背景的人。你可以将本书作为应对日常情况的指导，也可以作为构建Java平台架构策略的帮助手册。
预备知识
本书假设读者已经在整体上了解Java、JVM GC、服务器硬件架构以及虚拟化技术。这里的知识都是关于运行大规模Java平台的。在深入学习本书的内容之前，你可能希望先学习一下虚拟化，但是大多数Java的高级专家借助本书就足以掌握关于虚拟化及虚拟化Java应用的知识。实际上，通过回答下面的这个问题就能掌握继续阅读本书所需的虚拟化背景知识。这个问题是一位刚刚接触虚拟化的人某一天提出的：“Java是不是能够独立于操作系统及hypervisor？”
本书假设读者已经掌握了一些关于Java语言特别是JVM架构的背景知识。本书尽可能地概述了JVM架构以及具体的调优方法，但是本书不能代替专门的JVM优化图书。我只想说，刚刚接触JVM调优的vSphere管理员能够从本书中学习到足够的知识，以便于他们与从事Java的同事进行技术交流。除此之外，vSphere和Java管理员可以使用并修改本书的调优建议，并将其应用于自己的环境之中。JVM调优建议的各个章节在编写上比同类图书更为简单易懂，目的是为了让vSphere和Java管理员能够快速了解并有效地运用设计和优化策略。众多运行Java应用的VMware客户使用本书中所讨论的优化参数并立即得到了性能方面的提升。
你首先需要知道些什么
你在阅读本书就意味着你正在修正你的Java平台。可能你已经得出这样的结论，那就是Java平台的调优不能被忽略或轻视。但是，即便你刚刚涉足VMware虚拟化或者是在物理化系统中对Java进行调优，那么本书也是适合你的。作为补习内容（对于刚刚接触这些领域的人来说也可以作为入门介绍），以下的章节简要介绍了虚拟化与大规模Java平台调优相关的重要概念。
4GB的Java堆是不是相当于新的1GB的Java堆呢，为什么
在过去的2年中，我参与了超过290个客户电话和研讨会，了解到很明显的一点是，运行在Java平台上的40%的工作负载都部署到1～4GB的JVM上。我进而发现有大量小于1GB的JVM，大约占到了我接触客户的另外40%。而剩余的20%范围在4～360GB之间。是的，这个360GB的JVM是一个监控系统，它不能够水平扩展，所以客户只能使用一个JVM。尽管这听起来有点令人难以置信，但这确实是Java产品化平台的现状。不过，使用1GB堆的JVM会导致JVM实例数量的膨胀，在自身的管理方面这会成为令人头痛的问题。例如，你可能希望提供共计1TB的堆空间，如果你只使用1GB的JVM堆，那么这就意味着你有几千个JVM实例。这可能带来什么问题呢？你是否能够通过250个4GB的JVM得到1TB呢？当然可以，但因为在你的组织中，依然存在来自于古老的32位JVM的遗留规则，所以你还得继续使用小于1GB的JVM。更为现实的原因是，人们广泛认为更大的JVM会导致更长时间的GC停顿。这种说法并不完全正确，但也并不能说完全错误。的确，这会产生更大的停顿，但是随着64位JVM以及CMS（concurrent mark-sweep）GC的最新发展，规模更大且停顿时间更少的JVM时代已经到来。不仅GC更好了，底层的服务器硬件也能够更好地支持4GB堆空间了。实际上，4GB是一个独特且具有魔力的数字，因为在64位的JVM中，为了节省内存的使用，JVM会自动将4GB的堆空间视为32位的地址空间。这样做之所以可行是因为32位的地址范围就是在4GB之内。实际上，使用-XX:+UseCompressedOops参数的JVM可以应用于高达32GB的Java堆空间之中。
在读完本书之后，你将会认识到适合更大JVM的可选方案和应用负载是存在的。显然，我并不是倡导每个人都使用更大的JVM，但是4GB的JVM现在真的不算大了。需要记住的是，我倡导的是更为合理的JVM数量，尽管这可能意味着增加堆的大小。另外需要记住的是，如果有供应商跟你说从32位的JVM迁移到64位的JVM时会牺牲性能的话，那么这是完全不对的。我们的压缩优化经验在很大程度上驳斥了从32位JVM迁移到64位JVM会导致性能下降的说法。例如，可以考虑这样的情景，为了提供1TB的服务，可以使用250个JVM，也可以使用1000个JVM。问一下供应商，如果不用运行750个JVM会节省多少成本（因为你将1GB的JVM堆迁移为4GB的JVM堆）。节省的成本可能会包括不再用到的750个GC周期，还有节省下来的CPU内核。因为不再需要为额外的许可证支付费用，在这方面你也能节省费用。
本书中后面的章节将会深入讨论各种规模的JVM以及在什么情况你应该选择某一种方案而不是另外的可选方案。
我为什么要费心去做虚拟化，主要收益是什么
大约5年前，我们还有客户询问“为什么虚拟化”这样的问题。不过近几年来，随着虚拟化变得更为标准，虚拟化所能带来的收益也被广泛理解和接受。标准是基于VMware虚拟化技术的，这很大程度上是因为它的健壮性以及第5代技术的成熟性。
虚拟化所能带来的主要收益如下所示：
成熟、已经过证实的综合平台：VMware vSphere （http://www.vmware.com/products/datacenter-virtualization/vsphere/overview.html）是第5代虚拟化技术（领先于其他可选方案很多年）。相比竞争对手的方案，它能够提供更高的可靠性、更为高级的功能以及更好的性能。
应用的高可用性：高可用性的基础设施依然是很复杂且昂贵的。但是VMware将健壮的可用性以及容错能力集成到了平台之中，从而能够保护虚拟化应用。一旦某一个节点或服务器出现故障，所有的VM会在另外一台机器上自动重启。
基于向导的使用指南简化了安装过程：VMware基于向导的使用指南简化了搭建和配置的复杂性。仅需要花费其他方案1/3的时间就让环境就绪并运行起来。
简单便捷的管理：VMware能够让你在Web浏览器上通过“统一界面的系统（single pane of glass）”来管理虚拟化和物理环境。有一些节省时间的特性，如自动部署、动态修补以及运行中的VM迁移，能够将常规任务的时间从数小时减少至几分钟。管理变得更加快捷和容易，从而能够在不添加人员的情况下提升生产效率。
更高的可靠性和性能：我们的平台将CPU和内存领域的创新与简洁、基于特定目的构建的hypervisor结合起来，它能够消除其他平台的频繁修补、维护以及I/O瓶颈。所带来的结果就是最好的可靠性以及持续的高性能（相对于最接近的竞争对手，对高负载的系统，我们能够带来2～3倍的性能优势）。
更好的安全性：VMware的hypervisor比任何竞争对手都小，只需要144MB，而其他竞争对手需要3～10GB的硬盘配置文件。我们的hypervisor占用的空间更少，因此对外部威胁来说，所面临的就是攻击面（attack surface）很小，并且受到了严格的保护，因而实现了密闭安全，入侵的风险要小得多。
节省了更多的成本：相对于其他的虚拟化方案，VMware为每台主机提高了50%～70%的VM密度—提升了每台服务器的利用率，从15%提升到最高80%。对比其他的平台，你能在更少的硬件上运行更多的应用，在资金和运营成本方面能够带来更多的节省。
可负担性：VMware在功能上是最强大的，但在成本上却并非最高的。起步价每台服务器165美元，一个小的商业组织可以将更多的应用打包到更少的服务器上，从而实现更高的性能—交付业界最低的总拥有成本（TCO）。
为了快速确定并对比在你的环境中部署VMware虚拟化的成本，可以使用VMware的应用成本计算器，参见http://www.vmware.com/go/costperappcalc。
从根本上来讲，因为Java是独立于操作系统的，并且它不依赖于任何硬件，所以它是完美的虚拟化可选对象。Java也能从很多的虚拟化特性中受益，如高可用性（high availability，HA）与VMotion（在不停机的情况下，将VM从一个vSphere主机迁移到另一个主机的能力）。虚拟化为Java平台所增加的这些灵活性对于通用的Java平台来说是很重要的，对于大规模的Java平台来讲更是如此。在大规模的Java平台中，我们经常会看到几千个JVM需要不断地进行管理（如，启动、停止以及在不停机的情况下进行更新）。如果没有虚拟化所带来的灵活性，如VMotion和HA，这种类型的管理活动无法适应如此大的规模。
企业级Java应用需要动态扩展性、快速供应（provisioning），对于如今的开发和运维团队来讲，HA正成为日益重要的关注点。完全基于传统硬件的平台来实现这些需求会非常复杂并且成本高昂。虚拟化是一种突破性的技术，它减轻了企业组织中常见的企业级Java应用需求所面临的压力。VMware vSphere套件所能实现的一些关键属性包括水平扩展性、垂直扩展性、快速供应、增强的HA以及业务持续性。第1章讨论了３种类型的大规模Java平台，你可以进一步了解这种系统的复杂性。
既然你已经了解了大规模Java平台需要虚拟化所带来的灵活特性，并且Java对操作系统的独立性使其成为工作负载虚拟化的首选，那么让我们仔细看一下Java与操作系统和hypervisor之间的独立性。
我应该虚拟化Java平台吗
对于那些没有时间完整阅读本节的读者来说，我可以简单回答：“是的，你应该进行虚拟化。”毕竟，Java独立于底层的hypervisor（如VMware的裸机hypervisor）和操作系统。不过对于那些想更深入了解这是什么意思的读者，请继续读下去吧。
Java的主要设计原则就是跨平台的语言，它独立于操作系统（只要有一个操作系统支持的底层运行时即可）。我们知道这种运行时也就是JVM，它已经成为众多企业级应用平台中固定的一部分。你可以编写Java应用，然后将其运行在不同操作系统的各种JVM之上（无须重新编译）。当然，很多VMware客户在生产环境下会使用特定供应商的JVM，所以他们不必担心将Java应用从一个JVM实现迁移到另一个实现。如果他们选择这样做，也很容易实现，这主要归因于JVM为Java所提供的跨平台以及操作系统独立性。
所以，你可以很容易得到这样的结论，那就是Java应用其实并不关心要运行在什么目标JVM上，它们独立于特定的JVM实现和操作系统。
当然，你可能会问，“那某一个JVM相对于其他JVM所提供的不同的内部行为该如何处理呢？”目前来讲，它们都符合JVM规范，尽管有一些JVM可选参数（-XX、标记等）有不同的名字，但是它们的行为都或多或少有些类似。差异并不体现在语言上，而在于Java的处理方式可以通过各种JVM可选参数进行优化，这些参数可以在Java命令行中传入。
现在我们快进到基础设施层面。VMware ESXi是裸机（bare-metal）hypervisor，能够在特定的硬件上运行多个操作系统。基础设施管理员不用再担心为某种硬件安装一种操作系统，而对另一种硬件要安装不同的操作系统。VMware使得操作系统的运行独立于底层的硬件（裸机），并且为操作系统与裸机/硬件建立了一定程度的独立性。
Java是否独立于OS与hypervisor，答案显然是肯定的，但这是两种不同级别的独立性。第一个级别是Java跨平台与独立于OS的原则，第二个级别是VMware ESXi hypervisor使操作系统独立于其所运行的硬件。实际上，Java应用运行在操作系统上，这个操作系统位于基于ESXi的VM之中，而ESXi并不关心运行在操作系统上的是不是Java工作负载，这样就使得ESX hypervisor完全独立于运行在它上面的工作负载。关于这一点的进一步佐证就是因为这种独立性，当你部署一个Java应用到VM上的时候，你并不需要对操作系统做任何的变更。
与之相应的是，JVM也并不知道它运行在ESXi hypervisor上的一个VM之中，对JVM来说，VM就像任何其他能够为其提供计算资源（CPU、RAM等）的服务器一样。
只要你的应用所运行的操作系统支持你所使用的JVM，就没有必要额外担心和依赖下游VM和ESXi层的支持。
图1描述了本节讨论的所有分层。

图1企业级Java应用运行在VMware ESXi虚拟化的VM上
谁应该阅读本书
本书的目标人群是IT专业人士，他们可能正在寻找产品化以及QA/测试环境中，在VMware vSphere上运行企业级Java应用的实现指南。
本书的前3章能够使CIO、VP、董事以及企业架构师从中受益，他们可能试图高屋建瓴地了解虚拟化Java应用的业务问题。剩余的章节是为那些想学习实现细节的开发人员和管理员准备的。
如何使用本书
本书包含7章、一个附录以及一个术语表：
第1章：本章介绍了各种类型的大规模Java平台并重点讲述了基于它们的规模，各自所需要的性能提升。
第2章：本章详细描述了现代化数据平台是如何构造的。
第3章：本章为IT架构师介绍了核心的关注因素以及参考指南，这些架构师需要调整企业级Java应用的规模并将其运行在VMware vSphere上。本章阐述了如何为运行在VMware vSphere上的Java应用实现最佳的配置。我们会指导你进行应用的基准测试，并指出如何进行测量、有哪些可调优的选项以及如何确定Java应用的最佳规模。
第4章：本章带领读者学习划分现代虚拟化Java平台大小的各种不同方式。读者会了解如何将垂直和水平可扩展性应用于大规模Java平台的方法论，而且还会看到确定应用规模的样例，这些样例可以用于产品化的系统中。
第5章：本章总结了一些核心关注点，这些内容来源于一些已发表的关于性能的文章。
第6章：本章提供了将大规模Java应用部署到VMware上的最佳实践，包括架构、性能、设计和规模划分，以及高可用性方面的最佳实践。这些信息能够帮助IT架构师成功地在VMware vSphere上部署并运行Java环境。
第7章：本章总结了当你在虚拟化Java时，如果遇到瓶颈或性能问题该怎么处理。在这个领域，它为你提供了很有用的总结。
附录：该附录中包含了很多VMware客户所提出的问题，这是作者多年来所遇到的。阅读FAQ有助于快速提高技术水平。
术语表
致谢
我首先要感谢我的妻子Christine以及我们的儿子Anthony和Adrian，感谢他们能够理解我在写作本书的过程中没有足够的时间陪伴他们。Christine，你是我动力的支柱，你总是能够理解和迁就我。
我要感谢我的父母，他们牺牲了很多来帮助我追求教育和职业方面的发展，感谢我的兄弟姐妹所给予的鼓励。我也要感谢Christine一家所给予的关爱和支持。
我要感谢我亲爱的朋友，His Grace Mar Awa Royel，他是Assyrian Church of the East的主教，感谢他的祝福。
我还要感谢GTS的副总裁Matt Stepanski以及GCOE的高级主管Steve Beck，他们不断的支持和鼓励促成了本书的出版。
我还想真诚感谢Michael Webster，他完整地审阅了本书。非常感谢他的热情和能力，他迅速及时地审阅了本书并做出了一些重要的变更。
我要感谢VMware的同事，正是他们帮助我把这本书变成了现实：Lyndon Adams、Mark Achtemichuk、John Arrasjid、Scott Bajtos、Stephen Beck、Channing Benson、Jeff Buell、Dino Cicciarelli、Blake Connell、Ben Corrie、Melissa Cotton、Bhavesh Davda、Scott Deeg、Carl Eschenbach、Duncan Epping、Jonathan Fullam、Alex Fontana、Filip Hanik、Bob Goldsand、Jason Karnes、Jeremy Kuhnash、Ross Knippel、Gideon Low、Catherine Johnson、Mark Johnson、Kannan Mani、Sudhir Menon、Justin Murray、Vas Mitra、Avinash Nayak、Mahesh Rajani、Jags Ramnarayan、Raj Ramanujam、Harold Rosenberg、Dan Smoot、Randy Snyder、Lise Storc、Matt Stepanski、Mike Stolz、Guillermo Tantachuco、Don Sullivan、Abdul Wajid、Sumedh Wale、Yvonne Wassenaar、Michael Webster、Mark Wencek、James Williams以及Matthew Wood。

计算机\程序设计

现在企业已经不再询问“Java能不能虚拟化”这样的问题，而是“我们能够将虚拟化的Java应用平台扩展到多大？又该如何有效地对其进行调优？”在本书中，顶尖的Java虚拟化专家回答了这些问题，并提供了详尽的技术信息，你可以将这些技术信息用于任何生产或QA/测试环境。
最近9年以来，本书作者一直在虚拟化VMWare自身的企业级应用和300个VMWare重要客户的项目，这些项目的类型和规模各异——从100个JVM到10 000个以上JVM，堆内存从1GB到360GB，其中包括构建在集群JVM上的大数据应用。基于所有这些经验，作者展示了如何成功地划分和优化Java工作负载。
本书中包含富有极高价值的优化技巧，可以将这些技巧应用于物理环境、虚拟化环境，或者两者组合的环境之中。你能够学到如何合理地扩展已有的Java应用基础设施，如何为新的应用提供现代化架构，如何进行系统的基准测试并在各个方面提升虚拟化Java的性能。

通过阅读本书，你将学到：
 大规模Java平台相关的性能问题，包括合并、弹性和灵活性
 Java平台中理论限制和物理限制的技术考量
 使用VMWare　vFabric SQLFire构建水平的内存数据库，以提升可扩展性和响应时间
 使用吞吐/并行GC和并发标记清除（CMS）技术优化大规模Java系统
 设计和划分新的Java环境
 从物理化部署环境迁移到虚拟化时，设计并划分新的大规模Java平台
 为延迟敏感的内存数据库设计并划分Java平台
 现实世界中的性能案例：SQLFire与RDBMS对比、基于Spring的Java应用、vFabric SpringTrader、应用层、数据层等
 ESXi 3、4.1以及5的性能差异
 每种类型工作负载的最佳实践：架构、性能、设计、大小划分以及高可用性
 在负载均衡器层、Web服务器层、Java应用服务器层或DB服务器层识别瓶颈
 借助esxtop解决复杂的vSphere Java性能问题
 有关性能的FAQ：企业级用户所提问题的答案

（美） Emad Benjamin 著：暂无简介

张卫滨 文建国 译：暂无简介

几年前，业界对于虚拟化和云计算是否能够在商业中真正应用还有许多争论，但目前，云计算和虚拟化已经广泛应用于蓬勃发展的互联网领域以及传统的企业级软件解决方案之中，软件开发和部署正在经历着剧烈的变革。借助云计算的浪潮，一些公司脱颖而出，站在了时代的前沿，这其中就包括VMware—完整的虚拟化解决方案使其成为行业的领导者。
虚拟化在带来成本节省和运维便利的同时，也带来了一些新的挑战，对架构师和运维人员提出了新的要求。在解决了物理设施的虚拟化问题之后，我们的目光可能就会转移到应用程序本身上来，因为这才是真正为用户交付价值的关键所在。部署在虚拟化环境上的Java应用与物理环境上的应用有什么区别？对不同类型的Java应用如何进行优化？新的数据存储模式是什么？如何在虚拟化环境下最优化应用部署？对于这些问题，本书都给出了详尽的解答。本书的作者拥有VMware虚拟化的丰富经验，所传授的知识都来源于一线的实战经验，相信这些知识对于要进行虚拟化的架构师和运维工程师都会有很大帮助。
在翻译本书的过程中，深感作者知识领域的深厚和本书涉及内容的广泛，从计算机硬件体系结构到Java虚拟机的内存管理优化，从内存数据库的设计到整个应用分层的部署，本书都有介绍，因此，在翻译时我查阅了许多资料，这对于个人知识领域的拓展也有很大帮助。
在此要感谢关敏编辑所提供的帮助和指导，感谢我的搭档文建国同学，还要感谢一直以来给我支持和鼓励的朋友与家人。
尽管在翻译的过程中，我们力争达到准确和通畅，但限于水平和时间，书中肯定还有许多不足或纰漏之处，热忱期待你提出意见，希望本书能对你有所帮助！

张卫滨

译者序
前　言
第1章　大规模Java平台简介1
1.1　大规模Java平台的分类1
1.2　大规模Java平台的趋势与需求2
1.2.1　计算资源合并2
1.2.2　JVM实例合并2
1.2.3　弹性与灵活性3
1.2.4　性能3
1.3　大规模Java平台的技术因素3
1.3.1　Java平台在理论和实际中的限制3
1.3.2　NUMA7
1.3.3　在生产环境中，最为常见的JVM规模13
1.3.4　JVM和VM的水平扩展与垂直扩展13
1.4　本章小结17
第2章　现代化可扩展的数据平台18
2.1　SQLFire的拓扑结构20
2.1.1　客户端/服务器拓扑结构21
2.1.2　端到端拓扑结构23
2.1.3　冗余区23
2.1.4　全球的多点拓扑结构23
2.2　SQLFire特性25
2.2.1　服务器分组27
2.2.2　分区29
2.2.3　冗余31
2.2.4　位置协同32
2.2.5　磁盘持久化33
2.2.6　事务35
2.2.7　缓存插件39
2.2.8　监听器41
2.2.9　writer43
2.2.10　异步监听器44
2.2.11　DBSynchronizer46
2.2.12　SQLF命令与DDLUtils48
2.3　Active-Active架构与现代化数据平台 49
2.4　本章小结52
第3章　大规模Java平台调优53
3.1　GC调优方法58
3.1.1　步骤A：新生代调优58
3.1.2　步骤B：老年代调优62
3.1.3　步骤C：Survivor 空间调优63
3.2　本章小结65
第4章　设计和划分大规模Java平台66
4.1　为虚拟化大规模Java平台设计和划分新环境66
4.1.1　步骤1：建立生产环境下的负载Profile67
4.1.2　步骤2：建立基准67
4.1.3　步骤3：划分生产环境77
4.2　划分vFabric SQLFire Java平台：第二类工作负载78
4.2.1　步骤A：确定实体分组78
4.2.2　步骤B：确定数据Fabric的内存大小81
4.2.3　步骤C：确定模板VM和JVM的大小以及所需的vFabric SQLFire成员数量84
4.2.4　理解HotSpot JVM内部的内存分区 85
4.2.5　理解划分大型VM和JVM时NUMA的影响86
4.2.6　vFabric SQLFire大小划分样例90
4.3　本章小结96
第5章　性能研究97
5.1SQLFire和RDBMS性能研究97
5.1.1性能结果98
5.1.2　结果总结 101
5.2　Olio工作负载运行在tc Server和vSphere上的性能研究101
5.3　SpringTrader性能研究105
5.3.1vSphere应用层和数据层配置107
5.3.2　SpringTrader性能研究结果 110
5.4　ESXi 3、ESXi 4.1和ESXi 5的性能差异111
5.4.1CPU调度改进 111
5.4.2内存增强112
5.5vSphere 5性能提升113
5.6　本章小结114
第6章　最佳实践115
6.1vSphere上企业级Java应用的最佳实践（第一类）117
6.1.1VM规模大小以及配置的最佳实践117
6.1.2VM vCPU的最佳实践118
6.1.3　VM内存划分的最佳实践119
6.1.4　VM时间同步最佳实践122
6.1.5　垂直扩展性的最佳实践122
6.2　水平可扩展性、集群以及池的最佳实践123
6.2.1　分层之间配置的最佳实践124
6.2.2　vSphere的最佳实践126
6.3　SQLFire最佳实践以及vSphere上SQLFire的最佳实践（第二类JVM工作负载的最佳实践）128
6.3.1　SQLFire最佳实践129
6.3.2　在vSphere上vFabric SQLFire的最佳实践131
6.4　第三类工作负载的最佳实践136
6.5　GC策略选择138
6.5.1　IBM GC可选方案139
6.5.2　Oracle jRockit GC策略140
6.6　本章小结140
第7章　监控与故障排除141
7.1　开启请求支持的Ticket142
7.2　通过vCenter收集指标143
7.3　借助esxtop排查vSphere问题的技术146
7.4　Java问题排除指导148
7.4.1　排查Java内存问题150
7.4.2　排查Java线程竞争的问题151
7.5　本章小结152
附录FAQ153
术语表170