阿里架構師帶你深入淺出jvm
本文跟大家聊聊JVM的內部結構,從元件中的多執行緒處理,JVM系統執行緒,區域性變數陣列等方面進行解析
JVM
JVM = 類載入器(classloader) + 執行引擎(execution engine) + 執行時資料區域(runtime data area)
下面這幅圖展示了一個典型的JVM(符合JVM Specification Java SE 7 Edition)所具備的關鍵內部元件。
元件中的多執行緒處理
多執行緒處理”或“自由執行緒處理”指的是一個程式同時執行多個操作執行緒的能力。
作為多執行緒應用程式的一個示例,某個程式在一個執行緒上接收使用者輸入,在另一個執行緒上執行多種複雜的計算,並在第三個執行緒上更新資料庫。
在單執行緒應用程式中,使用者可能會花費時間等待計算或資料庫更新完成。 而在多執行緒應用程式中,這些程式可以在後臺進行,因此不會浪費使用者時間。
多執行緒處理可以是元件程式設計中的一個非常強大的工具。通過編寫多執行緒元件,您可以建立在後臺執行復雜計算的元件,它們允許使用者介面 (UI)
在計算的過程中自由地響應使用者輸入。 雖然多執行緒處理是一個強大的工具,但是要將其正確應用卻比較困難。
未能正確實現的多執行緒程式碼可能降低應用程式效能,或甚至導致應用程式凍結。 下列主題將向您介紹多執行緒程式設計的一些注意事項和最佳做法。.NET
Framework 提供幾個在元件中進行多執行緒處理的選項。 System.Threading 名稱空間中的功能是一個選項。
基於事件的非同步模式是另一個選項。 BackgroundWorker 元件是對非同步模式的實現;它提供封裝在元件中以便於使用的高階功能。
JVM系統執行緒
如果你用jconsole或者任何其他的debug工具檢視,可能會看到有許多執行緒在後臺執行。這些執行著的後臺執行緒不包含主執行緒,主執行緒是基於執行publicstatic
void main(String[])
的需要而被建立的。而這些後臺執行緒都是被主執行緒所建立。在HotspotJVM中主要的後臺系統執行緒,見下表:
VM 執行緒該執行緒用於等待執行一系列能夠使得JVM到達一個“safe-point”的操作。
而這些操作不得不發生在一個獨立的執行緒上的原因是:它們都要求JVM處於一個——無法修改堆的safepoint。
被這個執行緒執行的該類操作都是“stop-the-world”型的垃圾回收、執行緒棧回收、執行緒擱置以及有偏差的鎖定撤銷。
週期性的任務執行緒該執行緒用於響應timer事件(例如,中斷),這些事件用於排程執行週期性的操作
GC 執行緒這些執行緒支援在JVM中不同型別的垃圾回收
編譯器執行緒它們用於在執行時將位元組碼編譯為本地機器碼
訊號分發執行緒該執行緒接收傳送給JVM的訊號,並通過呼叫JVM合適的方法進行處理
單個執行緒
每個執行緒的一次執行都包含如下的元件
程式計數器(PC)
除非當前指令或者操作碼是原生的,否則當前指令或操作碼的地址都需要依賴於PC來定址。如果當前方法是原生的,那麼該PC即為undefined。所有的CPU都有一個PC,通常PC在每個指令執行後被增加以指向即將執行的下一條指令的地址。JVM使用PC來跟蹤正在執行的指令的位置。事實上,PC被用來指向methodarea的一個記憶體地址。
原生棧
不是所有的JVM都支援原生方法,但那些支援該特性的JVM通常會對每個執行緒建立一個原生方法棧。如果對JVM的JNI(JavaNative
Invocation)採用c連結模型的實現,那麼原生棧也將是一個C實現的棧。在這個例子中,原生棧中引數的順序
、返回值都將跟通常的C程式相同。一個原生方法通常會對JVM產生一個回撥(這依賴於JVM的實現)並執行一個Java方法。這樣一個原生到Java的呼叫發生在棧上(通常在Java棧),與此同時執行緒也將離開原生棧,通常在Java棧上建立一個新的frame。
棧
每個執行緒都有屬於它自己的棧,用於儲存線上程上執行的每個方法的frame。棧是一個後進先出的資料結構,這可以使得當前正在執行的方法位於棧的頂部。對於每個方法的執行,都會有一個新的frame被建立並被入棧到棧的頂部。當方法正常的返回或在方法執行的過程中遇到未捕獲的異常時frame會被出棧。棧不會被直接進行操作,除了push/
pop frame
物件。因此可以看出,frame物件可能會被分配在堆上,並且記憶體也沒必要是連續的地址空間(請注意區分frame的指標跟frame物件)。
棧的限制
一個棧可以是動態的或者是有合適大小的。如果一個執行緒要求更大的棧,那麼將丟擲StackOverflowError異常;如果一個執行緒要求新建立一個frame,又沒有足夠的記憶體空間來分配,將會丟擲OutOfMemoryError異常。
Frame
對於每一個方法的執行,一個新frame會被建立並被入棧到棧頂。當方法正常返回或在方法執行的過程中遇到未捕獲的異常,frame會被出棧。
區域性變數陣列
區域性變數陣列包含了在方法執行期間所用到的所有的變數。包含一個對this的引用,所有的方法引數,以及其他區域性定義的變數。對於類方法(比如靜態方法),方法引數的儲存索引從0開始;而對於例項方法,索引為0的槽都為儲存this指標而保留。
運算元棧
運算元棧在位元組碼指令被執行的過程中使用。它跟原生CPU使用的通用目的的暫存器類似。大部分的位元組碼都把時間花費在跟運算元棧打交道上,通過入棧、出棧、複製、交換或者執行那些生產/消費值的操作。對位元組碼而言,那些在區域性變數陣列和運算元棧之間移動值的指令是非常頻繁的。
動態連結
每個frame都包含一個對執行時常量池的引用。該引用指向將要被執行的方法所屬的類的常量池。該引用也用於輔助動態連結。
當一個Java類被編譯時,所有對儲存在類的常量池中的變數以及方法的引用都被當做符號引用。一個符號引用僅僅只是一個邏輯引用而不是最終指向實體記憶體地址的引用。JVM的實現可以選擇解析符號引用的時機,該時機可以發生在當類檔案被驗證後、被載入後,這稱之eager或靜態分析;不同的是它也可以發生在當符號引用被首次使用的時候,稱之為lazy或延遲分析。但JVM必須保證:解析發生在每個引用被首次使用前,同時在該時間點,如果遇到分析錯誤能夠丟擲異常。繫結是一個處理過程,它將被符號引用標識的欄位、方法或類替換為一個直接引用。這個處理過程只發生一次,因為符號引用需要被完全替換。如果一個符號引用關聯著一個類,而該類還沒有被解析,那麼該類也會被立即載入。每個直接引用都被以偏移的方式儲存,該儲存結構關聯著變數或方法的執行時位置。
執行緒之間共享
堆
堆中某個節點的值總是不大於或不小於其父節點的值;
堆總是一棵完全二叉樹。
將根節點最大的堆叫做最大堆或大根堆,根節點最小的堆叫做最小堆或小根堆。常見的堆有二叉堆、斐波那契堆等。
堆的定義如下:n個元素的序列{k1,k2,ki,…,kn}當且僅當滿足下關係時,稱之為堆。
(ki <= k2i,ki <= k2i+1)或者(ki >= k2i,ki >= k2i+1), (i = 1,2,3,4...n/2)
若將和此次序列對應的一維陣列(即以一維陣列作此序列的儲存結構)看成是一個完全二叉樹,則堆的含義表明,完全二叉樹中所有非終端結點的值均不大於(或不小於)其左、右孩子結點的值。由此,若序列{k1,k2,…,kn}是堆,則堆頂元素(或完全二叉樹的根)必為序列中n個元素的最小值(或最大值)
非堆式記憶體
有些物件並不會建立在堆中,這些物件在邏輯上被認為是JVM機制的一部分。
非堆式的記憶體包括:
永久代中包含:
方法區
內部字串
程式碼快取:用於編譯以及儲存方法,這些方法已經被JIT編譯成原生程式碼
記憶體管理
物件和陣列永遠都不會被顯式釋放,因此只能依靠垃圾回收器來自動地回收它們。
通常,以如下的步驟進行:
新物件和陣列被建立在年輕代
次垃圾回收器將在年輕代上執行。那些仍然存活著的物件,將被從eden區移動到survivor區
主垃圾回收器將會把物件在代與代之間進行移動,主垃圾回收器通常會導致應用程式的執行緒暫停。那些仍然存活著的物件將被從年輕代移動到老年代
永久代會在每次老年代被回收的時候同時進行,它們在兩者中其一滿了之後都會被回收
JIT編譯
JIT具體的做法是這樣的:當載入一個型別時,CLR為該型別建立一個內部資料結構和相應的函式,當函式第一被呼叫時,JIT將該函式編譯成機器語言.當再次遇到該函式時則直接從cache中執行已編譯好的機器語言.
方法區
所有的執行緒共享相同的方法區。所以,對於方法區資料的訪問以及對動態連結的處理必須是執行緒安全的。如果兩個執行緒企圖訪問一個還沒有被載入的類(該類必須只能被載入一次)的欄位或者方法,直到該類被載入完成,這兩個執行緒才能繼續執行。
類的檔案結構
一個被編譯過的類檔案包含如下的結構:
ClassFile
{ u4magic; u2minor_version; u2major_version; u2constant_pool_count;
cp_infocontant_pool[constant_pool_count – 1]; u2access_flags;
u2this_class; u2super_class; u2interfaces_count;
u2interfaces[interfaces_count]; u2fields_count;
field_infofields[fields_count]; u2methods_count;
method_infomethods[methods_count]; u2attributes_count;
attribute_infoattributes[attributes_count];}
magic,
minor_version,
major_version
指定一些資訊:
當前類的版本、編譯當前類的JDK版本
constant_pool跟符號表相似,但它包含更多的資料
access_flags為該類提供一組修改器
this_class為該類提供完全限定名在常量池中的索引,例如:org/jamesdbloom/foo/Bar
super_class提供對其父類的符號引用在常量池中的索引,例如:java/lang/Object
interface常量池中的陣列索引,該陣列提供對所有被實現的介面的符號引用
fields常量池中的陣列索引,該陣列提供對每個欄位的完整描述
methods常量池中的陣列索引,該陣列提供對每個方法簽名的完整描述,如果該方法不是抽象的或者native的,
那麼也會包含位元組碼
attributes不同值的陣列,提供關於類的額外資訊,包括註解:RetentionPolicy.CLASS以及RetentionPolicy.RUNTIME
可以使用javap命令檢視被編譯後的java類的位元組碼。
下面列出了在該類檔案中,使用到的操作碼:
aload_0該操作碼是形如aload_格式的一組操作碼中其中的一個。
它們都是用來載入一個物件引用到運算元棧。
而“”用於指示要被訪問的物件引用在區域性變數陣列中的位置,但n的值只能是0,1,2或3。
也有其他相似的操作碼用來載入非物件引用,如:iload_,lload_,fload_以及dload_
(其中,i表示int,l表示long,f表示float,而d表示double,上面n的取值範圍對這些*load_同樣適用)。
區域性變數的索引如果大於3,可以使用iload,lload,float,dload和aload載入。
這些操作碼都攜帶要被載入的區域性變數在陣列中的索引。
ldc該操作碼用來從執行時常量池取出一個常量壓入運算元棧
getstatic該操作碼用來從執行時常量池的靜態欄位列表入棧一個靜態值到運算元棧
invokespecial
invokevirtual
這些操作碼是一組用來執行方法的操作碼
(總共有:invokedynamic、invokeinterface、invokespecial、invokestatic、invokevirtual這幾種)。
其中,本例中出現的invokevirtual用來執行類的例項方法;
而invokespecial用於執行例項的初始化方法,同時也用於執行私有方法以及屬於超類但被當前類繼承的方法
(超類方法動態繫結到子類)。
return該操作碼是一組操作碼(ireturn,lreturn,freturn,dreturn,areturn以及return)中的其中一個。
每個操作碼,都是型別相關的返回語句。
其中i代表int,l表示long,f表示float,d表示double而a表示一個物件的引用。
沒有識別符號作為首字母的return語句,僅會返回void
就像在其他通用的位元組碼中那樣,以上這些操作碼主要用於跟本地變數、運算元棧以及執行時常量池打交道。
構造器有兩個指令,第一個將“this”壓入到運算元棧,接下來該構造器的父構造器被執行,這一操作將導致this被“消費”,因此this將從運算元棧出棧。
而對於sayHello()方法,它的執行將更為複雜。因為它不得不通過執行時常量池,解析符號引用到真實的引用。第一個運算元getstatic,用來入棧一個指向System類的靜態欄位out的引用到運算元棧。接下來的運算元ldc,入棧一個字串字面量“Hello”到運算元棧。最後,invokevirtual運算元,執行System.out的println方法,這將使得“Hello”作為一個引數從運算元棧出棧,併為當前執行緒建立一個新的frame。
類載入器
JVM的啟動是通過bootstrap類載入器來載入一個用於初始化的類。在publicstatic void main(String[])被執行前,該類會被連結以及例項化。main方法的執行,將順序經歷載入,連結,以及對額外必要的類跟介面的初始化。
載入:
載入是這樣一個過程:查詢表示該類或介面型別的類檔案,並把它讀到一個位元組陣列中。接著,這些位元組會被解析以確認它們是否表示一個Class物件以及是否有正確的主、次版本號。任何被當做直接superclass的類或介面也一同被載入。一旦這些工作完成,一個類或介面物件將會從二進位制表示中建立。
連結: 連結包含了對該類或介面的驗證,準備型別以及該類的直接父類跟父介面。簡而言之,連結包含三個步驟:驗證、準備以及解析(optional)
驗證:該階段會確認類以及介面的表示形式在結構上的正確性,同時滿足Java程式語言以及JVM語義上的要求。
在驗證階段執行這些檢查意味著在執行時可以免去在連結階段進行這些動作,雖然拖慢了類的載入速度,然而它避免了在執行位元組碼的時候執行這些檢查。
準備:包含了對靜態儲存的記憶體分配以及JVM所使用的任何資料結構(比如方法表)。靜態欄位都被建立以及例項化為它們的預設值。然而,沒有任何例項化器或程式碼在這個階段被執行,因為這些任務將會發生在例項化階段。
解析:是一個可選的階段。該階段通過載入引用的類或介面來檢查符號引用是否正確。如果在這個點這些檢查沒發生,那麼對符號引用的解析會被推遲到直到它們被位元組碼指令使用之前。
例項化 類或介面,包含執行類或介面的例項化方法:
在JVM中存在多個不同職責的類載入器。每一個類載入器都代理其已被載入的父載入器(除了bootstrap類載入器,因為它是根載入器)。
Bootstrap類載入器:當java程式執行時,java虛擬機器需要裝載java類,這個過程需要一個類裝載器來完成。而類裝載器本身也是一個java類,這就出現了類似人類的第一位母親是如何產生出來的問題。
其實,java虛擬機器中內嵌了一個稱為Bootstrap的類裝載器,它是用特定於作業系統的原生程式碼實現的,屬於java虛擬機器的核心,這個Bootstrap類裝載器不用專門的類裝載器去裝載。Bootstrap類裝載器負責載入java核心包中的類。
Extension 類載入器:從標準的Java擴充套件API中載入類。例如,安全的擴充套件功能集。
System 類載入器:這是應用程式預設的類載入器。它從classpath中載入應用程式類。
使用者定義的類載入器:可以額外得定義類載入器來載入應用程式類。使用者定義的類載入器可用於一些特殊的場景,比如:在執行時重新載入類或將一些特殊的類隔離為多個不同的分組(通常web伺服器中都會有這樣的需求,比如Tomcat)。
更快的類載入
一個稱之為類資料共享(CDS)的特性自HotspotJVM
5.0開始被引進。在安裝JVM期間,安裝器載入一系列的Java核心類(如rt.jar)到一個經過對映過的記憶體區進行共享存檔。CDS減少了載入這些類的時間從而提升了JVM的啟動速度,同時允許這些類在不同的JVM例項之間共享。這大大減少了記憶體碎片。
方法區的位置
JVM
Specification Java SE 7
Edition清楚地宣告:儘管方法區是堆的一個邏輯組成部分,但最簡單的實現可能是既不對它進行垃圾回收也不壓縮它。然而矛盾的是利用jconsole檢視Oracle的JVM的方法區(以及CodeCache)是非堆形式的。OpenJDK程式碼顯示CodeCache相對ObjectHeap而言是VM中一個獨立的域。
類載入器引用
類通常是按需載入,即第一次使用該類時才載入。由於有了類載入器,Java執行時系統不需要知道檔案與檔案系統。
執行時常量池
JVM對每個型別維護著一個常量池,它是一個跟符號表相似的執行時資料結構,但它包含了更多的資料。Java的位元組碼需要一些資料,通常這些資料會因為太大而難以直接儲存在位元組碼中。取而代之的一種做法是將其儲存在常量池中,位元組碼包含一個對常量池的引用。執行時常量池主要用來進行動態連結。
幾種型別的資料會儲存在常量池中,它們是:
數值字面量
字串字面量
類的引用
欄位的引用
方法的引用
如果你編譯下面的這個簡單的類:
package org.jvminternals;public class SimpleClass { public void sayHello() {System.out.println("Hello");}}
生成的類檔案的常量池,看起來會像下圖所示:
Constant
pool: #1 = Methodref #6.#17 // java/lang/Object."":()V#2 =
Fieldref #18.#19 // java/lang/System.out:Ljava/io/PrintStream;#3 =
String #20 // "Hello"#4 = Methodref #21.#22 //
java/io/PrintStream.println:(Ljava/lang/String;)V#5 = Class #23 //
org/jvminternals/SimpleClass#6 = Class #24 // java/lang/Object#7 = Utf8
#8 = Utf8 ()V #9 = Utf8 Code #10 = Utf8 LineNumberTable #11
= Utf8 LocalVariableTable #12 = Utf8 this #13 = Utf8
Lorg/jvminternals/SimpleClass; #14 = Utf8 sayHello #15 = Utf8 SourceFile
#16 = Utf8 SimpleClass.java #17 = NameAndType #7:#8 //
"":()V#18 = Class #25 // java/lang/System#19 = NameAndType
#26:#27 // out:Ljava/io/PrintStream;#20 = Utf8 Hello #21 = Class #28 //
java/io/PrintStream#22 = NameAndType #29:#30 //
println:(Ljava/lang/String;)V#23 = Utf8 org/jvminternals/SimpleClass #24
= Utf8 java/lang/Object#25 = Utf8 java/lang/System #26 = Utf8 out#27 =
Utf8 Ljava/io/PrintStream; #28 = Utf8 java/io/PrintStream #29 = Utf8
println #30 = Utf8 (Ljava/lang/String;)V
常量池中包含了下面的這些型別:
Integer一個4位元組的int常量
Long一個8位元組的long常量
Float一個4位元組的float常量
Double一個8位元組的double常量
String一個String字面值常量指向常量池中另一個包含最終位元組的UTF8記錄
Utf8一個位元組流表示一個Utf8編碼的字串序列
Class一個Class字面值常量指向常量池中的另一個Utf8記錄,它包含JVM內部格式的完全限定名
(它用於動態連結)
NameAndType用一個冒號區分一對值,每個值都指向常量池中得其他記錄。
冒號前的第一個值指向一個utf8字串字面量表示方法名或者欄位名。
第二個值指向一個utf8字串字面量表示型別。
舉一個欄位的例子是完全限定的類名;
舉一個方法的例子是: 它是一個列表,該列表中每個引數都是完全限定的類名
Fieldref,
Methodref,
InterfaceMethodref
用點來分隔的一對值,每個值指向常量池中的另一個記錄。
點前的第一個值指向一個Class記錄。第二個值指向一個NameAndType記錄
異常表
異常表儲存了每個異常處理器的資訊:
起始點
終止點
處理程式碼的PC偏移量
被捕獲的異常類的常量池索引
如果一個方法定義了try-catch或try-finally異常處理器,那麼一個異常表將會被建立。它包含了每個異常處理器的資訊或者finally塊以及正在被處理的異常型別跟處理器程式碼的位置。
當一個異常被丟擲,JVM會為當前方法尋找一個匹配的處理器。如果沒有找到,那麼該方法最終會唐突地出棧當前stackframe而異常會被重新丟擲到呼叫鏈(新的frame)。如果在所有的frame都出棧之前還是沒有找到異常處理器,那麼當前執行緒將會被終止。當然這也可能會導致JVM被終止,如果異常被丟擲到最後一個非後臺執行緒的話,比如該執行緒就是主執行緒。
最終異常處理器會匹配所有的異常型別並且無論什麼時候該型別的異常被丟擲總是會得到執行。在沒有異常丟擲的例子中,finally塊仍然會在方法的最後被執行。一旦return語句被執行就會立即跳轉到finally程式碼塊繼續執行。
字元比較
字元比較(character comparison)是指按照字典次序對單個字元或字串進行比較大小的操作,一般都是以ASCII碼值的大小作為字元比較的標準。
符號表
符號表在編譯程式工作的過程中需要不斷收集、記錄和使用源程式中一些語法符號的型別和特徵等相關資訊。這些資訊一般以表格形式儲存於系統中。如常數表、變數名錶、陣列名錶、過程名錶、標號表等等,統稱為符號表。對於符號表組織、構造和管理方法的好壞會直接影響編譯系統的執行效率。
在JVM中,內部字串被儲存在字串表中。字串表是一個hashtable對映物件指標到符號(比如:Hashtable),它被儲存在永久代裡。
當類被載入時,字串字面量會被編譯器自動“內部化”並且被加入到字元表。另外字串類的例項可以通過呼叫String.intern()來明確地內部化。當String.intern()被呼叫,如果符號表裡已經包含該字串,那麼指向該字串的引用將被返回。如果該字串沒有包含在字元表,則會被加入到字串表同時返回其引用。
在此我向大家推薦一個架構學習交流群。交流學習群號:744642380,裡面會分享一些資深架構師錄製的視訊錄影:有Spring,MyBatis,Netty原始碼分析,高併發、高效能、分散式、微服務架構的原理,JVM效能優化、分散式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源,目前受益良
相關文章
- 對JVM還有什麼不懂的?資深架構師一篇文章帶你深入淺出JVM!JVM架構
- 深入淺出!阿里P7架構師帶你分析ArrayList集合原始碼,建議是先收藏再看!阿里架構原始碼
- Redis雲端架構深入淺出Redis架構
- “阿里架構師”的JVM之GC詳解阿里架構JVMGC
- 架構師帶你深入理解Java的介面和抽象類架構Java抽象
- 深入淺出Nginx實戰與架構Nginx架構
- 【深入淺出jQuery】原始碼淺析–整體架構jQuery原始碼架構
- 深入淺出之JVM GC篇JVMGC
- 阿里P8大佬帶你深入解析JVM與java阿里JVMJava
- 架構師帶你玩轉分散式鎖架構分散式
- 跑馬燈帶你深入淺出TextView的原始碼世界TextView原始碼
- 深入淺出微服務架構:一分鐘讓你輕鬆上手Docker容器微服務架構Docker
- 阿里P8級架構師淺談Java架構師的工作都幹些什麼?阿里架構Java
- 阿里P8級架構師淺析秒殺架構設計實踐思路阿里架構
- 阿里十年架構師用一張圖告訴你什麼是系統架構師阿里架構
- 帶你深入淺出理解深度學習(附資源打包下載)深度學習
- JVM深入淺出 -- Java記憶體分配機制JVMJava記憶體
- 深入淺出JVM(十)之位元組碼指令(下篇)JVM
- 看阿里P9架構師如何向你定義架構及架構師阿里架構
- 阿里大資料架構師必備技能,你“佩奇”了嘛?阿里大資料架構
- jvm架構JVM架構
- 2017年------阿里大神帶你詳解Dubbo架構設計阿里架構
- 【深入淺出 Yarn 架構與實現】4-3 RM 管理 NodeManagerYarn架構
- 【深入淺出 Yarn 架構與實現】4-1 ResourceManager 功能概述Yarn架構
- 深入淺出FE(十四)深入淺出websocketWeb
- 【深入淺出ES6】解構
- 深入淺出JVM(十一)之如何判斷物件“已死”JVM物件
- 深入淺出的webpack構建工具--webpack4+vue+router專案架構(十四)WebVue架構
- 阿里架構師帶你玩轉git,設定git倉庫可見性,讓git隻手把控阿里架構Git
- 阿里P7架構師告訴你Java架構師必須知道的 6 大設計原則阿里架構Java
- 深入淺出etcd系列Part 1 – etcd架構和程式碼框架架構框架
- 【深入淺出 Yarn 架構與實現】4-4 RM 管理 ApplicationYarn架構APP
- 淺談JVM整體架構與調優引數JVM架構
- 深入淺出解析JVM中的Safepoint | 得物技術JVM
- 阿里雲架構師解讀三大主流遊戲架構阿里架構遊戲
- 阿里大師帶你詳解API介面安全阿里API
- 【深入淺出 Yarn 架構與實現】4-2 RM 管理 Application MasterYarn架構APPAST
- 【深入淺出 Yarn 架構與實現】6-2 NodeManager 狀態機管理Yarn架構