【Java核心技术卷】谈谈对Java平台的理解
專題 | 談談對Java平臺的理解
2019年4月24日下午 ?? 沉曉
`
Java平臺如何理解
Java平臺的體系包括了以下幾個重要組成部分：
- Java程序設計語言
- Class文件格式
- 各種硬件平臺上的Java虛擬機
- Java API類庫及相關工具
- 來自商業機構和開源社區第三方Java類庫
就Java平臺而言, Java是一種面向對象的語言,它擁有兩個顯著的特性:
大部分情況下，程序員不需要自己操心內存的分配和回收。
說到跨平臺, 就需要引入Java的從源代碼到執行的過程存在的機制了:
Java源程序首先要通過編譯,翻譯成字節碼文件(.class文件), 字節碼文件再通過Java的虛擬機的解釋器和JIT(即時編譯器),翻譯成二進制交給CPU進行執行.
所有的程序,最終都要回歸二進制,由CPU進行執行, 跨平臺的關鍵就在于編譯之后,:
首先講一下虛擬機(JVM), JVM有針對各個操作系統對應的版本, 能夠調用相應操作系統的API, 對于這種"中間件",需要建立一套標準,這套標準的語言規范就是字節碼語言規范.
你可能會迷惑,我這里說明一下, Java程序語言規范不同于字節碼語言規范, Java誕生早期,它們在語法上類似,功能上類似.
隨著Java的發展, Java需要引入了很多特性,但是作為JVM支持的字節碼語言規范不能夠輕易變更, 就需要在Java程序語言規范和編譯器上加一些東西,使JVM能夠支持, 比如說泛型和內部類, JVM是不認這個的, 只是編譯器動了一些手腳,讓JVM能夠去支持,如果想進一步了解,可以看我的專欄 <Java核心技術 卷1>
Java編譯器編譯Java后翻譯成字節碼文件,而不是二進制,使得Java具備了跨平臺的能力.
說到這里,想多點關于JVM將字節碼文件翻譯成二進制的過程,
JVM采用 解釋和編譯混合的一種模式，即所謂的混合模式（-Xmixed）。
通常運行在 server 模式的 JVM，會進行上萬次調用以收集足夠的信息進行高效的編譯，client 模式這個門限是 1500 次。
Java發展那么多年,經過統計研究表明, "絕大多數應用程序,都表現為: 小部分的代碼,耗費了大多數的資源", 基于這種分析,有些方法和代碼塊是高頻率調用的，也就是所謂的熱點代碼，所以通過即時編譯器，提前將這類字節碼直接編譯成本地機器碼。這樣類似于緩存技術，運行時再遇到這類代碼直接可以執行，而不是先解釋后執行,這也是Java速度為什么提高如此之快的原因了.但是千萬別認為,編譯后,再去執行速度就會很快, “-Xcomp”會導致 JVM 啟動變慢非常多，同時有些 JIT 編譯器優化方式，比如分支預測，如果不進行 profiling，往往并不能進行有效優化。
解釋: server是服務器端 client是客戶端
Oracle Hotspot JVM 內置了兩個不同的 JIT compiler，C1 對應前面說的 client 模式，適用于對于啟動速度敏感的應用，比如普通 Java 桌面應用；C2 對應 server 模式，它的優化是為長時間運行的服務器端應用設計的。默認是采用所謂的分層編譯（TieredCompilation）。關于分層編譯的內容,以后會寫到.
Oracle JDK9 支持分層編譯和 AOT 協作使用， 其中AOT（Aheadof-Time Compilation），直接將字節碼編譯成機器代碼，這樣就避免了 JIT 預熱等各方面的開銷，因為我個人對這個也不太了解,可以參考http://openjdk.java.net/jeps/295。
在這里突然想穿插一些內容:
Python的熱度近年來持續升高, 加之go語言和Node.js的發展,多少撼動了Java后端的地位.
但是未來的主流是混合編程, 現在Python是通過解釋器執行的, 但是Python通過某種改變可以在Jython(虛擬機)上面運行,這也是Java虛擬機帶動發展的結果. 如果走到了混合編程的那一天,在不同的場景選擇合適的語言, 帶來的好處將超乎人們的想象.
對于垃圾回收機制, 今后,我會開一個專欄<深入理解Java虛擬機>,你或許聽過這本書,我會在這個專欄里,記載我的感悟. 還有 Java API類庫及相關工具 和 來自商業機構和開源社區第三方Java類庫, 這個就需要項目經驗了, 靠時間博得的東西拉不開差距, 拉得開差距的地方在于對Java核心技術的掌握, 無非就是你付出了多少時間 ,你忍受了多少寂寞, 耐住性子深入學習了多久.
總結
以上是生活随笔為你收集整理的【Java核心技术卷】谈谈对Java平台的理解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 递归修改子目录及文件的权限
- 下一篇： Android框架式编程之BufferK