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

　VMware公司首席架构师亲笔撰写，全方位解读在VMWare vSphere上优化企业级Java应用的最佳技术实践和实用技巧
　　从计算机硬件体系结构到Java虚拟机的内存管理优化，从内存数据库的设计到整个应用分层的部署，详细讨论Java平台虚拟化和调优的原则、策略和技巧，包含大量实例
　　现在企业已经不再询问“Java能不能虚拟化”这样的问题，而是“我们能够将虚拟化的Java应用平台扩展到多大？又该如何有效地对其进行调优？”在本书中，顶尖的Java虚拟化专家回答了这些问题，并提供了详尽的技术信息，你可以将这些技术信息用于任何生产或QA/测试环境。
　　最近9年以来，本书作者一直在虚拟化VMWare自身的企业级应用和300个VMWare重要客户的项目，这些项目的类型和规模各异——从100个JVM到10 000个以上JVM，堆内存从1GB到360GB，其中包括构建在集群JVM上的大数据应用。基于所有这些经验，作者展示了如何成功地划分和优化Java工作负载。
　　《大规模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：企业级用户所提问题的答案

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

　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实战》。

译者序
前　言
第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