应该使用32位还是64位的JVM?
应该使用32位还是64位的JVM?
猴亮屏 发表于4年前
应该使用32位还是64位的JVM?
  • 发表于 4年前
  • 阅读 16
  • 收藏 0
  • 点赞 0
  • 评论 0

【腾讯云】买域名送云解析+SSL证书+建站!>>>   

摘要: 今天给小MAC安装ORACLE,遇到了JVM FOR MAC的安装问题,貌似OS X 10.9.1没有内置JVM,而需要自己从中端安装?然互他又提示什么默认是服务器版JVM。。。闲逛找秘籍时,突然发现这篇文章,非常底层,非常牛逼,所以赶紧剽窃来,留着以后慢慢研究,嘿嘿~偷技术,也能叫偷吗?


应用使用32位的JVM,还是应该使用64位的JVM,我自己以前还真没想过,大家都想过了吗?本文是Plumbr中的一篇博文,为大家提了个醒。(2012.11.27最后更新)

    在我的企业级软件开发职业生涯中,我多次面对这个问题。每隔一段时间我不得不建议配置一个新的特定环境。而往往该问题部分与"我应该使用32位还是64位JVM?"这一问题有关。老实说,一开始我是靠掷硬币来解决的,而不是给出一个合理的答案。(抱歉,兄弟们!)但现在我对这个问题有了更多的领悟,并想与你们分享。
    第一步--越多越好,对吗?即如此,因为64>32,所以答案很简单:如果可能的话,应该总是选择64位?好吧,请耐心点儿。64位架构的坏处是,相同的数据结构会消耗更多的内存,甚至是多很多。我们的测评显示,根据不同的JVM版本和操作系统版本,以及相应的硬件架构,最终会用掉比32位架构多30-50%的堆内存。更大的堆也会造成更长的GC暂停,这会对应用程序造成潜在的影响--在4.5G的堆上执行完全GC肯定会比在3G的堆上执行花费更长的时间。所以,仅仅是因为64比32大就去赶64位JVM的时髦,肯定是错误的。
    但,什么时候才是使用64位JVM的好时机呢?多数情况下,要看堆的大小。在不同的平台下,你很快就得面对32位JVM堆内存的上限问题。下表列出了在不同平台下的这种限制:
Linux         2GB       特定内核,如hugemem,可以达到3G
Windows    1.5GB    使用"/3G"的启动参数并使用/LARGEADDRESSAWARE参数去编译JRE,则可提高到3G
Mac OS X   3.8GB    警告--未能找到老的Mac,所以没有对其进行测试

    那么,这有什么坏处?我打赌,你肯定见过在16G的RAM上运行32位的机器。问题就在于,在只有16G RAM的Windows系统中,JVM只能分配到少于10%的内存。
    主因--地址空间。在32位系统中,理论上可以为每个进程分配4G内存。而Windows系统对地址空间的处理使这一理论值无法达到。Windows将进程的地址空间砍掉了一半。一半留给了内核(用户进程无法使用它),另一半则留给了用户。无论系统中有多大的RAM,32位进程只能使用到2G的RAM。更糟的是--地址空间必须是连续的,所以在实践中,Windows系统最多只为你剩下了1.5-1.8G的堆内存。
    有一个在32位Windows系统中减少内核空间并增加用户空间的窍门,即,可以在boot.ini系统使用/3GB参数。然而,为了能确保它有效,必须使用/LARGEADDRESSAWARE开关去编译或链接JVM。
    不幸地是,至少对于HotSpot JVM无法做到这一点。直到最新的JDK 1.7版本,HotSpot JVM仍未使用该选项进行编译。但又幸运地是,如果你运行2006年之后的JRockit版本,就能享用到2.8-2.9G的堆大小。
    那么,我们是否可以得出结论,如果你的应用要求大于2-3G的内存,你就总是应该运行64位的JVM?也许。但你也必须要清楚应用的场景。我们已经介绍了使用64位JVM的坏处--增加的堆消耗,以及更长的GC中断。让我们分析一下原因。
    问题1:64位JVM需要多出30-50%的内存。为什么会如此呢?主要是因为内存是以64位架构进行部局。首先,在64位JVM中,对象头有12字节。其次,对象引用会占用4字节或8字节,实际值取决于JVM的参数与堆的大小。相较于32位JVM的8字节对象头和4字节对象引用,毫无疑问会增加一些开销。在我们之前发布的博客中你会找到更多关于如何计算对象内存的相关信息。
    问题2:更长的垃圾收集中断。构建更大的堆意味着GC要做更多的工作去清理无用的对象。这意味着,在实际应用中构建大于12-16G的堆时,你必须要特别小心。没有很好的性能调优与测评,你很容易就会引起一个耗时数分钟的完全GC。在应用程序的非关键潜在危险场景中,通过对吞吐量的优化或许能解决这一问题,但在多数情况下,它会造成程序中断。
    当我需要更大的内存且又不希望引入由64位架构所造成的开销,那该怎么办呢?在我们以前的一篇博文中已经涉及了这个问题--通过对堆的分区,GC调优,构建不同的JVM,或对堆分配不同的内存,就可以避免这一问题。
    最后,让我们重申,你应该总是要意识到选择64位JVM的后果,但也不要惧怕这一选择。


  • 打赏
  • 点赞
  • 收藏
  • 分享
共有 人打赏支持
猴亮屏
粉丝 29
博文 487
码字总数 48573
作品 2
×
猴亮屏
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: