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位
jvm也不另外(不同款式的翻譯機，操作系統找到適合自己的翻譯機就能運行啦)
總結：原來jvm的存在已經為我們解決解決了跨平台的問題，也解決了GC（垃圾回收，再后面會提到），內存管理......當然有利就有弊，在算法網站可以明顯看到同樣的算法運行時長最短的永遠是c/c++。
最后說一點我對跨平台的看法：我個人覺得java的跨平台的特性十分適合於技術適合網絡世界，當請求調用服務時：java對象被序列化成二進制流/java類的字節碼文件傳輸到別的機器上的時候能快速的通過java虛擬機解析出來，執行下一步操作，而不再需要考慮機器類型。