深入理解java虛擬機——JAVA虛擬機程序計數器深度解析這一篇就夠了

目錄

一、開篇介紹

二、程序計數器(Program Counter Register)

       ------ 程序計數器在虛擬機中的特點

       ------ 程序計數器在虛擬機整體架構中的位置

三、JAVA虛擬機多線程的執行過程

       ------ Java調度機制

       ------ Java中線程的狀態分爲6種

四、java多線程下程序計數器如何起作用的:

五、番外篇

 


 

開篇介紹

 

1、前篇介紹了【 JAVA虛擬機堆內存結構以及堆內存作用對象回收機制 】,主要包含四部分

    一、堆區(Heap) 

    二、對象的內存佈局

    三、對象的訪問定位

    四、Java堆的內存劃分

2、前篇博文已將對JVM虛擬機內存中的 方法棧 【JAVA虛擬機內存結構之虛擬機棧(JVM Stack)】做了詳細的介紹,棧的四大部分:

虛擬機棧主要用於存儲四部分內容

棧幀(Stack Frame)

        ------ 局部變量表

        ------ 操作數棧

        ------ 動態連接

        ------ 方法返回地址

想了解棧的內存結構,已將棧的運行原理,可以去看一下。

 

想了解JVM整體內存架構的可以看一下這篇博文  【JAVA虛擬機的整體內存模型】,可以從整體瞭解虛擬機的組成,以及各部分功能如何組合在一起工作的。

 

下面開始本篇主要介紹的內容

 


 

一、程序計數器(Program Counter Register)


程序計數器 是一個比較小的內存區域,用於指示當前線程所執行的字節碼執行到了第幾行,可以理解爲是當前線程的行號指示器。字節碼解釋器在工作時,會通過改變這個計數器的值來取下一條語句指令。

  每個程序計數器只用來記錄  一個線程的行號,所以它是線程私有(一個線程就有一個程序計數器)的。

  如果程序執行的是一個Java方法,則計數器記錄的是正在執行的  虛擬機字節碼指令地址 ;如果正在執行的是一個本地(native,由C語言編寫完成)方法,則計數器的值爲Undefined,由於程序計數器只是記錄當前指令地址,所以不存在內存溢出的情況,因此,程序計數器也是所有JVM內存區域中唯一一個沒有定義OutOfMemoryError的區域。

 

程序計數器在虛擬機中的特點

  1. 線程私有的。
  2. 是java虛擬機規範裏面, 唯一 一個 沒有規定任何 OutOfMemoryError 情況的區域。
  3. 生命週期隨着線程,線程啓動而產生,線程結束而消亡。

 

程序計數器在虛擬機整體架構中的位置

 

程序計數器是最小的一塊內存區域,它可以看作是當前線程所執行的字節碼的行號指示器
每條線程需要有一個獨立的程序計數器(線程私有),以保證線程切換後能恢復到正確的執行位置。

 

JAVA虛擬機多線程的執行過程

 

Java調度機制

所有的Java虛擬機都有一個線程調度器,用來確定那個時刻運行那個線程。主要包含兩種:搶佔式線程調度器和協作式線程調度器。

  • 搶佔式線程調度:每個線程可能會有自己的優先級,但是優先及並不意味着高優先級的線程一定會被調度,而是由CPU隨機的選擇,所謂搶佔式的線程調度,就是說一個線程在執行自己的任務時,雖然任務還沒有執行完,但是CPU會迫使它暫停,讓其它線程佔有CPU的使用權。
  • 協作式線程調度:每個線程可以有自己的優先級,但優先級並不意味着高優先級的線程一定會被最先調度,而是由cpu時機選擇的,所謂協作式的線程調度,就是說一個線程在執行自己的任務時,不允許被中途打斷,一定等當前線程將任務執行完畢後纔會釋放對cpu的佔有,其它線程纔可以搶佔該cpu。

兩者對比:

搶佔式線程調度不易發生飢餓現象,不易因爲一個線程的問題而影響整個進程的執行,但是其頻繁阻塞與調度,會造成系統資源的浪費。協作式的線程調度很容易因爲一個線程的問題導致整個進程中其它線程飢餓。

java的用法:

Java在調度機制上採用的是搶佔式的線程調度機制。

Java線程在運行的過程中多個線程之間式協作式的。

 

 

Java虛擬機的多線程是通過線程輪流切換分配處理執行時間的方式來實現的。
在任何一個確定的時刻,一個處理器(對於多核處理器來說是一個內核)都只會執行一條程序中的指令。

線程的執行需要操作系統分配執行時間片 ,當時間片使用完後,線程就會被掛起

 

 

Java中線程的狀態分爲6種

1. 初始(NEW):新創建了一個線程對象,但還沒有調用start()方法。
2. 運行(RUNNABLE):Java線程中將就緒(ready)和運行中(running)兩種狀態籠統的稱爲“運行”。
線程對象創建後,其他線程(比如main線程)調用了該對象的start()方法。該狀態的線程位於可運行線程池中,等待被線程調度選中,獲取CPU的使用權,此時處於就緒狀態(ready)。就緒狀態的線程在獲得CPU時間片後變爲運行中狀態(running)。
3. 阻塞(BLOCKED):表示線程阻塞於鎖。
4. 等待(WAITING):進入該狀態的線程需要等待其他線程做出一些特定動作(通知或中斷)。
5. 超時等待(TIMED_WAITING):該狀態不同於WAITING,它可以在指定的時間後自行返回。
6. 終止(TERMINATED):表示該線程已經執行完畢。

這6種狀態定義在Thread類的State枚舉中,可查看源碼進行一一對應。

 

 

java多線程下程序計數器如何起作用的:

 

1.線程隔離性,每個線程工作時都有屬於自己的獨立計數器。
2.執行java方法時,程序計數器是有值的,且記錄的是正在執行的字節碼指令的地址(參考上一小節的描述)。
3.執行native本地方法時,程序計數器的值爲空(Undefined)。因爲native方法是java通過JNI直接調用本地C/C++庫,可以近似的認爲native方法相當於C/C++暴露給java的一個接口,java通過調用這個接口從而調用到C/C++方法。由於該方法是通過C/C++而不是java進行實現。那麼自然無法產生相應的字節碼,並且C/C++執行時的內存分配是由自己語言決定的,而不是由JVM決定的。

字節碼解釋器工作時通過改變這個計數器的值來選取下一條需要執行的字節碼指令。
分支、循環、跳轉、異常處理、線程恢復等基礎功能都需要依賴這個計數器來完成。

 

關於class指令如何解析查看,可以看我的這篇文章  JAVA虛擬機內存結構之虛擬機棧(JVM Stack) , 裏面有詳細的步驟。

 

 

 

番外篇

 

Java中線程的狀態詳解

1. 初始狀態
實現Runnable接口和繼承Thread可以得到一個線程類,new一個實例出來,線程就進入了初始狀態。

2.1. 就緒狀態
就緒狀態只是說你資格運行,調度程序沒有挑選到你,你就永遠是就緒狀態。
調用線程的start()方法,此線程進入就緒狀態。
當前線程sleep()方法結束,其他線程join()結束,等待用戶輸入完畢,某個線程拿到對象鎖,這些線程也將進入就緒狀態。
當前線程時間片用完了,調用當前線程的yield()方法,當前線程進入就緒狀態。
鎖池裏的線程拿到對象鎖後,進入就緒狀態。
2.2. 運行中狀態
線程調度程序從可運行池中選擇一個線程作爲當前線程時線程所處的狀態。這也是線程進入運行狀態的唯一一種方式。

3. 阻塞狀態
阻塞狀態是線程阻塞在進入synchronized關鍵字修飾的方法或代碼塊(獲取鎖)時的狀態。

4. 等待
處於這種狀態的線程不會被分配CPU執行時間,它們要等待被顯式地喚醒,否則會處於無限期等待的狀態。

5. 超時等待
處於這種狀態的線程不會被分配CPU執行時間,不過無須無限期等待被其他線程顯示地喚醒,在達到一定時間後它們會自動喚醒。

6. 終止狀態
當線程的run()方法完成時,或者主線程的main()方法完成時,我們就認爲它終止了。這個線程對象也許是活的,但是,它已經不是一個單獨執行的線程。線程一旦終止了,就不能復生。
在一個終止的線程上調用start()方法,會拋出java.lang.IllegalThreadStateException異常。

 

調用obj的wait(), notify()方法前,必須獲得obj鎖,也就是必須寫在synchronized(obj) 代碼段內。

與等待隊列相關的步驟和圖

 

同步隊列和等待隊列的概念:

簡單的理解是同步隊列存放着競爭同步資源的線程的引用(不是存放線程),而等待隊列存放着待喚醒的線程的引用。

我感覺同步隊列(應該叫多個啓動start()方法的線程開始競爭鎖的一個池)就是存放着 【調用線程的start()方法,此線程進入就緒狀態】,就緒狀態的線程應該就被放在了同步隊列中,競爭CPU的時間片,然後進入運行狀態

 

等待隊列

當線程執行了wait()方法,或者LockSupport.park(),則會進入等待隊列等待喚醒。

 

同步隊列狀態


當前線程想調用對象A的同步方法時,發現對象A的鎖被別的線程佔有,此時當前線程進入同步隊列。簡言之,同步隊列裏面放的都是想爭奪對象鎖的線程。
當一個線程1被另外一個線程2喚醒時,1線程進入同步隊列,去爭奪對象鎖。
同步隊列是在同步的環境下才有的概念,一個對象對應一個同步隊列。
線程等待時間到了或被notify/notifyAll喚醒後,會進入同步隊列競爭鎖,如果獲得鎖,進入RUNNABLE狀態,否則進入BLOCKED狀態等待獲取鎖。

 

幾個方法的比較


Thread.sleep(long millis):一定是當前線程調用此方法,當前線程進入TIMED_WAITING狀態,但不釋放對象鎖,millis後線程自動甦醒進入就緒狀態。作用:給其它線程執行機會的最佳方式。


Thread.yield():一定是當前線程調用此方法,當前線程放棄獲取的CPU時間片,但不釋放鎖資源,由運行狀態變爲就緒狀態,讓OS再次選擇線程。作用:讓相同優先級的線程輪流執行,但並不保證一定會輪流執行。實際中無法保證yield()達到讓步目的,因爲讓步的線程還有可能被線程調度程序再次選中。Thread.yield()不會導致阻塞。該方法與sleep()類似,只是不能由用戶指定暫停多長時間。
thread.join()/thread.join(long millis),當前線程裏調用其它線程t的join方法,當前線程進入WAITING/TIMED_WAITING狀態,當前線程不會釋放已經持有的對象鎖。線程t執行完畢或者millis時間到,當前線程一般情況下進入RUNNABLE狀態,也有可能進入BLOCKED狀態(因爲join是基於wait實現的)。


obj.wait():當前線程調用對象的wait()方法,當前線程釋放對象鎖,進入等待隊列。依靠notify()/notifyAll()喚醒或者wait(long timeout) timeout時間到自動喚醒。


obj.notify():喚醒在此對象監視器上等待的單個線程,選擇是任意性的。notifyAll()喚醒在此對象監視器上等待的所有線程。


LockSupport.park()/LockSupport.parkNanos(long nanos),LockSupport.parkUntil(long deadlines), 當前線程進入WAITING/TIMED_WAITING狀態。對比wait方法,不需要獲得鎖就可以讓線程進入WAITING/TIMED_WAITING狀態,需要通過LockSupport.unpark(Thread thread)喚醒。

 

 

 

 

參考文獻

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章