Java技術體系
如果僅從傳統(tǒng)意義上看，Sun官方所定義的Java技術體系包括了以下幾個
組成部分：
- Java程序設計語言
- 各種硬件平臺上面的Java虛擬機
- Class文件格式
- Java API類庫
- 來自商業(yè)結構和開源社區(qū)的第三方Java類庫
我們可以把Java程序設計語言、Java虛擬機、Java API類庫這三部分統(tǒng)稱為JDK。JDK是用于支持Java程序開發(fā)的最小環(huán)境。
JDK（Java Development Kit，Java開發(fā)工具包）是用來編譯、調試Java程序的開發(fā)工具包。包括Java工具（javac/java/jdb等）和Java基礎的類庫（Java API 類庫）。
JRE（Java Runtime Environment， Java運行環(huán)境）是支持Java程序運行的標準環(huán)境，所有的程序都要在JRE下才能夠運行。包括JVM和Java核心類庫和支持文件。
Java虛擬機
JVM（Java Virtual Machine， Java虛擬機）是一種用于計算設備的規(guī)范，它是一個虛構出來的計算機，是通過在實際的計算機上仿真模擬各種計算機功能來實現(xiàn)的。 Java虛擬機有自己完善的硬件架構，如處理器、堆棧等，還具有相應的指令系統(tǒng)。JVM包括一套字節(jié)碼指令集、一組寄存器、一個棧、一個垃圾回收堆和一個存儲方法域。JVM是JRE的一部分。
JVM遵循著馮·諾依曼體系結構的設計原理。馮·諾依曼體系結構中，指出計算機處理的數(shù)據(jù)和指令都是二進制數(shù)，采用存儲程序方式不加區(qū)分的存儲在同一個存儲器里，并且順序執(zhí)行，指令由操作碼和地址碼組成，操作碼決定了操作類型和所操作的數(shù)的數(shù)字類型，地址碼則指出地址碼和操作數(shù)。
從DOS到Window8，從Unix到Ubuntu和CentOS，還有MAC OS等等，不同的操作系統(tǒng)指令集以及數(shù)據(jù)結構都有著差異，而JVM通過在操作系統(tǒng)上建立虛擬機，自己定義出來的一套統(tǒng)一的數(shù)據(jù)結構和操作指令。JVM主要工作是解釋自己的指令集（即字節(jié)碼）并映射到本地的CPU指令集和OS的系統(tǒng)調用，不同的操作系統(tǒng)會有不同的JVM映射規(guī)則，使之與操作系統(tǒng)無關。（JVM屏蔽了與具體操作系統(tǒng)平臺相關的信息，把同一套語言翻譯給各大主流的操作系統(tǒng)，使得Java程序只需生成在Java虛擬機上面運行的目標代碼（字節(jié)碼），就可以在多種平臺上面不加修改的運行，從而實現(xiàn)跨平臺運行）可以說JVM是Java的核心，是Java可以一次編譯到處運行的本質所在。
JVM屏蔽了與具體操作系統(tǒng)平臺相關的信息，使Java程序只需生成在Java虛擬機上運行的目標代碼（字節(jié)碼）,就可以在多種平臺上不加修改地運行。JVM在執(zhí)行字節(jié)碼時，實際上最終還是把字節(jié)碼解釋成具體平臺上的機器指令執(zhí)行。
Java虛擬機組成
JVM由4大部分組成：ClassLoader、Runtime Data Area、Execution Engine、Native Interface
ClassLoader
ClassLoader 是負責加載class文件，Java類里getClassLoader（)默認加載器，負責加載class文件，class文件在文件開頭有特定的文件標示，并且ClassLoader只負責class文件的加載，至于它是否可以運行，則由Execution Engine決定。
Java語言系統(tǒng)自帶有三個類加載器
- Bootstrap ClassLoader 最頂層的加載類，主要加載核心類庫，%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等。另外需要注意的是可以通過啟動JVM時指定-Xbootclasspath和路徑來改變Bootstrap ClassLoader的加載目錄。比如java -Xbootclasspath/a:path被指定的文件追加到默認的bootstrap路徑中。我們可以打開我的電腦，在上面的目錄下查看，看看這些jar包是不是存在于這個目錄。
- Extention ClassLoader 擴展的類加載器，加載目錄%JRE_HOME%\lib\ext目錄下的jar包和class文件。還可以加載-D java.ext.dirs選項指定的目錄。
- Appclass Loader也稱為SystemAppClass 加載當前應用的classpath的所有類。
Native Interface
Native Interface是負責調用本地接口的。他的作用是調用不同語言的接口給JAVA用，他會在Native Method Stack中記錄對應的本地方法，然后調用該方法時就通過Execution Engine加載對應的本地lib。原本多于用一些專業(yè)領域，如JAVA驅動，地圖制作引擎等，現(xiàn)在關于這種本地方法接口的調用已經(jīng)被類似于Socket通信，WebService等方式取代。
Execution Engine
Execution Engine是執(zhí)行引擎，負責給操作系統(tǒng)解釋放入Runtime DataArea的指令和數(shù)據(jù)。
Runtime Data Area
Runtime Data Area則是存放數(shù)據(jù)的，分為五部分：Stack，Heap，Method Area，PC Register，Native Method Stack。
- 程序計數(shù)器（Program Counter Register）是一塊較小的內存空間，它可以看做是當前線程所執(zhí)行的字節(jié)碼的行號指示器。在虛擬機的概念模型里（僅是概念模型，各種虛擬機可能會通過一些更高效的方式去實現(xiàn)），字節(jié)碼解釋器工作時就是通過改變這個計數(shù)器的值來選取下一條需要執(zhí)行的字節(jié)碼指令、分支、循環(huán)、跳轉、異常處理、線程恢復等基礎功能都需要依賴這個計數(shù)器來完成。
由于Java虛擬機的多線程是通過線程輪流切換并分配處理器執(zhí)行時間的方式來實現(xiàn)的。在任何一個確定的時刻，一個處理器都只會執(zhí)行一條線程中的指令。因此，為了線程切換后能恢復到正確的執(zhí)行位置，每條線程都需要有一個獨立的程序計數(shù)器，各個線程之間計數(shù)器互不影響，獨立存儲。
程序計數(shù)器，是唯一一個在java虛擬機規(guī)范中沒有規(guī)定任何OutOfMemoryError的區(qū)域。
- Java虛擬機棧也是線程私有的，生命周期與線程相同。虛擬機棧描述的是Java方法執(zhí)行的內存模型：每個方法在執(zhí)行的同時，都會創(chuàng)建一個棧幀，用于存儲局部變量表、操作數(shù)棧、動態(tài)鏈接、方法出口等信息。平常我們把java分為堆內存和棧內存，其中的“棧”就是現(xiàn)在講的虛擬機棧，或者說是虛擬機棧中局部變量表部分。局部變量表所需的內存空間在編譯期間完成分配，當進入一個方法時，這個方法需要在棧幀中分配多大的局部變量空間是完全確定的，在方法運行期間不會改變局部變量表的大小。
Java虛擬機的解釋執(zhí)行引擎稱為“基于棧的執(zhí)行引擎”，其中所指的“棧”就是操作數(shù)棧。因此我們也稱Java虛擬機是基于棧的，這點不同于Android虛擬機，Android虛擬機是基于寄存器的。
- 本地方法棧（Native Method Stack）也是線程私有。本地方法棧和虛擬機棧所發(fā)揮的作用非常相似，它們之間的區(qū)別主要是，虛擬機棧是為虛擬機執(zhí)行Java方法（也就是字節(jié)碼）服務的，而本地方法棧則為虛擬機使用到的Native方法服務。與虛擬機棧類似，本地方法棧也會拋出StackOverflowError和OutOfMemoryError異常。
- Java堆（Java Heap）所有線程共享。Java堆在虛擬機啟動時創(chuàng)建，是Java虛擬機所管理的內存中最大的一塊。Java堆的唯一目的就是存放對象實例和數(shù)組。
Java堆是垃圾收集器管理的主要區(qū)域，因此也成為“GC堆”。從內存回收的角度來看，由于現(xiàn)在收集器大都采用分代收集算法，所以Java堆可以細分為：新生代和老年代；再細分一點：Eden空間、From Survivor空間、To Survivor空間等。從內存分配角度來看，線程共享的Java堆可以劃分出多個線程私有的分配緩沖區(qū)（Thread Local Allocation Buffer，TLAB）。但是不管怎么劃分，哪個區(qū)域，存儲的都是對象實例。
Java堆物理上不需要連續(xù)的內存，只要邏輯上連續(xù)即可。如果堆中沒有內存完成實例分配，并且也無法再擴展時，將會拋出OutOfMemoryError異常。
- 方法區(qū)（Method Area）所有線程共享。用于存儲已被虛擬機加載的類信息、常量、靜態(tài)變量、即時編譯器編譯后的代碼等數(shù)據(jù)。方法區(qū)也有一個別名叫做Non-Heap（非堆），用于與Java堆區(qū)分。對于HotSpot虛擬機來說，方法區(qū)又習慣稱為“永久代”（Permancent Generation），但這只是對于HotSpot虛擬機來說的，其他虛擬機的實現(xiàn)上并沒有這個概念。相對而言，垃圾收集行為在這個區(qū)域比較少出現(xiàn)，但也并非不會來收集，這個區(qū)域的內存回收目標主要是針對常量池的回收和對類型的卸載上。
- 運行時常量池屬于方法區(qū)。Class文件中除了有類的版本、字段、方法、接口等描述信息外，還有一項信息是常量池，用于存放編譯期生成的各種字面常量和符號引用，這部分內容將在類加載后進入方法區(qū)的運行時常量池中存放。也就是說，這部分內容，在編譯時只是放入到了常量池信息中，到了加載時，才會放到運行時常量池中去。運行時常量池縣歸于Class文件常量池的另外一個重要特征是具備動態(tài)性，Java語言并不要求常量一定只有編譯期才能產生，也就是并非預置入Class文件中常量池的內容才能進入方法區(qū)的運行時常量池，運行期間也可能將新的常量放入池中，這種特性被開發(fā)人員利用的比較多的是String類的intern()方法。
HotSpot虛擬機對象探秘
對象的創(chuàng)建
（1）判斷類是否加載、解析、初始化
虛擬機遇到一條new指令時，先去檢查這個指定的參數(shù)是否能在常量池中定位到一個類的符號引用，并且檢查這個符號引用代表的類是否已被加載、解析和初始化過。如果沒有，那先執(zhí)行相應的類加載過程。
（2）為新對象分配內存
在類加載檢查通過后，接下來虛擬機將為新生對象分配內存。對象所需內存的大小在類加載完成后便可完全確定。對象的內存分配是在Java堆中的，為對象分配空間的任務等同于把一塊確定大小的內存從Java堆中劃分出來，此時Java堆中的情況有兩種可能，一種是Java堆中內存是絕對規(guī)整的，一種是Java堆中的內存并不是規(guī)整的。因此有兩種分配方式：
1）Java堆內存是規(guī)整的，即所有用過的內存都放在一邊，空閑的內存放在另一邊，中間放著一個指針作為分界點的指示器，此時，分配內存僅需要把這個指針向空閑空間那邊挪動一段與對象大小相等的距離，這種方式也稱為“指針碰撞”（Bump the Pointer）；
2）Java堆內存不是規(guī)整的，即已使用的內存和空閑的內存相互交錯，就沒有辦法簡單地進行指針的移動，此時的分配方案是，虛擬機必須維護一個列表，記錄上哪些內存塊是可用的，在分配的時候從列表中找到一塊足夠大的控件劃分給對象實例，并更新列表上的記錄，這種方式也稱為“空閑列表”（Free List）；
選擇哪種分配方式由Java堆是否規(guī)整決定，而Java堆是否規(guī)整又由所采用的垃圾收集器是否帶有壓縮整理功能決定。因此，對于Serial、ParNew等帶Compact過程的垃圾收集器，系統(tǒng)采用的是指針碰撞算法；對于CMS這種基于Mark-Sweep算法的收集器，通常采用空閑列表算法。
（3）解決并發(fā)安全問題
確定了如何劃分內存空間之后，還有一個問題就是，對象的創(chuàng)建在虛擬機中是非常頻繁的行為，比如，可能出現(xiàn)正在給對象A分配內存，指針還沒來得及修改，對象B又同時使用了原來的指針來分配內存的情況，解決這種并發(fā)問題，一般有兩種方案：
1）對分配內存空間的動作進行同步處理，比如，虛擬機采用CAS配上失敗重試的方式保證更新操作的原子性；
2）另一種方式是，把內存分配的動作按照線程劃分在不同的空間之中進行，即每個線程在Java堆中預先分配一小塊內存，稱為本地線程分配緩沖（Thread Local Allocation Buffer，TLAB），哪個線程要分配內存，就在哪個線程的TLAB上分配。只有TLAB用完并分配新的TLAB時，才需要同步鎖定，虛擬機是否使用TLAB，可以通過-XX:+/-UserTLAB參數(shù)來設定。
（4）初始化分配到的內存空間
內存分配完成后，虛擬機將分配到的內存空間都初始化為零值（不包括對象頭），如果使用TLAB，這一工作也可以提前至TLAB分配時進行。也正是這一步操作，才保證了我們對象的實例字段在Java代碼中可以不賦初值就直接使用。注意，此時對象的實例字段全部為零值，并沒有按照程序中的初值進行初始化。
（5）設置對象實例的對象頭
上面工作完成后，虛擬機對對象進行必要的設置，主要是設置對象的對象頭信息。例如這個對象是哪個類的實例、如何才能找到類的元數(shù)據(jù)信息、對象的哈希碼、對象的GC分代年齡等信息。這些信息存放在對象的對象頭（Object Header）之中。根據(jù)虛擬機當前的運行狀態(tài)的不同，如是否啟用偏向鎖等，對象頭會有不同的設置方式。
（6）初始化對象<init>方法
其實，上面工作完成后，從虛擬機角度來看，一個新的對象已經(jīng)產生了，但從Java程序的角度來看，對象創(chuàng)建才剛剛開始，對象實例中的字段僅僅都為零值，還需要通過<init>方法進行初始化，把對象按照程序員的意愿進行初始化。此時，一個真正可用的對象才算完全產生出來。
對象的內存布局
不同的虛擬機實現(xiàn)中，對象的內存布局有差別，以最常用的HotSpot虛擬機為例。HotSpot虛擬機中，對象在內存中存儲的布局可以分為三塊區(qū)域：對象頭（Header）、實例數(shù)據(jù)（Instance Data）和對齊填充（Padding）。
1）對象頭：包含兩部分信息，一部分是用于存儲對象自身的運行時數(shù)據(jù)，如哈希碼、GC分代年齡、鎖狀態(tài)標志等；另一部分是類型指針，即對象指向它的類元數(shù)據(jù)的指針，虛擬機通過這個指針來確定這個對象是哪個類的實例。如果對象是一個Java數(shù)組，對象頭中還有一塊用于記錄數(shù)組長度的數(shù)據(jù)，因為虛擬機可以通過普通Java對象的元數(shù)據(jù)信息確定Java對象的大小，但是從數(shù)組的元數(shù)據(jù)中卻無法確定數(shù)組大小。
2）實例數(shù)據(jù)：真正存儲對象有效信息的部分。也就是在程序中定義的各種類型的字段內容，包括從父類繼承下來的，以及子類中定義的，都會在實例數(shù)據(jù)中記錄。
3）對齊填充：不是必然存在的，僅起著占位符的作用，對于HotSpot來說，虛擬機的自動內存管理系統(tǒng)要求對象其實地址必須是8字節(jié)的整數(shù)倍，因此，如果對象實例數(shù)據(jù)部分沒有對齊時，就需要通過對齊填充的方式來補全。
對象的訪問定位
建立對象是為了使用對象，我們的Java程序需要通過棧上的reference數(shù)據(jù)來操作堆上的具體對象。由于reference類型在Java虛擬機規(guī)范里面只規(guī)定了是一個指向對象的引用，并沒有定義這個引用應該通過什么種方式去定位、訪問到堆中的對象的具體位置，對象訪問方式也是取決于虛擬機實現(xiàn)而定的。主流的訪問方式有使用句柄和直接指針兩種。
1）通過句柄訪問對象
如果使用句柄訪問的話，Java堆中將會劃分出一塊內存來作為句柄池，reference中存儲的就是對象的句柄地址，而句柄中包含了對象實例數(shù)據(jù)與類型數(shù)據(jù)的具體各自的地址信息。
2）通過直接指針訪問對象
如果使用直接指針訪問的話，Java堆對象的布局中就必須考慮如何放置訪問類型數(shù)據(jù)的相關信息，reference中存儲的直接就是對象地址。
這兩種對象訪問方式各有優(yōu)勢，使用句柄來訪問的最大好處就是reference中存儲的是穩(wěn)定句柄地址，在對象被移動（垃圾收集時移動對象是非常普遍的行為）時只會改變句柄中的實例數(shù)據(jù)指針，而reference本身不需要被修改。
使用直接指針來訪問最大的好處就是速度更快，它節(jié)省了一次指針定位的時間開銷，由于對象訪問的在Java中非常頻繁，因此這類開銷積小成多也是一項非常可觀的執(zhí)行成本。從上一部分講解的對象內存布局可以看出，就虛擬機HotSpot而言，它是使用第二種方式進行對象訪問，但在整個軟件開發(fā)的范圍來看，各種語言、框架中使用句柄來訪問的情況也十分常見
Java內存模型
JMM(Java Memory Model，Java內存模型)，Java虛擬機是一個完整的計算機的一個模型，因此這個模型自然也包含一個內存模型—又稱為Java內存模型。Java內存模型規(guī)范了Java虛擬機與計算機內存是如何協(xié)同工作的，來屏蔽掉各種硬件和操作系統(tǒng)的內存訪問差異，以實現(xiàn)讓Java程序在各平臺下都能達到一致的內存訪問效果。
物理計算機在處理運算任務的時候加入了高速緩存來調和處理器以及內存之間不同數(shù)量級導致的耗時問題：將需要運算的數(shù)據(jù)復制到緩存中，然后進行高速運算，之后再由緩存同步回內存中。物理計算機制定讀寫協(xié)議，使各個處理器在訪問涉及同一主存區(qū)域的緩存時遵循指定的協(xié)議，解決**緩存一致性問題。在Java虛擬機中，定義了一種Java內存模型，類比物理計算機對并發(fā)過程中緩慢存數(shù)據(jù)的處理方式。
Java內存模型的主要目標是定義程序中各個變量的訪問規(guī)則，即在JVM中將變量存儲到內存和從內存中取出變量這樣的底層細節(jié)。此處的變量與Java編程里面的變量有所不同步，它包含了實例字段、靜態(tài)字段和構成數(shù)組對象的元素，但不包含局部變量和方法參數(shù)，因為后者是線程私有的，不會共享，當然不存在數(shù)據(jù)競爭問題（如果局部變量是一個reference引用類型，它引用的對象在Java堆中可被各個線程共享，但是reference引用本身在Java棧的局部變量表中，是線程私有的）。為了獲得較高的執(zhí)行效能，Java內存模型并沒有限制執(zhí)行引起使用處理器的特定寄存器或者緩存來和主內存進行交互，也沒有限制即時編譯器進行調整代碼執(zhí)行順序這類優(yōu)化措施。
