基于x86和JVM浅谈32bit与64bit的区别

前言

32位和64位系统在计算机领域中常常提及，但是仍然很多人不知道32位和64位的区别，所以本人在网上整理了一些资料，并希望可以与大家一起分享。对于32位和64位之分，本文将分别从处理器，操作系统，JVM进行讲解。

IA介绍

  简介

说到处理器，大家用的最多的莫过于Intel的处理器了，所以本文主要从Intel的处理器讲解32位和64位的处理器之分。
通常将采用Intel（英特尔）处理器的服务器称之为IA（IntelArchitecture）架构服务器，又称 CISC（ComplexInstructionSetComputer复杂指令集）架构服务器，由于IA架构的服务器是基于PC的x86处理器体系结 构，所以又把IA架构的服务器称为PC服务器或者x86服务器。
虽然IA构架服务器始于PC,但经过不断的发展，IA架构服务器已经远远超出了PC的概念。
IA架构根据intel的官方声明，分为以下三类：
1 IA-32
2 Intel® 64
3 IA-64

  历史

x86架构于1978年推出的Intel 8086中央处理器中首度出现，它是从Intel 8008处理器中发展而来的，而8008则是发展自Intel 4004的。8086在三年后为IBM PC所选用，之后x86便成为了个人电脑的标准平台，成为了历来最成功的CPU架构。

其他公司也有制造x86架构的处理器，计有Cyrix（现为VIA所收购）、NEC集团、IBM、IDT以及Transmeta。Intel以外最成功的制造商为AMD。
8086是16位处理器；直到1985年32位的80386的开发，这个架构都维持是16位。
Intel 80386 32位处理器推出后，也许是到目前为止x86架构的最大跃进。Linux、386BSD、Windows NT和Windows 95都是一开始为386所发展,这种386的基本架构变成未来所有x86系列发展的基础。

现时Intel把x86-32称为IA-32，全名为"Intel Architecture, 32-bit"。

随后IA服务器经历了486系统、PentiumPro系统、PII系统、PIII系统、XEON系统等几个阶段。处理器系统的处理能力在大幅度提高，而服务器系统的总线结构始终是IA-32总线体系。
IA-32服务器在发展到8路XEON服务器以后，体系结构已经开始成为制约服务器性能提高的瓶颈。
因此，hp和Intel自1994年开始合作开发IA－64架构的处理器，IA-64结构既不是Intel的32位x86结构的扩充，也不是完全采用hp公司64位PA-RISC结构，而是一种全新的设计样式。目前正式宣布支持IA-64平台的有Monterey、Linux64、hp-UX、Solaris、Win2000,Windows xp等操作系统。
IA-64的代表产品就是Itanium(安腾)处理器,是专门用在高端企业级64-bit计算环境中竞争的，对抗基于IBM Power4/5，HP PA-RISC，Sun UltraSparc-III及DEC Alpha的高端企业级处理器。

但由于它不能很好地解决与以前32位应用程序的兼容，所以应用受到较大的限制，而AMD在IA-32上新增了64位寄存器，并兼容早期的16位和32位软件，形成AMD64版本。尽管目前Intel采取了各种软、硬方法来弥补这一不足，但随着AMD64处理器的全面投入，Intel的IA－64架构的这两款处理器前景不容乐观。

为x86系统而设的应用软件实在太庞大，Intel眼见使用AMD64的Opteron及Athlon 64取得成功，便需要对竞争者的威胁作出迎击,也开发了兼容早期16位和32的64位处理器，Intel将之命名为"IA-32E"，意即IA-32的延伸，在数星期后才改称为EM64T。虽然该处理器的内核与AMD64几乎相同，但是在以往Intel的营销中，Intel总把AMD的产品贬为自家技术的仿制品，Intel为了自身的面子，定不会承认使用了对手AMD的技术，因此Intel把该技术以EM64T这个名字来推出，后来Intel索性将此技术正式命名为Intel 64。

Intel 64指令集被应用于Pentium 4、Pentium D、Pentium Extreme Edition、Celeron D、Xeon、Intel Core 2及Intel Core i7处理器上。

由于AMD64和Intel64基本上一致，很多软硬件产品都使用一种不倾向任何一方的词汇来表明它们对两种架构的同时兼容。出于这个目的，AMD对这种CPU架构的原始称呼——"x86-64"被不时地使用，还有变体"x86_64"。其他公司如微软和太阳计算机系统公司在营销资料中使用"x64"作为对"x86-64"的缩写。

  EM64T技术详解

Intel官方是给EM64T这样定义地：EM64T全称Extended Memory 64 Technology，即64位内存扩展技术，他是Intel IA-32架构（Intel Architectur-32 extension）地一个扩展，且兼容原来地架构。通过增加CPU地运算位宽扩展增加cpu和内存之间地位宽，从而让系统支持更大容量地内存（32bit处理器最多只能支持内存容量只有4GB，而64bit地最高则达64GB）。在理论上，虽然EM64T架构最高能够很好的运行在64 bit内存寻址，但由于设计和制造工艺等方面地因素，并非所有EM64T地处理器都能达到理论地上限。

Intel为支持EM64T技术地处理器可分为两大类：传统IA-32模式和IA-32e扩展模式，两大类下具体又可分为多种运行模式

EM64T运行模式
传统IA-32模式			IA-32e扩展模式
保护模式	真实地址模式	真实8086模式	兼容模式	64位模式

 

传统IA-32模式下，与IA-32工作模式一样，我们可以安装windows xp 32bit，安装32位硬件硬件驱动，安装32位应用程序。目前大部分人的处理器是Intel 64，安装了windows xp 32，上面的程序运行情况良好，包括16bit和32bit程序。
 

兼容模式下，操作系统和硬件驱动程序都是64bit，计算机允许在64bit操作系统下不需要预编译就可以运行大多数传统32bit应用程序，这和传统IA-32模式下基本相同，32位应用程序仍然只能访问4G内存，但此限制只在进程级，而不在系统级。
 

由于兼容模式下，要求硬件驱动程序都是64bit，所以导致了64位Windows最大的一个劣势就是兼容性，而兼容性方面最突出的就是各种硬件设备的驱动程序。，如果你所用的硬件设备的开发商还没有开发出针对64位Windows XP的驱动程序，那么要么该设备在64位Windows XP下无法使用，要么使用操作系统自带的通用驱动勉强使用，但是性能和功能都会受到影响 。
至于其他软件程序则一般没有什么大问题。在64位Windows XP中，只有16位应用程序是完全无法使用的，而32位应用程序则可以继续使用。不过在安装这些应用程序的时候也要注意，有些应用程序，虽然和硬件扯不上关系，但是为了实现软件的某些特殊功能，安装软件的时候同时还会向系统中装入驱动程序，这种程序在没有发布64位版之前是无法在64位Windows下使用的。
如著名的截图软件SnagIt，该软件使用默认安装的时候会向系统中安装一个虚拟的打印机，该打印机可以将文档输出为图形格式。因为安装了虚拟设备，因而该程序还没有提供64位的版本，因此在64位Windows XP下使用默认选项安装的时候就会出错，除非我们自定义安装选项，不安装这个虚拟打印机。
 

但是对于服务器来说，服务器不需要什么外设，硬件的兼容性差对服务器的影响较小。

64bit模式下，必须要有64bit地操作系统、驱动程序和应用程序三者合作,这时操作系统无法运行32位程序，兼容性最差，但充分发挥64位架构的优势。 

 

操作系统32 bit和操作系统64 bit

64bit计算主要有两大优点：可以进行更大范围的整数运算；可以支持更大的内存。
64位CPU一次可提取64位数据，比32位提高了一倍，理论上性能会提升1倍。但这是建立在64bit操作系统，64bit软件的基础上的。
但是我们不能因为数字上的变化，而简单的认为64bit处理器的性能是 32bit处理器性能的两倍。实际上在32bit应用程序下，32bit处理器的性能甚至会更强，即使是64bit处理器，目前情况下也是在32bit应用下性能更强。所以要认清64bit处理器的优势，但不可迷信64bit。

那什么情况下，我们需要升级到64bit操作系统呢？
这要取决于应用的类型。以下的例子是从64位处理得到的好处：
  加密程序：大多数加密算法基于大量的整型数据，适合在64位通用寄存器和运算器处理。
  科学计算：整型数据的科学计算将从64位处理中受益，浮点运算不会从中受益，因为即便是32位处理器，浮点寄存器也已经达到了80位到128位。
  需求超过4G的应用程序：如数据库服务器, 图形处理和视频压缩相关应用。

64位虚拟内存空间理论上最高可以支持直接访问2EB,不过当前的所谓64位处理器并不能真正做到，原因很简单，目前还没有机器支持那么大的物理内存。EM64T提供40位寻址能力，最大支持到1TB内存。

 

JVM 32 bit和JVM 64 bit

JVM是Java开发人员必不可少的工具，而JVM也有32 bit和64 bit之分.
那实际上32位和64位JDK有什么区别呢？
JVM 32bit 和JVM 64bit的区别如下:
  1目前只有server VM支持64bit JVM，client不支持32bit JVM。
  2 .The Java Plug-in, AWT Robot and Java Web Start这些组件目前不支持64bit JVM
  3.本地代码的影响：对JNI的编程接口没有影响，但是针对32-bit VM写的代码必须重新编译才能在64-bit VM工作。
  4.32-bit JVM堆大小最大是4G, 64-bit VMs 上, Java堆的大小受限于物理内存和操作系统提供的虚拟内存。(这里的堆并不严谨)
  5.线程的默认堆栈大小：在windows上32位JVM,默认堆栈最大是320k 64-bit JVM是1024K。
  6.性能影响:
    (1)64bit JVM相比32bit JVM,在大量的内存访问的情况下，其性能损失更少，AMD64和EM64T平台在64位模式下运行时，Java虚拟机得到了一些额外的寄存器，它可以用来生成更有效的原生指令序列。
    (2)性能上，在SPARC 处理器上，当一个java应用程序从32bit 平台移植到64bit平台的64bit JVM会用大约 10-20%的性能损失，而在AMD64和 EM64T平台上，其性能损失的范围在0-15%.

以上摘自http://java.sun.com/docs/hotspot/HotSpotFAQ.html#64bit_description

 

JVM 性能分析

Sun的官网上写着,当一个java应用程序从32bit 平台移植到64bit平台的64bit JVM上,应用会有性能损失，相信很多人都会不解。
从数字上看，我们一般会认为64位JDK比32位JDK好，但是上文说过"实际上在32bit应用程序下，32bit处理器的性能甚至会更强，即使是64bit处理器，目前情况下也是在32bit应用下性能更强"。

许多在大同世界里很简单的道理包括越多大越好，移到计算机领域里就不是那么回事了。当处理多重CPU时，你会觉得那些多核所多出来的处理单元很有用，但如果你的工作仅仅是单线程的，那你要做的却是让其他核一边歇着。

32位与64位的比较则更加细微。x86-64 架构不仅在x86架构的基础上增大了寄存器，而且还增加了寄存器的数量。从基本上说这会带来更好的性能（因为更多的寄存器可以让编译器创建更好的机器代码）。然而很不幸，至今把Java从32位移到64位带来的只是性能的下降。

Java虚拟机（JVM）是一个软件规范，其32位与64位版本性能有所不同，但它们都包括JIT编译器和垃圾回收功能（GC）,其性能关键在JIT编译器和垃圾回收功能的执行效率上。       JIT编译器实现了程序执行之前Java字节码到硬件机器码的动态翻译，其背后的思想在于，相比Java源代码，字节码更小也更容易编译，但付出的代价是需要在Java字节码编译为机器码时花上一点时间，但与直接把Java源代码编译为机器码相比，时间还是少得多的。在32位与64位的JVM中，相应的JIT在把Java字节码编译为最终的机器码时，所花的时间稍微有所不同，但还能进行一些优化；另外，在IBM与Sun这两个版本的客户端与服务端程序上，总体性能也会有所不同。 垃圾回收会收回对象不再需要使用的内存,它必须被经常执行以释放对象不再访问的Java堆。由于在32位与64位平台上，Java堆中的数据大小会有所变化，所以会因为32位与64位JVM的性能差异，然而指针越大越GC管理越困难,导致相应垃圾回收的性能也会有所不同。

 

64bit JVM的测试性能-----马力更大并不总代表性能更强

接下来主要涉及两个现在广泛应用的64位平台——AMD64与PowerPC64，并分别使用IBM与Sun Microsystems这两个Java语言巨头提供的Java虚拟机（JVM），通过SPECjvm98与SPECjbb2000的测试，来评价32位与64位中JVM的性能。使用了以下项目测试客户端性能。  2_201_compress，一个流行的压缩程序。 2 _202_jess，一个Java版的NASA CLIPS基于规则的专家系统。 2 _209_db，数据管理基准测试软件。 2_213_javac，JDK Java编译器。 2 _222_mpegaudio，一个MPEG-3音频解码器。 2 _227_mtrt，一个对图像文件进行处理的双线程程序。 2 _228_jack，一个分析程序生成器。

该测试的测试结果总结：
1 基于运行Linux操作系统的PowerPC64平台的测试结果，表明如果在此平台上使用IBM的JVM，那么，那些不需要64位特性的程序，还是让它们运行在32位JVM中，因为在此平台的所有测试结果中，64位JVM的性能都比32位平台低。

2 基于运行Linux操作系统的AMD64平台的测试结果，表明不管是Sun还是IBM的JVM，32位与64位的性能都在伯仲之间，要注意的是，性能的差异是依赖于具体的应用程序与JVM的，如果需要最佳性能，就必须在某个特定的执行环境中测试某个特定的程序，以评价转换到64位所带来的潜在性能提升。

考虑篇幅大小，这里不一一列出详细的测试报告,详细的测试报告请参考http://blog.csdn.net/xieqidong/archive/2008/03/22/2205055.aspx
这里以我们熟知的AMD64为例列出部分测试报告。

图 1

图1是在AMD64平台上，Linux版本的Sun Java 2 Standard Edition Development Kit 5.0 (J2SE 1.5.0)的性能测试报告,结果表明只有三项测试客户端——_201_compress、_222_mpegaudio、 _228_jack，在64位版本的JVM上比32位表现出更佳的性能。

图2

图2是在 AMD64平台上，Linux版本的IBM Developer Kit for Linux、Java 2 Technology Edition Version 1.4.2 GA的性能测试报告,测试结果表明只有三项测试客户端——_209_db、_213_javac、_228_jack，在64位环境下表现出了更佳的性能。

 

如何选择JVM 32bit和JVM 64bit

网上有选择JVM32bit和JVM 64bit的建议: 
1、你的应用程序是否需要超过2GB的Java Heap来获取更优的性能呢？ Yes = 64-Bit No = 32-Bit  如何判断你的应用需要多大的Java Heap呢？可以通过计算平均的Heap使用情况来确定。

2、你的应用程序是否需要高精度的科学计算进行统计、安全、加密等等？ Yes = 64-Bit No = 32-Bit 3、你的应用程序只需要小于2GB的Java Heap？（与第1点类似） Yes = 32-Bit on 64Bit OS No = 64-Bit 4、你的应用程序并不需要64位的特性，但是却是部署在64位的操作系统上？ Yes = 32-Bit No = 64-Bit 5、最重要的一点是，其他情况下那就在32位的OS上用32位的JDK

 

总结

本文介绍了32 bit系统和64bit 系统，并介绍我们常用的JVM 32bit和JVM 64bit,并进行比较分析，64bit系统虽然能访问更多的内存，操作更大的文件和磁盘管理，但是很多情况下性能其实未必比32bit系统好，尤其是JVM。
所以本人认为:在项目实施中，数据库服务器可以选择部署在64bit操作系统上，而对于应用服务器，就不能一概而论了，如果要获得应用的最佳性能，就要在应用的部署环境中进行测试，以评价转换到64位所带来的潜在性能提升，再决定是部署在JVM 32bit还是JVM 64bit。但一般情况下，除非应用需要较大的内存，并超过了2G，并且对应的服务器物理内存超过了4G，否则应该以JVM 32bit优先。