Java體系結(jié)構(gòu)采用了一個(gè)擴(kuò)展的內(nèi)置安全模型

Java的安全模型是其多個(gè)重要結(jié)構(gòu)特點(diǎn)之一，它使Java成為適用于網(wǎng)絡(luò)環(huán)境的技術(shù)。

Java安全模型側(cè)重于保護(hù)終端用戶免受從網(wǎng)絡(luò)下載的、來(lái)自不可靠來(lái)源的、惡意程序(以及善意程序中的bug)的侵犯。

為了達(dá)到這個(gè)目的，Java提供了一個(gè)用戶可配置的“沙箱”，在沙箱中可以放置不可靠的Java程序。

沙箱對(duì)不可靠程序的活動(dòng)進(jìn)行了限制，程序可以在沙箱的安全邊界內(nèi)做任何事，但是不能進(jìn)行任何跨越這些邊界的舉動(dòng)。例如：

1.對(duì)本地硬盤(pán)的讀寫(xiě)操作

2.進(jìn)行任何網(wǎng)絡(luò)連接，但不能連接到提供這個(gè)applet的源主機(jī)，

3.創(chuàng)建新的進(jìn)程

4.裝載新的動(dòng)態(tài)連接庫(kù)

簽名和認(rèn)證使得接收端系統(tǒng)可以確認(rèn)一系列class文件(在一個(gè)JAR文件中)已經(jīng)由某一實(shí)體進(jìn)行了數(shù)字簽名(有效，可被信賴)，并且在簽名過(guò)后，這些class文件沒(méi)有改動(dòng)。

雖然版本1.1中發(fā)布的安全API包含了對(duì)認(rèn)證的支持，但實(shí)際上，除了提供完全信任和完全不信任策略以外，沒(méi)有提供許多實(shí)際的幫助。

版本1.2提供的API可以幫助建立細(xì)粒度的安全策略，這種策略是在數(shù)字簽名代碼的認(rèn)證基礎(chǔ)上的。

基本沙箱 沙箱模式使你可以接收來(lái)自任何來(lái)源的代碼，而不是要求用戶避免將來(lái)自不信任站點(diǎn)的代碼下載到機(jī)器上。 但是當(dāng)來(lái)自不可靠來(lái)源的代碼運(yùn)行時(shí)，沙箱會(huì)限制它進(jìn)行可能破壞系統(tǒng)的任何動(dòng)作。 不必指出哪些代碼可以信任，哪些代碼不可以信任，也不必掃描查找病毒，沙箱本身限制了下載的任何病毒或其他惡意的、有漏洞的代碼，使得他它們不能對(duì)計(jì)算機(jī)進(jìn)行破壞
組成Java沙箱的基本組件如下： 類(lèi)裝載器結(jié)構(gòu) class文件檢驗(yàn)器 內(nèi)置于Java虛擬機(jī)(及語(yǔ)言)的安全特性 安全管理器及Java API
Java的沙箱安全模型中的類(lèi)裝載器和安全管理器是可以由用戶定制的。
類(lèi)裝載器體系結(jié)構(gòu) 在Java沙箱中，類(lèi)裝載器體系結(jié)構(gòu)是第一道防線。 1.它防止惡意代碼去干涉善意的代碼 2.它守護(hù)了被信任的類(lèi)庫(kù)的邊界 3.它將代碼歸入某類(lèi)(成為保護(hù)域)，該類(lèi)確定了代碼可以進(jìn)行哪些操作
防止惡意代碼去干涉善意的代碼，通過(guò)為不同的類(lèi)裝載器裝入的類(lèi)提供不同的命名空間來(lái)實(shí)現(xiàn)的。
命名空間由一系列唯一的名稱(chēng)組成，每一個(gè)被裝載的類(lèi)有一個(gè)名字，這個(gè)命名空間是由Java虛擬機(jī)為每一個(gè)類(lèi)裝載器維護(hù)的。
命名空間有助于安全的實(shí)現(xiàn)，有效地在裝入了不同命名空間的類(lèi)之間設(shè)置一個(gè)防護(hù)罩。 在Java虛擬機(jī)中，在同一個(gè)命名空間內(nèi)的類(lèi)可以直接進(jìn)行交互，而不同的命名空間中的類(lèi)甚至不能覺(jué)察到彼此的存在，除非顯示的提供了允許它們進(jìn)行交互的機(jī)制。

類(lèi)裝載器體系結(jié)構(gòu)守護(hù)了被信任的類(lèi)庫(kù)的邊界，這是通過(guò)分別使用不同的類(lèi)裝載器裝載可靠的包和不可靠的包來(lái)實(shí)現(xiàn)的。

雖然通過(guò)賦給成員受保護(hù)(或包訪問(wèn))的訪問(wèn)限制，可以在同一個(gè)包中的類(lèi)型間授予彼此訪問(wèn)的特殊權(quán)限，但這種特殊的權(quán)限只能授給在同一個(gè)包中的運(yùn)行時(shí)成員，而且它們必須是由同一個(gè)裝載器裝載的。

用戶自定義類(lèi)裝載器經(jīng)常依賴其他類(lèi)裝載器--至少依賴于虛擬機(jī)啟動(dòng)時(shí)創(chuàng)建的啟動(dòng)類(lèi)裝載器-來(lái)幫助它實(shí)現(xiàn)一些類(lèi)裝載請(qǐng)求。

在版本1.2以前，非啟動(dòng)類(lèi)裝載器必須顯示地求助于其他類(lèi)裝載器，類(lèi)裝載器可以請(qǐng)求另一個(gè)用戶自定義的類(lèi)裝載器來(lái)裝載一個(gè)類(lèi)，這個(gè)請(qǐng)求是通過(guò)對(duì)被請(qǐng)求的用戶自定義類(lèi)裝載器調(diào)用loadClass()來(lái)實(shí)現(xiàn)的，也可以通過(guò)調(diào)用findSystemClass()來(lái)請(qǐng)求啟動(dòng)類(lèi)裝載器來(lái)裝載類(lèi)，這是類(lèi)ClassLoader中的一個(gè)靜態(tài)方法。

在版本1.2中，類(lèi)裝載器請(qǐng)求另一個(gè)類(lèi)裝載器來(lái)裝載類(lèi)型的過(guò)程被形式化，稱(chēng)為雙親委派模式。

從版本1.2開(kāi)始，除啟動(dòng)類(lèi)裝載器以外的每一個(gè)類(lèi)裝載器，都有一個(gè)“雙親”類(lèi)裝載器，在某個(gè)特定的類(lèi)裝載器試圖以常用方式裝載類(lèi)型以前，它會(huì)先默認(rèn)地將這個(gè)任務(wù)“委派”給它的雙親--請(qǐng)求它的雙親來(lái)裝載這個(gè)類(lèi)型。這個(gè)雙親再依次請(qǐng)求它自己的雙親來(lái)裝載這個(gè)類(lèi)型。這個(gè)委派的過(guò)程一直向上繼續(xù)，直到達(dá)到啟動(dòng)類(lèi)裝載器，通常啟動(dòng)類(lèi)裝載器是委派鏈中的最后一個(gè)類(lèi)裝載器。如果一個(gè)類(lèi)裝載器的雙親類(lèi)裝載器有能力來(lái)裝載這個(gè)類(lèi)型，則這個(gè)類(lèi)裝載器返回這個(gè)類(lèi)型。否則，這個(gè)類(lèi)裝載器試圖自己來(lái)裝載這個(gè)類(lèi)型。

在版本1.2以前的大多數(shù)虛擬機(jī)的實(shí)現(xiàn)中，內(nèi)置的類(lèi)裝載器(原始類(lèi)裝載器)負(fù)責(zé)在本地裝載可用的class文件。

這些class文件通常包括哪些要運(yùn)行的Java應(yīng)用程序的class文件，以及這個(gè)應(yīng)用程序所需要的任何類(lèi)庫(kù)，這些類(lèi)庫(kù)中包含Java API的基本class文件。

許多實(shí)現(xiàn)都是按照類(lèi)路徑(class path)指明的順序查找目錄和JAR文件

在版本1.2中，裝載本地可用的class文件的工作被分配到多個(gè)類(lèi)裝載器中，原始類(lèi)裝載器的內(nèi)置的類(lèi)型裝載器被重新命名為啟動(dòng)類(lèi)裝載器，表示它現(xiàn)在只負(fù)責(zé)裝載那些核心Java API的class文件，核心Java API的class文件是用于“啟動(dòng)”Java虛擬機(jī)的class文件。

在版本1.2中，由用戶自定義類(lèi)裝載器來(lái)負(fù)責(zé)其他class文件的裝載，例如用于應(yīng)用程序運(yùn)行的class文件，用于安裝或下載標(biāo)準(zhǔn)擴(kuò)展的class文件，在類(lèi)路徑中發(fā)現(xiàn)的類(lèi)庫(kù)的class文件等。當(dāng)1.2版本的Java虛擬機(jī)開(kāi)始運(yùn)行時(shí)，在應(yīng)用程序啟動(dòng)以前，它至少會(huì)創(chuàng)建一個(gè)用戶自定義類(lèi)裝載器，也可能創(chuàng)建多個(gè)。

所以這些類(lèi)裝載器被連接在一個(gè)雙親-孩子的關(guān)系鏈中，關(guān)系鏈的頂端是啟動(dòng)類(lèi)裝載器，關(guān)系鏈的末端是“系統(tǒng)類(lèi)裝載器”，有時(shí)也被成為原始類(lèi)裝載器。

系統(tǒng)類(lèi)裝載器，指由Java應(yīng)用程序創(chuàng)建的、新的用戶定義類(lèi)裝載器的默認(rèn)委派雙親，它裝載應(yīng)用程序的初始類(lèi)。

Java虛擬機(jī)只把彼此訪問(wèn)的特殊權(quán)限授予由同一個(gè)類(lèi)裝載器裝載到同一個(gè)包中的類(lèi)型。

運(yùn)行時(shí)包，它指由同一個(gè)類(lèi)裝載器裝載的、屬于同一個(gè)包的、多個(gè)類(lèi)型的集合。

啟動(dòng)類(lèi)裝載器裝載核心Java API的class文件，這些class文件是最可信任的。

已安裝擴(kuò)展的類(lèi)裝載器裝載來(lái)自于任何已安裝擴(kuò)展的class文件，這個(gè)也是可信的。

由類(lèi)路徑裝載器中發(fā)現(xiàn)的代碼不能訪問(wèn)已安裝擴(kuò)展或Java API中的包內(nèi)可見(jiàn)成員。

類(lèi)裝載器可以簡(jiǎn)單地拒絕裝載特定的禁止類(lèi)型就可以了。

類(lèi)裝載器必須將每一個(gè)被裝載的類(lèi)放置在一個(gè)保護(hù)域中，一個(gè)保護(hù)域定義了這個(gè)代碼在運(yùn)行時(shí)將得到怎樣的權(quán)限。

class文件檢測(cè)器

class文件實(shí)質(zhì)上是一個(gè)字節(jié)序列，class文件檢驗(yàn)器的實(shí)現(xiàn)的目標(biāo)之一就是程序的健壯性。

Java虛擬機(jī)的class文件校驗(yàn)器在字節(jié)碼執(zhí)行之前，必須完成大部分檢驗(yàn)工作。

它只在執(zhí)行前對(duì)字節(jié)碼進(jìn)行一次分析(并檢驗(yàn)它的完整性)，每一次遇到一個(gè)跳轉(zhuǎn)指令時(shí)都進(jìn)行檢驗(yàn)。

虛擬機(jī)將確認(rèn)所有的跳轉(zhuǎn)指令會(huì)達(dá)到另一條合法的指令，而且這條指令是在這個(gè)方法的字節(jié)流中的。

class文件檢驗(yàn)器要進(jìn)行四趟獨(dú)立的掃描來(lái)完成，

第一趟 是在類(lèi)被裝載時(shí)進(jìn)行的，檢查這個(gè)class文件的內(nèi)部結(jié)構(gòu)，以保證它可以被安全地編譯。

第二趟+第三趟是在連接過(guò)程中進(jìn)行的，確認(rèn)類(lèi)型數(shù)據(jù)遵從Java編程語(yǔ)言的語(yǔ)義，包括校驗(yàn)它所包含的所有字節(jié)碼的完整性。

第四趟 是在進(jìn)行動(dòng)態(tài)連接的過(guò)程中解析符號(hào)引用時(shí)進(jìn)行的，確認(rèn)被引用的類(lèi)、字段以及方法確實(shí)存在。

第一趟：class文件的結(jié)構(gòu)檢查

對(duì)每一段將被當(dāng)作類(lèi)型導(dǎo)入的字節(jié)序列，class文件檢驗(yàn)器都會(huì)確認(rèn)它是否符合Java class文件的基本結(jié)構(gòu)。

例如每個(gè)class文件必須以4個(gè)同樣的字節(jié)開(kāi)始：魔數(shù)0xCAFEBABE。這個(gè)魔數(shù)的用處是讓class文件分析器很容易分辨出某個(gè)文件有明顯問(wèn)題而加以拒絕。

校驗(yàn)器還必須確認(rèn)在class文件中聲明的主版本號(hào)和次版本號(hào)，這個(gè)版本號(hào)必須在這個(gè)Java虛擬機(jī)實(shí)現(xiàn)可以支持的范圍以內(nèi)。

class文件檢驗(yàn)器 必須檢驗(yàn)確認(rèn)這個(gè)class文件沒(méi)有被刪節(jié)，尾部也沒(méi)有附帶其他的字節(jié)。

class文件中包含的每一個(gè)組成部分都聲明了它的長(zhǎng)度和類(lèi)型，校驗(yàn)器可以使用組成部分的類(lèi)型和長(zhǎng)度來(lái)確定整個(gè)class文件的正確的總長(zhǎng)度，這樣來(lái)檢查一個(gè)裝入的文件 其長(zhǎng)度是否和它里面的內(nèi)容相一致。

第一趟掃描的主要目的就是保證這個(gè)字節(jié)序列正確地定義了一個(gè)新類(lèi)型，它必須遵從Java的class文件的固定格式，這樣才能被編譯成在方法區(qū)中的(基于實(shí)現(xiàn)的)內(nèi)部數(shù)據(jù)結(jié)構(gòu)。第二、第三、第四趟掃描 不是在符合class文件格式的二進(jìn)制數(shù)據(jù)上進(jìn)行的，而是在方法區(qū)中、由實(shí)現(xiàn)決定的數(shù)據(jù)結(jié)構(gòu)上進(jìn)行的。

第二趟：類(lèi)型數(shù)據(jù)的語(yǔ)義檢查

在第二趟掃描中，class文件校驗(yàn)器進(jìn)行的檢查 不需要查看字節(jié)碼，也不需要查看和裝載任何其他類(lèi)型。

在這趟掃描中，校驗(yàn)器查看每個(gè)組成部分，確認(rèn)它們是否是其所屬類(lèi)型的實(shí)例，它們的結(jié)構(gòu)是否正確。

例如，方法描述符(它的返回類(lèi)型，以及參數(shù)的類(lèi)型和個(gè)數(shù))在class文件中被存儲(chǔ)成一個(gè)字符串，這個(gè)字符串必須符合特定的上下文無(wú)關(guān)文法。

校驗(yàn)器對(duì)每個(gè)組成部分進(jìn)行檢查，為了確認(rèn)每個(gè)方法描述符都是符合特定語(yǔ)法的、格式正確的字符串。

class文件校驗(yàn)器檢查這個(gè)類(lèi)本身是否符合特定的條件，它們是由Java編程語(yǔ)言規(guī)定的。

例如，檢驗(yàn)器強(qiáng)制除object類(lèi)以外的所有類(lèi)，都必須有一個(gè)超類(lèi)。

校驗(yàn)器還要檢查final類(lèi)沒(méi)有被子類(lèi)化，而且final方法沒(méi)有被覆蓋。

還要檢查常量池中的條目是合法的，而且常量池的所有索引必須指向正確類(lèi)型的常量池條目。

class文件檢驗(yàn)器在運(yùn)行時(shí)檢查了一些Java語(yǔ)言應(yīng)該在編譯時(shí)遵守的強(qiáng)制規(guī)則。

第三趟：字節(jié)碼驗(yàn)證

在class文件校驗(yàn)器成功地進(jìn)行了兩趟檢查后，它將把注意力放在字節(jié)碼上，

Java虛擬機(jī)對(duì)字節(jié)流進(jìn)行數(shù)據(jù)流分析，這些字節(jié)流代表的是類(lèi)的方法。

字節(jié)碼流代表了Java的方法，它是由被稱(chēng)為操作碼的單字節(jié)指令組成的序列，每一個(gè)操作碼后跟著一個(gè)或多個(gè)操作數(shù)。

操作數(shù)用于在Java虛擬機(jī)執(zhí)行操作碼指令時(shí)提供所需的額外數(shù)據(jù)。

執(zhí)行字節(jié)碼時(shí)，依次執(zhí)行每個(gè)操作碼，這就在Java虛擬機(jī)內(nèi)構(gòu)成了執(zhí)行的線程。

每一個(gè)線程被授予自己的Java棧，這個(gè)棧是有不同的棧幀構(gòu)成的。每一個(gè)方法調(diào)用將獲得一個(gè)自己的棧幀--棧幀其實(shí)就是一個(gè)內(nèi)存片段，其中存儲(chǔ)著局部變量和計(jì)算的中間結(jié)果?

在棧幀中，用于存儲(chǔ)方法的中間結(jié)果的部分被稱(chēng)為該方法的操作數(shù)棧。操作碼和它得(可選的)操作數(shù)可能存儲(chǔ)在操作數(shù)棧中的數(shù)據(jù)，或存儲(chǔ)在方法棧幀中的局部變量中的數(shù)據(jù)。

這樣，在執(zhí)行一個(gè)操作碼時(shí)，除了可以使用緊隨其后的操作數(shù)，虛擬機(jī)還可以使用操作數(shù)棧中的數(shù)據(jù)，或局部變量中的數(shù)據(jù)或兩者都用。

字節(jié)碼檢驗(yàn)器要進(jìn)行大量的檢查，以確保采用任何路徑在字節(jié)碼流中都得到一個(gè)確定的操作碼，確保操作數(shù)?？偸前_的數(shù)值以及正確的類(lèi)型。

它必須保證局部變量在賦予合適的值以前不能被訪問(wèn)，而且類(lèi)的字段中必須總是被賦予正確類(lèi)型的值，類(lèi)的方法被調(diào)用時(shí)總是傳遞正確數(shù)值和類(lèi)型的參數(shù)。

它必須保證每一個(gè)操作碼都是合法的，即每一個(gè)操作碼都有合法的操作數(shù)，以及對(duì)每一個(gè)操作碼，合適類(lèi)型的數(shù)值位于局部變量中或是在操作數(shù)粘中。

在第一、第二、第三掃描中，class文件校驗(yàn)器可以保證導(dǎo)入的class文件構(gòu)成合理，內(nèi)在一致，符合Java編程語(yǔ)言的限制條件，并且包含的字節(jié)碼可以被Java虛擬機(jī)安全的執(zhí)行。

第四趟：符號(hào)引用的驗(yàn)證

Java虛擬機(jī)將追蹤哪些引用--從被驗(yàn)證的class文件到被引用的class文件，以確保這個(gè)引用是正確的。

必須檢查被檢測(cè)的class文件以外的其他類(lèi)，所以需要裝載新的類(lèi)。

大多數(shù)Java虛擬機(jī)的實(shí)現(xiàn)采用延遲裝載類(lèi)的策略，直到類(lèi)真正地被程序使用時(shí)才裝載。

即使一個(gè)實(shí)現(xiàn)確實(shí)預(yù)先裝載了這些類(lèi)，為了加快裝載過(guò)程的速度，還是會(huì)表現(xiàn)為延遲裝載。

class文件檢驗(yàn)器的第四趟掃描僅僅是動(dòng)態(tài)連接過(guò)程的一部分，

當(dāng)一個(gè)class文件被裝載時(shí)，它包含了對(duì)其他類(lèi)的符號(hào)引用以及它們的字段和方法。

一個(gè)符號(hào)引用是一個(gè)字符串，它給出了名字，并且可能還包含了其他關(guān)于這個(gè)被引用項(xiàng)的信息--這些信息必須足矣唯一地識(shí)別一個(gè)類(lèi)、字段或方法

對(duì)于其他類(lèi)的符號(hào)引用 必須給出這個(gè)類(lèi)的全名；

對(duì)于其他類(lèi)的字段的符號(hào)引用必須給出類(lèi)名、字段名以及字段描述符；

對(duì)于其他類(lèi)中的方法的引用必須給出類(lèi)名、方法名、方法的描述符

動(dòng)態(tài)連接是一個(gè)將符號(hào)引用解析為直接引用的過(guò)程

當(dāng)Java虛擬機(jī)執(zhí)行字節(jié)碼時(shí)，如果它遇到一個(gè)操作碼，這個(gè)操作碼第一次使用一個(gè)指向另一個(gè)類(lèi)的符號(hào)引用，那么虛擬機(jī)就必須解析這個(gè)符號(hào)引用。

在解析時(shí)，虛擬機(jī)執(zhí)行兩個(gè)基本任務(wù)：

1.查找被引用的類(lèi)(如果必要的話就裝載它)

2.將符號(hào)引用替換為直接引用，例如一個(gè)指向類(lèi)、字段或方法的指針或偏移量

虛擬機(jī)必須記住這個(gè)直接引用，這樣當(dāng)它以后再次遇到相同的引用時(shí)，它就可以立即使用這個(gè)直接引用。

當(dāng)Java虛擬機(jī)解析一個(gè)符號(hào)引用時(shí)，class文件校驗(yàn)器的第四趟掃描確保了這個(gè)引用是合法的。

當(dāng)這個(gè)引用是個(gè)非法引用時(shí)--例如，這個(gè)類(lèi)不能被裝載，或這個(gè)類(lèi)的確存在，但是不包含被引用的字段或方法--class文件校驗(yàn)器將會(huì)拋出一個(gè)錯(cuò)誤

如果Volcano類(lèi)中的某個(gè)方法調(diào)用了名為L(zhǎng)ava的類(lèi)中的某個(gè)方法，這個(gè)Lava中的方法的全名和描述符將包含在Volcano的class文件的二進(jìn)制數(shù)據(jù)中。

當(dāng)Volcano的方法在執(zhí)行過(guò)程中第一次調(diào)用Lava的方法時(shí)，Java虛擬機(jī)必須確認(rèn)類(lèi)Lava中存在這個(gè)方法，并且這個(gè)方法的名字和描述符與Volcano中期待的相匹配。

如果這個(gè)符號(hào)引用(類(lèi)名、方法名、描述符)是正確的，那么 虛擬機(jī)將把他替換為一個(gè)直接引用，例如一個(gè)指針，從那時(shí)開(kāi)始將使用這個(gè)指針。

但如果Volcano類(lèi)中的符號(hào)引用不能匹配Lava類(lèi)中的任何方法時(shí)，第四趟掃描驗(yàn)證失敗，Java虛擬機(jī)將拋出一個(gè)NoSuchMethodError

二進(jìn)制兼容

正因?yàn)镴ava程序是動(dòng)態(tài)連接的，所以class文件校驗(yàn)器在第四次掃描中，必須檢查相互引用的類(lèi)之間是否兼容。

在一個(gè)類(lèi)中，哪些可以被修改、增加和刪除，而并不破壞這個(gè)被修改的類(lèi)與依賴它的那些事先已存在的類(lèi)之間的二進(jìn)制兼容性。

例如，向一個(gè)類(lèi)中增加一個(gè)新的方法始終是一個(gè)影響二進(jìn)制兼容性的改動(dòng)，但是不能刪除一個(gè)正在被其他類(lèi)使用的方法。

Java虛擬機(jī)內(nèi)置的安全特性

Java虛擬機(jī)裝載一個(gè)類(lèi)，并且對(duì)它進(jìn)行了第一到第三趟的class文件檢驗(yàn)，這些字節(jié)碼就可以被運(yùn)行。

除了對(duì)符合引用的校驗(yàn)(class文件校驗(yàn)的第四趟掃描)，Java虛擬機(jī)在執(zhí)行字節(jié)碼時(shí)還進(jìn)行一些內(nèi)置的安全機(jī)制的操作。

這些機(jī)制大多數(shù)是Java的類(lèi)型安全的基礎(chǔ)。

1.類(lèi)型安全的引用轉(zhuǎn)換

2.結(jié)構(gòu)化的內(nèi)存訪問(wèn)(無(wú)指針?biāo)惴?

3.自動(dòng)垃圾收集(不必顯示地釋放被分配的內(nèi)存)

4.數(shù)組邊界檢查

5.空引用檢查

通過(guò)保證一個(gè)Java程序只能使用類(lèi)型安全的、結(jié)構(gòu)化的方法去訪問(wèn)內(nèi)存，Java虛擬機(jī)使得Java程序更為健壯。

Java虛擬機(jī)并未指明運(yùn)行時(shí)數(shù)據(jù)空間在Java虛擬機(jī)內(nèi)部是如何分布的。

運(yùn)行時(shí)數(shù)據(jù)空間是指一些內(nèi)存空間，Java虛擬機(jī)用這些空間來(lái)存儲(chǔ)一個(gè)Java程序時(shí)所需要的數(shù)據(jù)：

Java棧(每個(gè)線程一個(gè))、

一個(gè)存儲(chǔ)字節(jié)碼的方法區(qū)，

以及一個(gè)垃圾收集堆(它用來(lái)存儲(chǔ)由運(yùn)行的程序創(chuàng)建的對(duì)象)

查看一個(gè)class文件的內(nèi)部，將找不到任何內(nèi)存地址。

當(dāng)Java虛擬機(jī)裝載一個(gè)class文件時(shí)，由它決定將這些字節(jié)碼以及其他從class文件中解析得到的數(shù)據(jù)放置在內(nèi)存的什么地方。

當(dāng)Java虛擬機(jī)啟動(dòng)一個(gè)線程時(shí)，由它決定將它為這個(gè)線程創(chuàng)建Java棧放到哪里。

當(dāng)它創(chuàng)建一個(gè)新的對(duì)象時(shí)，也是由它決定這個(gè)對(duì)象放到內(nèi)存中什么地方。

對(duì)每個(gè)Java虛擬機(jī)的實(shí)現(xiàn)來(lái)說(shuō)，由它的設(shè)計(jì)者來(lái)決定使用什么數(shù)據(jù)結(jié)構(gòu)來(lái)表示運(yùn)行時(shí)數(shù)據(jù)空間，并且將它們放在內(nèi)存的哪個(gè)位置。

禁止對(duì)內(nèi)存進(jìn)行非結(jié)構(gòu)化訪問(wèn)，是字節(jié)碼指令集本身的內(nèi)在本質(zhì)。

本地方法沒(méi)有經(jīng)過(guò)Java API，所以當(dāng)它視圖做些具有破壞性的動(dòng)作時(shí)，安全管理器并未檢查。

安全管理器中包含一個(gè)方法，用來(lái)確定一個(gè)程序是否能裝載動(dòng)態(tài)連接庫(kù)，因?yàn)樵谡{(diào)用本地方法時(shí) 動(dòng)態(tài)連接庫(kù)是必須的。

在調(diào)用本地方法前必須確認(rèn)它是可信任的。

異常的結(jié)構(gòu)化處理。因?yàn)镴ava虛擬機(jī)支持異常，所以當(dāng)一些違反安全的行為發(fā)生時(shí)，它會(huì)做出一些結(jié)構(gòu)化處理，Java虛擬機(jī)將拋出一個(gè)異?；蛞粋€(gè)錯(cuò)誤，而不是崩潰。

這個(gè)異?；蝈e(cuò)誤導(dǎo)致這個(gè)錯(cuò)誤線程的死亡，而不是使整個(gè)系統(tǒng)陷入癱瘓

拋出一個(gè)錯(cuò)誤 總是導(dǎo)致拋出錯(cuò)誤的這個(gè)線程死亡，這對(duì)一個(gè)運(yùn)行的Java程序來(lái)說(shuō)是一個(gè)不便因素，但它不會(huì)導(dǎo)致整個(gè)程序的中止。

如果這個(gè)程序還有一些線程正在正常工作，則這些線程有可能繼續(xù)正常工作，即使它的同伴已經(jīng)死亡。

而拋出y一個(gè)異?？赡軐?dǎo)致這個(gè)線程的死亡，但是他經(jīng)常作為一個(gè)手段被使用，使程序能夠?qū)⒖刂茝陌l(fā)生異常的地方轉(zhuǎn)到處理這個(gè)異常的情況。

安全管理器和Java API 它主要用于保護(hù)虛擬機(jī)的外部資源不被虛擬機(jī)內(nèi)運(yùn)行的惡意或有漏洞的代碼侵犯。 安全管理器定義了沙箱的外部邊界。 因?yàn)樗强啥ㄖ频?，所以它允許程序建立自定義的安全策略。 當(dāng)Java API進(jìn)行任何可能不安全的操作時(shí)，它都會(huì)向安全管理器請(qǐng)求許可，從而強(qiáng)制執(zhí)行自定義的安全策略。 要向安全管理器請(qǐng)求許可，Java API將調(diào)用安全管理器對(duì)象的"check"方法(因?yàn)檫@些方法名都是以"check"開(kāi)頭)。 例如，安全管理器的checkRead()方法決定了線程可否讀取一個(gè)特定的文件， checkWrite()方法決定了線程能否對(duì)一個(gè)特定的文件進(jìn)行寫(xiě)操作。 這些方法的實(shí)現(xiàn)定義了應(yīng)用程序的定制安全策略。
Java API在進(jìn)行一個(gè)可能不安全的操作前，總是檢查安全管理器。
當(dāng)java應(yīng)用程序啟動(dòng)時(shí)，它還沒(méi)有安全管理器，但是，應(yīng)用程序通過(guò)將一個(gè)指向java.lang.SecurityManager或是其子類(lèi)的實(shí)例傳給setSecurityManager()，依次來(lái)安裝安全管理器，這個(gè)動(dòng)作是可選的。
如果應(yīng)用程序沒(méi)有安裝安全管理器，那么它就不會(huì)對(duì)請(qǐng)求Java API的任何動(dòng)作做限制--Java API將做任何被請(qǐng)求的事(這就是Java應(yīng)用程序在默認(rèn)情況下將不會(huì)有任何安全限制的原因)
如果應(yīng)用程序確實(shí)安裝了 安全管理器，那么它將負(fù)責(zé)應(yīng)用程序整個(gè)剩余的生命周期，它不可被替代、擴(kuò)展或者修改。 Java API將只執(zhí)行那些被安全管理器同意的請(qǐng)求。