【PC-x86-x64】JDK 32bit与64bit的区别及x64 PC的发展历程【转】
一次偶然分析的机会：
在进行Minecraft也就是所谓的我的世界游戏的时候，在对局域网进行开放的时候，我的是64bit的JDK，而我同学的是32bit的JDK，所以在进行局域网链接的时候就会出现Internal Exception:java.lang.NullPointerException ，
在此我就先来分析一下为什么会产生这样的异常?
解析错误：
首先肯定是网络异常：java空指针，但是在处理和检查完网络没有错误的前提下，再次尝试之后发现依然是这样的问题，查看了是使用32bit的JDK的时候，而自己的操作系统是64bit并且我的是64bit的时候， 尝试换一下
JDK的操作位数(也就是从32bit更换到64bit)。更换完成之后，发现异常解决，所以觉得需要分析一下JDK的使用位数的影响，以此去找到答案。
32bit和64bit系统在计算机领域中常常提及，但是还是会存在这种情况，很多人不知道它们之间的差异。所以在分析32bit和64bit的时候， 需要从处理器、操作系统以及JVM出发。Big-man接下来会逐步地进行较为详细的解答。
处理器（IA（Intel Architecture））：
提及IA,市场上用到的最多的也就是莫过于Intel, 所以在这里讲解一下Intel处理器的32bit和64bit的处理器之分。
Intel:
通常采用Intel（英特尔）处理器的服务器称之为IA（Intel Architecture）架构服务器，又称CISC（Complex Instruction Set Computer复杂指令集）架构服务器，由于IA架构服务器是基于PC端的x86处理器体系结构的，所以又把
IA架构的服务器称为PC服务器或者x86服务器。
虽然IA架构服务器始于PC，但经过不断的发展，IA架构服务器已经远远超出了PC的范畴。
IA根据官方的需求，分为一下三类：
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。Big-man所知道也就是Intel和AMD了。
8086是16位处理器；直到1985年32位的80386的开发，这个架构都维持是16位。
Intel 80386 32位处理器推出后，也许是目前为止x86最大跃进。Linux , 386BSD , Windows NT 和 Windows 95都是一开始为386所发展的，这种系列的386架构成为未来开发的所有x86系列的基础。
现实中把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架构的处理器，那一年Big-man还没有出生了，真的是没赶上趟啊。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架构的这两款处理器前景不容乐观。所以Big-man在现在市场上还可以看见AMD的存在。
EM64T:
为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。两家自主研发的公司都分别为了自己的旗帜而
开始了如火如荼的竞争，Big-man觉得技术就是在竞争中得到革新的和进步的。
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扩展模式，两大类下具体又可分为多种运行模式
传统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位。这在Big-man的数学章节里面会进行换算的。
需求超过4G的应用程序：如数据库服务器, 图形处理和视频压缩相关应用。
64位虚拟内存空间理论上最高可以支持直接访问2EB,不过当前的所谓64位处理器并不能真正做到，原因很简单，目前还没有机器支持那么大的物理内存。EM64T提供40位寻址能力，最大支持到1TB内存。
在接下来Big-man分析:JVM 32 bit和JVM 64 bit
JVM是Java开发人员必不可少的工具，而JVM也有32 bit和64 bit之分。这个问题的重要性讨论我就不在这里赘述了，Big-man相信每一个进行Java开发的程序猿/媛都会存在这样的意识的。
那实际上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（Java Native Interface）的编程接口没有影响，但是针对32-bit VM写的代码必须重新编译才能在64-bit VM工作。
4、32-bit JVM堆大小最大是4G, 64-bit VMs 上, Java堆的大小受限于物理内存和操作系统提供的虚拟内存。(这里的堆并不严谨，Big-man这里地不眼睛指的是不像数据结构中的堆是一种存储数据的结构。)
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%。所以JVM的性能还和Big-man这样的程序猿手中的电脑配置的好坏有关了。
如果你还想更清楚地了解一下的话可以去它的官网看看，但是你的English需要一定的功底：Java-Sun
JVM 性能分析:
Sun的官网上写着, 当一个java应用程序从32bit 平台移植到64bit平台的64bit JVM上, 应用会有性能损失，相信很多人都会不解，比如Big-man。 Su公司是一个伟大的公司。
从数字上看，我们一般会认为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编译器：
JIT编译器实现了程序执行之前Java字节码到硬件机器码的动态翻译，其背后的思想在于，相比Java源代码，字节码更小也更容易编译，但付出的代价是需要在Java字节码编译为机器码时花上
一点时间，但与直接把Java源代码编译为机器码相比，时间还是少得多的。在32位与64位的JVM中，相应的JIT在把Java字节码编译为最终的机器码时，所花的时间稍微有所不同，但还能进行
一些优化；另外，在IBM与Sun这两个版本的客户端与服务端程序上，总体性能也会有所不同。
垃圾回收功能（GC）:
垃圾回收会收回对象不再需要使用的内存,它必须被经常执行以释放对象不再访问的Java堆。由于在32位与64位平台上，Java堆中的数据大小会有所变化，所以会因为32位与64位JVM的性能差异，然而
指针越大越GC管理越困难,导致相应垃圾回收的性能也会有所不同。
64bit JVM的测试性能—–马力更大并不总代表性能更强
网上有选择JVM32bit和JVM 64bit的建议:
1、你的应用程序是否需要超过2GB的Java Heap来获取更优的性能呢？ Yes = 64-Bit No = 32-Bit 如何判断你的应用需要多大的Java Heap呢？可以通过计算平均的Heap使用情况来确定。
对于这个问题，Big-man的意思就是清楚自己的目的和所开发的意义是什么？
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。
所以Big-man想要给出一些建议和认识:
在项目实施中，数据库服务器可以选择部署在64bit操作系统上；
而对于应用服务器，就不能一概而论了，如果要获得应用的最佳性能，就要在应用的部署环境中进行测试，以评价转换到64位所带来的潜在性能提升，再决定是部署在JVM 32bit还是JVM 64bit。
但一般情况下，除非应用需要较大的内存，并超过了2G，并且对应的服务器物理内存超过了4G，否则应该以JVM 32bit优先。
---------------------
作者：JD9
来源：CSDN
原文：https://blog.csdn.net/XXJ19950917/article/details/73527313
版权声明：本文为博主原创文章，转载请附上博文链接！
