Java 7 刚刚发布没两天,但来自Lucene 和Solr 社区的某些人立即报料了一些Java 7 中的严重bug。甚至 Apache Lucene 项目管理委员会成员Uwe Schindler 发布了暂时不要使用Java 7 的警告信息。那么到底Java 7 是有什么问题,为什么我们等了5 年的 Java 7 现在却不能使用呢?让我们来看看实际的情况:
成都网站制作、成都做网站的关注点不是能为您做些什么网站,而是怎么做网站,有没有做好网站,给创新互联一个展示的机会来证明自己,这并不会花费您太多时间,或许会给您带来新的灵感和惊喜。面向用户友好,注重用户体验,一切以用户为中心。
推荐专题:Java 7正式发布
这个问题跟Java 7 无关,而是跟JVM 有关
首先这个问题是跟HotSpot JVM 有关,而不是Java 7 语言本身的问题。此次发布的 GA 版本包含三个bug:7070134, 7044738 和 7068051 ,这三个bug直接导致JVM 崩溃或者进行错误的计算。
Hotspot是因为PorterStemmer 的sigsegv 而崩溃的
第一个问题(7070134) 是关于错误的编译器对循环的优化,该特性在Hotspot JVM 中是默认启用的,你可以通过 -XX:-UseLoopPredicate 参数来关闭这个特性。如果你想了解关于这个问题的详情,请看Stemmer.java ,编译并允许这个类你将会重现 JVM 崩溃并报严重错误,信息如下:
- # A fatal error has been detected by the Java Runtime Environment:
- #
- # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000000026536da, pid=5432, t
- id=6568
- #
- # JRE version: 7.0-b135
- # Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b05 mixed mode windows-amd64
- compressed oops)
- # Problematic frame:
- # J Stemmer.step4()V
这个错误直接在代码执行过程中发生,在JDK 1.6 是体验不到的。而最近Lucene 做了一些更灵活的基于 PulsingCodec 算法的索引机制,而这个机制相当大的程度上会导致上述的错误。
循环展开优化会导致不正确的结果
第二个bug (7044738) 是“错误的计算”,这个错误极为罕见的发生在OSR (On-Stack Replacement) 编译嵌套循环上,控制流退出且对应的内存没有被考虑到,这直接导致重复的克隆结果,想了解编译细节请看older overview (PDF)
一个最简单的解决办法就是使用 -XX:LoopUnrollLimit=1 参数来避免这个问题。
Clone loop predicate during loop unswitch
第三个bug(7068051) 跟一些老的 feature request 相关,由于一些无效的JVM 统计导致使用循环优化后的JVM 崩溃。
结论
根据这些bug的情况,只有在你大量的使用这些优化方法,那么你才可能已经受 Java 7 中存在的问题所影响。一般情况下是不受影响的。事实上 Java 6 的用户使用了某些优化选项也会存在问题,但因为这些优化选项在 Java 7 中是默认启用的才导致这个问题影响那么大,例如 (-XX:+OptimizeStringConcat or -XX:+AggressiveOpts) ,由于这些问题在 Java 7 发布的前 5 天才被发现,因此 Oracle 来不及解决这些bug,目前 Oracle 似乎也正在准备下一个补丁版本,但对一些高级用户来说,这些都不是问题,因为源码是开放的,你可以做你想做的。
本文译自 http://blog.eisele.net/2011/07/dont-use-java-7-are-you-kidding-me.html
当前题目:别用Java7?你是在开玩笑吗?
文章转载:http://www.mswzjz.com/qtweb/news2/170302.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联