受多種狀況的影響,又開始看JVM 方面的知識。java
一、Java 實在過於內卷,無法不往深了學。面試
二、面試題問的多,被迫學習。安全
三、純粹的好奇。 很喜歡一句話:「八小時內謀生活,八小時外謀發展。」markdown
--- 望別日與君相見時,君已有所成。學習
共勉
測試
封面地點
:湖南--小城市邵陽spa
做者
:博主 🤸♂️code
@[TOC](雙親委派機制 詳解(手畫詳圖)面試高頻 你值得擁有!!!)orm
雙親委派機制是當類加載器須要加載某一個.class字節碼文件時,則首先會把這個任務委託給他的上級類加載器,遞歸這個操做,若是上級沒有加載該.class文件,本身才會去加載這個.class。這是一種任務委派模式。遞歸
用一個小故事來加深你們的印象:
一、你看到餐桌上有個雞腿,看到麻麻很是幸苦。你就說:麻麻你次這個雞腿吧。麻麻又看到桌上的奶奶,就講媽:次這個雞腿補補身子吧。奶奶高興的說:我媳婦孝順啊,我今天也來嚐嚐這個孝順味道的雞腿啦。
二、你看到餐桌上有個雞腿,看到麻麻很是幸苦。你就說:麻麻你次這個雞腿吧。麻麻又看到桌上奶奶在,就講媽:次這個雞腿補補身子把。奶奶高興的說:我媳婦有這個孝順心就行了,你天天上班次外賣,對身體很差,這個雞腿給你次。麻麻拿到手上,又反手把雞腿夾給我,講:這個雞腿仍是得你次,你如今正在長身體,不補一補長不高。⛹️♂️
==這就是雙親委派機制,不知道看完這個餐桌小故事,你們有沒有懂勒。==
我在我本身的項目中建立了 一個java.lang
的包 ,而後建立了一個 String 類。
再準備一個測試類,引用這個String類。
String 類 裏面就一個靜態代碼塊。
代碼能夠運行,輸出以下:
並無輸出個人String 裏面的static 靜態代碼塊,證實使用的仍然是 jdk 自帶的。
緣由是什麼呢?
一步一步分析。
咱們自定義一個類,你要想加載的話,應該是用 Application ClassLoader(系統類加載器、應用程序加載器)進行加載。可是這個時候又牽扯到了 雙親委派機制。
一、當咱們要加載這個自定義String時,
二、先是讓應用程序加載器(Application ClassLoader)加載,可是發現它上面還有擴展類加載器(Extension ClassLoader)
三、接着委託給擴展類加載器(Extension ClassLoader),忽然發現它上面還有Bootstrap ClassLoader (啓動類加載器)
四、就又接着委託到了Bootstrap ClassLoader (啓動類加載器)。啓動加載器一看,這不是 java.lang 包下的嗎,這是個人任務啊,急忙把他加載啦,而後成功返回。因此這裏使用的 new String() 實際使用的仍是 java 中 String。
這樣子能夠防止什麼樣問題的發生呢?
你想啊,你寫了一個項目,裏面用了Jdk 核心類,像String.java,Integer.java,Date.java這種核心類,若是這種核心類可以被隨意更改,第1、這頗有可能致使整個項目的崩潰,第2、會影響到Java 虛擬機的穩定性。
確保Java核心類庫的安全
:全部的Java應用都至少會引用java.lang.Object類,也就是說在運行期,java.lang.Object類會被記載到Java虛擬機當中;若是這個加載過程是由Java應用本身的類加載器所完成的,那麼可能會在JVM中存在多個版本的java.lang.Object類,並且這些類仍是不兼容的、相互不可見的(由於命名空間的緣由)。藉助父親委託機制,Java核心類庫中的類的加載工做都是由啓動類加載器來統一完成的,從而確保了Java應用所使用的都是同一個版本的Java核心類庫,他們之間是互相兼容的。確保Java核心類庫提供的類不會被自定義的類所替代
。不一樣的類加載器能夠爲相同名稱(binary name)的類建立額外的命名空間
。相同名稱的類能夠並存在Java虛擬機中,只須要用不一樣的類加載器來加他們便可,不一樣類加載器所加載的類是不兼容的,這就至關於在Java虛擬機內部建立了一個又一個相互隔離的Java類空間。.class
。經過委託去向上面問一問,加載過了,就不用再加載一遍。保證數據安全。划水的一篇哈,咱們都加油,放肆愛!!!
讓咱們一塊兒走到最後吧
共勉