Java性能权威指南.pdf
http://www.100md.com
2020年11月18日
 |
| 第1页 |
 |
| 第8页 |
 |
| 第15页 |
 |
| 第28页 |
 |
| 第41页 |
 |
| 第213页 |
参见附件(67726KB，331页)。
Java性能权威指南对Java 7和Java 8中影响性能的因素展开了全面深入的介绍，讲解传统上影响应用性能的JVM特征，包括即时编译器、垃圾收集、语言特征等。内容包括：用G1垃圾收集器应用的吞吐量；使用Java飞行记录器查看性能细节，而不必借助专业的分析工具；堆内存与原生内存实践；线程与同步的性能，以及数据库性能实践等。
编辑推荐
市面上介绍Java的书有很多，但专注于Java性能的并不多，能游刃有余地展示Java性能优化难点的更是凤毛麟角，本书即是其中之一。通过使用JVM和Java平台，以及Java语言和应用程序接口，本书详尽讲解了Java性能调优的相关知识，帮助读者深入理解Java平台性能的各个方面，使程序如虎添翼。
通过阅读本书，你可以：
运用四个基本原则大程度地提升性能测试的效果
使用JDK中自带的工具收集Java应用的性能数据
理解JIT编译器的优缺点
调优JVM垃圾收集器以减少对程序的影响
学习管理堆内存和JVM原生内存的方法
了解如何大程度地优化Java线程及同步的性能
解决Java EE和Java SE应用程序接口的性能问题
改善Java驱动的数据库应用程序的性能
作者简介
Scott Oaks是Oracle公司的一位架构师，专注研究Oracle中间件软件的性能。加入Oracle之前，他曾于Sun Microsystem公司任职多年，在多个技术领域都有建树，包括SunOS的内核、网络程序设计、Windows系统的远程方法调用(RPC)以及OPEN LOOK虚拟窗口管理器。1996年，Scott成为Sun公司的Java布道师，并于2001年加入Sun公司的Java性能小组——从那时起他就一直专注于Java的性能提升。此外，Scott也在O'Reilly出版社出版了多部书籍，包括Java Security、Java Threads、JXTA in a Nutshell和Jini in a Nutshell。
导论
这是一本关于Java性能调优科学和艺术的书。
说性能调优是门科学，这并不令人意外；性能调优涉及大量数字、检测和分析工作。性能调优工程师大多具有科学背景，只有基于严谨的科学理论才能将性能发挥到极致。
那它的艺术性呢？其实性能调优是科学与艺术的结合体这一说法并不新鲜，但我们探讨性能时却很少能清楚地意识到这一点。从某种程度上说，这可能是因为我们所受的教育训练并不容易产生“艺术”的思想火花。
说它是艺术的部分原因是，对一些人来说，艺术从根本上就是建立在知识和经验的基础上的。据说，足够先进的技术与魔术无异，例如对于圆桌骑士而言，使用手机毫无疑问就是一种魔法。与此类似，优秀性能调优工程师的工作就像是艺术，而这艺术正是源于深厚的知识、丰富的经验和敏锐的直觉。
本书的侧重点不在于三者中的经验和直觉，而是在拓展知识的深度。日积月累，这些知识将有助于提升你的技能，有助于你成为一名优秀的Java性能调优工程师。本书还有助于你深入理解Java平台性能的各个方面。
本书涉及的知识主要分两大类。首先是如何Java机(Java Virtual Machine，JVM)
自身的性能进行调优，即如何通过JVM的配置来影响程序的各种性能指标。JVM性能调优的过程实际上与C++程序员在编译时通过测试选择编译参数，以及PHP码农在php.ini文件中选择适当变量等过程非常类似，但对于那些即便有其他语言经验的Java开发者来说，调优过程仍然不那么令人愉快。
其次是理解Java平台的特性对性能的影响。注意，此处的平台既指Java语言(例如线程和同步)，也指Java标准API(例如XML解析性能)，虽然Java语言和Java API完全不是一回事，但本书并不作严格区分，这两方面的内容都会涵盖。
JVM自身的性能很大程度上取决于调优标志，而Java平台的性能则更多由在应用代码中采用最佳实践决定。在一个开发团队中，开发人员编写代码，性能组负责性能测试。编码和调优常常被认为是两个不同的专业领域：性能调优工程师只是竭力将JVM的性能发挥到极致，而开发人员只关心他们的代码逻辑是否正确。这种区分没有什么意义。任何从事Java相关工作的人都应该熟谙代码在JVM中的行为，以及如何调优才能提升性能。对专业知识的全面掌握能让你的工作更具艺术气息。
吞吐量测试
吞吐量测试是基于一段时间内所能完成的工作量。虽然最常见的吞吐量测试是服务器处理客户端产生的数据，但这并非绝对的：单个独立运行的应用也可以像测量流逝时间一样测量吞吐量。
在客户端一服务器的吞吐量测试中，并不考虑客户端的思考时间。客户端向服务器发送请求，当它收到响应时，立刻发送新的请求。持续这样的过程，等到测试结束时，客户端会报告它所完成的操作总量。客户端常常有多个线程在处理，所以吞吐量就是所有客户端所完成的操作总量。通常这个数字就是每秒完成的操作量，而不是测量期间的总操作量。这个指标常常被称作每秒事务数(TPS)、每秒请求数(RPS)或每秒操作次数(OPS)
所有的客户端-服务器测试都存在风险，即客户端不能足够快地向服务器发送数据。这可能是由于客户端机器的CPU不足以支持所需数量的客户端线程，也可能是因为客户端需要花大量时间处理响应才能发送新的请求。在这些场景中，测试衡量的其实是客户端性能而不是服务器性能，这并不是我们的目的。
其中的风险依赖于每个线程所承载的工作量(客户端机器的线程数和配置)。由于客户端线程需要执行大量工作，零思考时间(面向吞吐量)测试更可能会遇到这种情形。因此，通常吞吐量测试比响应时间测试的线程数少，线程负载也小。
通常吞吐量测试也会报告请求的平均响应时间。这是重要的信息，但它的变化并不表示性能有问题，除非报告的吞吐量相同。能够承受500 OPS，响应时间0.5秒的服务器，它的性能要好过响应时间0.3秒但只有4000PS的服务器。
吞吐量测试总是在合适的热身期之后进行，特别是因为所测量的东西并不固定。
Java性能权威指南截图
您现在查看是摘要介绍页， 详见PDF附件(67726KB，331页)。