关于java的跨平台特性

比眉伴天荒 2022-01-09 12:57 247阅读 0赞

**Write once, compile anywhere，“一次编译，到处运行”的著名口号大家想必都听说过吧**  
一次编译：把java代码（.java文件）通过编译器转换成字节码（.class文件）（符合java规范的二进制数）  
到处运行：指的也就是java的跨平台性，即相同的字节码放在不同的操作系统上，运行出来的结果依旧是一样的。

> java不仅仅只是狭义的一门高级语言，更是一种java体制

到这里我还是对Write once, compile anywhere没有任何概念，难道别的高级语言就不可以吗。

我们来看看另一门高级语言c语言。我们编写了一个hello.c文件，linux下编译结果是hello,window下编译结果是hello.exe,而mac下编译结果是hello.out。我们无法把别的平台下的编译结果拿到当前平台下进行运行。  
仅仅只是因为后缀名（扩展名）不同导致的吗，我们把c语言编译后的结果后缀名都统一成一种格式就可以了吗？当然不是！即使面对的是同一个后缀名的执行程序，不同的平台,不同的芯片，不同的环境（32位，64位）的指令集合也完全不同。编译出来的结果也千差万别

仔细想想电脑所有的文件都是二进制文件，不同的是操作系统需要通过不同的后缀名来使用不同的软件打开该文件。所以错不在后缀名上，错在不同操作系统解析这些二进制代码的方式各有所不同，产生的结果也各不相同。

举个例子 现在写了一个马冬梅.c 的程序（printf(“我叫马冬梅”)）,将它放在不同系统中执行的结果  
window（32位）:我叫马梅  
window（64位）:我叫马冬梅  
linux:我叫马东  
mac:我叫冬梅

java虚拟机定义的二进制格式，这种我们称之为 字节码(ByteCode),是java虚拟机所能运行的格式

那么JVM又是怎么实现跨平台的呢？  
首先指定规则告诉编译器我们不搞特殊，我们所有平台都一视同仁，你们编译出来的java代码的后缀必须是.class文件，到这一步，其实也没有解决实质性的问题，就是操作系统不能正确解析字节码。  
既然操作系统解决不了的问题，那么我们自己解决，我们在操作系统前来解析这些字节码。

打一个比方，将这些操作系统比作windows比作美国人，mac比作韩国人，Linux比作日本人。  
如果这个时候我们对他们说我爱你，他们当然听不懂。但是可以使用一个类似翻译机的东西  
我爱你->英语翻译器->I love you 美国人（windows）听懂了  
我爱你->韩语翻译器->사랑해 韩国人（mac）听懂了  
我爱你->日语翻译器->あなたのことが好きです 日本人（Linux）听懂了

这翻译器都做是同一个工作就是让外国人听懂（操作系统执行正确的指令）。JVM就是这些翻译器，尽管平台再多，我们对应每一个平台我们都给他整一个翻译器。然后我们收到的必须是中文（规定编译器解析出同一个类型的文件.class），我们就能翻译个外国人听，让他们听懂（JVM执行字节码，得到相同的结果）

软件都要根据平台下载，有些还要严格区分32位/64位

![1529236-20190413175326415-736045516.png][]

jvm也不另外(不同款式的翻译机，操作系统找到适合自己的翻译机就能运行啦)

![1529236-20190413175332821-1855767824.png][]

总结：原来jvm的存在已经为我们解决解决了跨平台的问题，也解决了GC（垃圾回收，再后面会提到），内存管理......当然有利就有弊，在算法网站可以明显看到同样的算法运行时长最短的永远是c/c++。  
最后说一点我对跨平台的看法：我个人觉得java的跨平台的特性十分适合于技术适合网络世界，当请求调用服务时：java对象被序列化成二进制流/java类的字节码文件传输到别的机器上的时候能快速的通过java虚拟机解析出来，执行下一步操作，而不再需要考虑机器类型。

转载于:https://www.cnblogs.com/Gang-Bryant/p/10702161.html

[1529236-20190413175326415-736045516.png]: /images/20220109/9e69a3089e8d4e218b3e372b8c271306.png
[1529236-20190413175332821-1855767824.png]: /images/20220109/f6e4f334acad446eb7661721ffd8e0c1.png