其实就是因为操作系统有32位和64位,这两者有什么区别呢?
引用链接 http://blog.sina.com.cn/s/blog_4adc4b090102vr3a.html
所谓32位处理器就是一次只能处理32位,也就是4个字节的数据,而64位处理器一次就能处理64位,即8个字节的数据。如果我们将总长128位的指令分别按照16位、32位、64位为单位进行编辑的话:旧的16位处理器,比如Intel 80286 CPU需要8个指令,32位的处理器需要4个指令,而64位处理器则只要两个指令,显然,在工作频率相同的情况下,64位处理器的处理速度会比16位、32位的更快。而且除了运算能力之外,与32位处理器相比,64位处理器的优势还体现在系统对内存的控制上。由于地址使用的是特殊的整数,而64位处理器的一个ALU(算术逻辑运算器)和寄存器可以处理更大的整数,也就是更大的地址。传统32位处理器的寻址空间最大为4GB,使得很多需要大容量内存的数据处理程序在这时都会显得捉襟见肘,形成了运行效率的瓶颈。而64位的处理器在理论上则可以达到1800万个TB,1TB等于1024GB,1GB等于1024MB,所以64位的处理器能够彻底解决32位计算系统所遇到的瓶颈现象,速度快人一等,对于那些要求多处理器可扩展性、更大的可寻址内存、视频/音频/三维处理或较高计算准确性的应用程序而言,AMD 64处理器可提供卓越的性能。
引用链接 http://blog.sina.com.cn/s/blog_4adc4b090102vr3a.html
所谓32位处理器就是一次只能处理32位,也就是4个字节的数据,而64位处理器一次就能处理64位,即8个字节的数据。如果我们将总长128位的指令分别按照16位、32位、64位为单位进行编辑的话:旧的16位处理器,比如Intel 80286 CPU需要8个指令,32位的处理器需要4个指令,而64位处理器则只要两个指令,显然,在工作频率相同的情况下,64位处理器的处理速度会比16位、32位的更快。而且除了运算能力之外,与32位处理器相比,64位处理器的优势还体现在系统对内存的控制上。由于地址使用的是特殊的整数,而64位处理器的一个ALU(算术逻辑运算器)和寄存器可以处理更大的整数,也就是更大的地址。传统32位处理器的寻址空间最大为4GB,使得很多需要大容量内存的数据处理程序在这时都会显得捉襟见肘,形成了运行效率的瓶颈。而64位的处理器在理论上则可以达到1800万个TB,1TB等于1024GB,1GB等于1024MB,所以64位的处理器能够彻底解决32位计算系统所遇到的瓶颈现象,速度快人一等,对于那些要求多处理器可扩展性、更大的可寻址内存、视频/音频/三维处理或较高计算准确性的应用程序而言,AMD 64处理器可提供卓越的性能。
理论上来说32位的JVM有4G的堆大小限制。但是因为各种条件限制比如交换区,内核地址空间使用,内存碎片,虚拟管理机的管理开销,实际上可用的堆的大小远远比理论上的4G要少。
在32位windows的机器上,堆最大可以达到1.4G至1.6G。
在32位solaris的机器上,堆最大可以达到2G
而在64位的操作系统上,32位的JVM,堆大小可以达到4G
补充一句,在使用java参数-xms -xmx定义堆大小的时候,
1. 如果是32bit的jvm超过4G肯定是没用的,定义了4G,最终使用到的可能只有2G
2. 这两个值最好定义成一样,可以减少java gc的操作,有小幅度性能提高
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管理越困难,导致相应垃圾回收的性能也会有所不同。