搜索
首页Javajava教程关于java性能的9个谬论
关于java性能的9个谬论Nov 26, 2016 am 11:32 AM
javajava性能

Java的性能有某种黑魔法之称。部分原因在于Java平台非常复杂,很多情况下问题难以定位。然而在历史上还有一种趋势,人们靠智慧和经验来研究Java性能,而不是靠应用统计和实证推理。在这篇文章中,我希望拆穿一些最荒谬的技术神话。

1.Java很慢

关于Java的性能有很多谬论,这一条是最过时的,可能也是最为明显的。

确实,在上世纪90年代和本世纪初处,Java有时是很慢。

然而从那以后,虚拟机和JIT技术已经有了十多年的改进,Java的整体性能现在已经非常好了。

在6个独立的Web性能基准测试中,Java框架在24项测试中有22项位列前四。

尽管JVM利用性能剖析仅优化常用的代码路径,但这种优化效果很明显。很多情况下,JIT编译的Java代码和C++一样快,而且这样的情况越来越多了。

尽管如此,依然有人认为Java平台很慢,这或许源自体验过Java平台早期版本的人的历史偏见。

在下结论之前,我们建议保持客观的态度,并且评估一下最新的性能结果。

2.可以孤立地看待单行Java代码

考虑下面这行短小的代码:

MyObject obj = new MyObject();

对Java开发者而言,看似很明显,这行代码一定会分配一个对象并调用适当的构造器。

我们也许可以据此推出性能边界了。我们认为这行代码一定会导致执行一定量的工作,基于这种推定,就可以尝试计算其性能影响了。

其实这种认识是错误的,它让我们先入为主地认为,不管什么工作,在任何情况下都会进行。

事实上,javac和JIT编译器都能够将死代码优化掉。就JIT编译器而言,基于性能剖析数据,甚至可以通过预测将代码优化掉。在这样的情况下,这行代码根本不会运行,所以不会影响性能。

此外,在某些JVM中——比如JRockit——JIT编译器甚至可以将对象上的操作分解,这样即便代码路径还有效,分配操作也可以避免。

这里的寓意是,在处理Java性能问题时,上下文非常重要,过早的优化有可能产生违反直觉的结果。所以最好不好过早优化。相反,应该总是构建代码,并且使用性能调校技术来定位性能热点,然后加以改进。

3.微基准测试和你想象的一样

正如我们上面看到的那样,检查一小段代码不如分析应用的整体性能来的准确。

尽管如此,开发者还是喜欢编写微基准测试。似乎对平台底层的某些方面进行修修补补会带来无穷的乐趣。

理查德·费曼曾经说过:“不要欺骗自己,你自己正是最容易被欺骗的人。”这句话用来说明编写Java微基准测试这件事是再合适不过了。

编写良好的微基准测试极其困难。Java平台非常复杂,而且很多微基准测试只能用于测量瞬时效应,或是Java平台的其他意想不到的方面。

例如,如果没有经验,编写的微基准测试往往就是测一下时间或垃圾收集,却没有抓住真正的影响因素。

只有那些有实际需求的开发者和开发团队才应该编写微基准测试。这些基准测试应该完全公开(包括源代码),而且是可以复现的,还应接受同行评审及进一步的审查。

Java平台的很多优化表明统计运行和单次运行对结果影响很大。要得到真实可靠的答案,应该将一个单独的基准测试运行多次,然后把结果汇总到一起。

如果读者感觉有必要编写微基准测试,Georges、Buytaert和Eeckhout等人的论文《利用严格的统计方法评测Java 性能(Statistically Rigorous Java Performance Evaluation)》是个不错的开始。缺乏适当的统计分析,我们很容易被误导。

有很多开发好的工具以及围绕这些工具的社区(比如Google的Caliper)。如果确实有必要编写微基准测试,那也不要自己编写,这时需要的是同行的意见和经验。

4.算法慢是性能问题的最常见原因

在开发者之间有一个很常见的认知错误(普通大众也是如此),即认为系统中他们控制的那部分很重要。

在探讨Java性能时,这种认知错误也有所体现:Java开发者认为算法的质量是性能问题的主要原因。开发者考虑的是代码,因此他们自然会偏向于考虑自己的算法。

实际上在处理一系列现实中的性能问题时,人们发现算法设计是根本问题的几率不足10%。

相反,与算法相比,垃圾收集、数据库访问和配置错误导致应用程序缓慢的可能性更大。

大部分应用处理的数据量相对较小,因此,即使主要算法效率不高,通常也不会导致严重的性能问题。可以肯定,我们的算法不是最优的;尽管如此,算法带来的性能问题还是算小的,更多性能问题是应用栈的其他部分导致的。

因此我们的最佳建议是,使用实际生产数据来揭开性能问题的真正原因。要测量性能数据,而不是凭空猜测!

5.缓存可以解决所有问题

“计算机科学中的所有问题都可以通过引入一个中间层来解决。”

David Wheeler的这句程序员格言(在互联网上,这句话至少还被认为是其他两位计算机科学家说的)非常常见,尤其是在Web开发者之中很流行。

如果未能透彻理解现有的架构,而且分析也已停顿,往往就是“缓存可以解决所有问题”这种谬论抬头的时候了。

在开发者看来,与其处理吓人的现有系统,还不如在前面加一层缓存,将现有系统隐藏起来,以此期待最好的情况。无疑,这种方式只是让整体架构更复杂了,当下一个接手的开发者打算了解系统现状时,情况会更糟糕。

规模庞大、设计拙劣的系统往往缺乏整体的设计,是一次一行代码、一个子系统这样写出来的。然而很多情况下,简化并重构架构会带来更好的性能,而且几乎总是更容易让人理解。

所以当评估是否真的有必要加入缓存时,应该先计划收集一些基本的使用统计信息(比如命中率和未命中率等),以此证明缓存层带来的真正价值。

6.所有应用都需要关注Stop-The-World问题

Java平台存在一个无法改变的事实:为运行垃圾收集,所有应用线程必须周期性停顿。有时这被当作Java的一个严重缺点,即使没有任何真凭实据。

实证研究表明,如果数字数据(如价格波动)变化的频率超过200毫秒一次,人就无法正常感知了。

应用主要是给人用的,因此我们有一个有用的经验法则,200毫秒或低于200毫秒的Stop-The-World(STW)通常是没有影响的。有些应用可能有更高的要求(如流媒体),但很多GUI应用是不需要的。

少数应用(比如低延迟交易或机械控制系统)无法接受200毫秒的停顿。除非编写的就是这类应用,否则用户基本感觉不到垃圾收集器的影响。

值得一提的是,在应用线程数量超过物理核数的任何系统中,操作系统必须控制对CPU的分时访问。Stop-The-World听着可怕,但实际上任何应用(不管是JVM还是其他应用)都要面对稀缺计算资源的争用问题。

如果不去测量,JVM对应用性能有何附加影响是不清楚的。

总之,请打开GC日志,以此来确定停顿时间是否真的影响了应用。通过分析日志来确定停顿时间,这里既可以手工分析,也可以利用脚本或工具分析。然后再判定它们是否真的给应用于带来了问题。最重要的是,问自己一个关键的问题:确实有用户抱怨吗?

7.手写对象池适合一大类应用

认为Stop-The-World停顿在某种程度上是不好的,应用开发团队的一个常见反应就是在Java堆内实现自己的内存管理技术。这往往会归结为实现一个对象池(甚至是全面的引用计数),而且需要使用了领域对象的任何代码都参与进来。

这种技术几乎总是具有误导性的。它基于过去的认知,那时对象分配非常昂贵,而修改对象则廉价的多。现在的情况已经完全不同了。

现在的硬件在分配时非常高效;最新的桌面或服务器硬件,内存带宽至少是2到3GB。这是一个很大的数字,除非专门编写的应用,否则要充分利用这么大的带宽还真不容易。

一般来说,正确实现对象池非常困难(尤其是有多个线程工作时),而且对象池还带来了一些负面的要求,使这种技术不是一个通用的良好选择:

所有接触到对象池代码的开发者必须了解对象池,而且能正确处理

哪些代码知道对象池,哪些代码不知道对象池,其界限必须让大家知道,并且写在文档中

这些额外的复杂性要保持更新,而且定期复审

如果有一条不满足,悄然出现问题(类似于C 中的指针复用)的风险就又回来了

总之,只有GC停顿不能接受,而且调校和重构也未能将停顿减小到可以接受的水平时,才能使用对象池。

8.在垃圾收集中,相对于Parallel Old,CMS总是更好的选择

Oracle JDK默认使用一个并行的Stop-The-World收集器来收集老年代,即Parallel Old收集器。

Concurrent-Mark-Sweep (CMS)是一个备选方案,在大部分垃圾收集周期,它允许应用线程继续运行,但这是有代价的,而且有一些注意事项。

允许应用线程与垃圾收集线程一起运行,不可避免地带来一个问题:应用线程修改了对象图,可能会影响对象的存活性。这种情况必须在事后加以清理,因此CMS实际上有两个STW阶段(通常非常短)。

这会带来一些后果:

必须将所有应用线程带到安全点,每次Full GC期间会停顿两次;

尽管垃圾收集与应用同时执行,但应用的吞吐量会降低(通常是50%);

在使用CMS进行垃圾收集时,JVM所用的簿记信息(和CPU周期)远高于其他的并行收集器。

这些代价是不是物有所值,取决于应用的情况。但是天下没有免费的午餐。CMS收集器在设计上值得称道,但它不是万能的。

所以在确定CMS是正确的垃圾收集策略之前,首先应该确认Parallel Old的STW停顿确实不能接受,而且已经无法调校。最后,我重点强调一下,所有指标必须从与生产系统等价的系统中获得。

9.增加堆的大小可以解决内存问题

当应用陷入困境,并且怀疑是GC的问题时,很多应用团队的反应就是增加堆的大小。在某些情况下,这样做可以快速见效,而且为我们留出了时间来考虑更周详的解决方案。然而,如果没有充分理解性能问题的原因,这种策略反而会让事情变得更糟糕。

考虑一个编码非常糟糕的应用程序,它正在产生很多领域对象 (它们的生存时间很有代表性,比如说是2-3秒)。如果分配率高到一定程度,垃圾收集会频繁进行,这样领域对象会被提升到老年代。领域对象几乎是一进入年老代,生存时间就结束了,从而直接死亡,但它们直到下一次Full GC时才会被回收。

如果增加了应用的堆大小,我们所做的不过是增加了相对短命的对象进入和死亡所用的空间。这会导致Stop-The-World停顿时间更长,对应用并无益处。

在修改堆大小或者调校其他参数之前,理解对象的分配和生存时间的动态是很有必要的。没有测量性能数据就盲目行动,只会使情况更糟糕。在这里,垃圾收集器的老年代分布情况特别重要。

结论

当谈到Java的性能调校时,直觉常常起误导作用。我们需要实验数据和工具来帮助我们将平台的行为可视化并加强理解。

垃圾收集就是最好的例子。对于调校或者生成指导调校的数据而言,GC子系统拥有无限的潜力;但是对于产品应用而言,不使用工具很难理解所产生数据的意义。

默认情况下,运行任意Java进程(包括开发环境和产品环境),应该至少总是使用如下参数:

-verbose:gc(打印GC日志)
-Xloggc:(更全面的GC日志)
-XX:+PrintGCDetails(更详细的输出)
-XX:+PrintTenuringDistribution(显示JVM所使用的将对象提升进入老年代的年龄阈值)

然后使用工具来分析日志,这里可以利用手写的脚本,可以用图生成,还可以使用GCViewer(开源的)或jClarity Censum这样的可视化工具。


声明
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
带你搞懂Java结构化数据处理开源库SPL带你搞懂Java结构化数据处理开源库SPLMay 24, 2022 pm 01:34 PM

本篇文章给大家带来了关于java的相关知识,其中主要介绍了关于结构化数据处理开源库SPL的相关问题,下面就一起来看一下java下理想的结构化数据处理类库,希望对大家有帮助。

Java集合框架之PriorityQueue优先级队列Java集合框架之PriorityQueue优先级队列Jun 09, 2022 am 11:47 AM

本篇文章给大家带来了关于java的相关知识,其中主要介绍了关于PriorityQueue优先级队列的相关知识,Java集合框架中提供了PriorityQueue和PriorityBlockingQueue两种类型的优先级队列,PriorityQueue是线程不安全的,PriorityBlockingQueue是线程安全的,下面一起来看一下,希望对大家有帮助。

完全掌握Java锁(图文解析)完全掌握Java锁(图文解析)Jun 14, 2022 am 11:47 AM

本篇文章给大家带来了关于java的相关知识,其中主要介绍了关于java锁的相关问题,包括了独占锁、悲观锁、乐观锁、共享锁等等内容,下面一起来看一下,希望对大家有帮助。

一起聊聊Java多线程之线程安全问题一起聊聊Java多线程之线程安全问题Apr 21, 2022 pm 06:17 PM

本篇文章给大家带来了关于java的相关知识,其中主要介绍了关于多线程的相关问题,包括了线程安装、线程加锁与线程不安全的原因、线程安全的标准类等等内容,希望对大家有帮助。

详细解析Java的this和super关键字详细解析Java的this和super关键字Apr 30, 2022 am 09:00 AM

本篇文章给大家带来了关于Java的相关知识,其中主要介绍了关于关键字中this和super的相关问题,以及他们的一些区别,下面一起来看一下,希望对大家有帮助。

Java基础归纳之枚举Java基础归纳之枚举May 26, 2022 am 11:50 AM

本篇文章给大家带来了关于java的相关知识,其中主要介绍了关于枚举的相关问题,包括了枚举的基本操作、集合类对枚举的支持等等内容,下面一起来看一下,希望对大家有帮助。

java中封装是什么java中封装是什么May 16, 2019 pm 06:08 PM

封装是一种信息隐藏技术,是指一种将抽象性函式接口的实现细节部分包装、隐藏起来的方法;封装可以被认为是一个保护屏障,防止指定类的代码和数据被外部类定义的代码随机访问。封装可以通过关键字private,protected和public实现。

归纳整理JAVA装饰器模式(实例详解)归纳整理JAVA装饰器模式(实例详解)May 05, 2022 pm 06:48 PM

本篇文章给大家带来了关于java的相关知识,其中主要介绍了关于设计模式的相关问题,主要将装饰器模式的相关内容,指在不改变现有对象结构的情况下,动态地给该对象增加一些职责的模式,希望对大家有帮助。

See all articles

热AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover

AI Clothes Remover

用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool

Undress AI Tool

免费脱衣服图片

Clothoff.io

Clothoff.io

AI脱衣机

AI Hentai Generator

AI Hentai Generator

免费生成ai无尽的。

热门文章

R.E.P.O.能量晶体解释及其做什么(黄色晶体)
2 周前By尊渡假赌尊渡假赌尊渡假赌
仓库:如何复兴队友
4 周前By尊渡假赌尊渡假赌尊渡假赌
Hello Kitty Island冒险:如何获得巨型种子
3 周前By尊渡假赌尊渡假赌尊渡假赌

热工具

DVWA

DVWA

Damn Vulnerable Web App (DVWA) 是一个PHP/MySQL的Web应用程序,非常容易受到攻击。它的主要目标是成为安全专业人员在合法环境中测试自己的技能和工具的辅助工具,帮助Web开发人员更好地理解保护Web应用程序的过程,并帮助教师/学生在课堂环境中教授/学习Web应用程序安全。DVWA的目标是通过简单直接的界面练习一些最常见的Web漏洞,难度各不相同。请注意,该软件中

Atom编辑器mac版下载

Atom编辑器mac版下载

最流行的的开源编辑器

Dreamweaver Mac版

Dreamweaver Mac版

视觉化网页开发工具

PhpStorm Mac 版本

PhpStorm Mac 版本

最新(2018.2.1 )专业的PHP集成开发工具

SecLists

SecLists

SecLists是最终安全测试人员的伙伴。它是一个包含各种类型列表的集合,这些列表在安全评估过程中经常使用,都在一个地方。SecLists通过方便地提供安全测试人员可能需要的所有列表,帮助提高安全测试的效率和生产力。列表类型包括用户名、密码、URL、模糊测试有效载荷、敏感数据模式、Web shell等等。测试人员只需将此存储库拉到新的测试机上,他就可以访问到所需的每种类型的列表。