單板機 單片機 個人計算機有什么區(qū)別嗎

1、單板機 單片機 個人計算機有什么區(qū)別嗎 懸賞分：0 | 解決時間：2010-7-10 19:08 | 提問者：1網(wǎng)命徒1 最佳答案 單板機是很久以前的稱呼，那時集成電路發(fā)展剛起步?jīng)]多久，不能將很多的東西集成在一起。后來，隨著大規(guī)模集成電路（ic）的出現(xiàn)，可以把cpu、串口、DA、時鐘等功能模塊集成在一塊芯片中，也就是現(xiàn)在說的單片機（single chip unit/micro-control-unit/MCU-單片機）.單片機將以往單板機上的大部分需要依靠很多獨立元件的功能模塊集成在一塊芯片之中了，（單板機上的非IC器件一般沒法集成）。集成后，我們再進行設計時，就可以省略很多外圍的器件，因為一

2、片單片機就集成了以前單板機上很多元件的功能啦。單片機，常用的英文縮小是MCU-也即micro-control-unit。從這個名稱就可以看出，它是一個具有完整的功能的控制模塊了。將單片機與外圍電路構成的就是單片機系統(tǒng)了。這個單片機系統(tǒng)就是一個小型的計算機系統(tǒng)了。功能方面肯定不能與我們的PC相比了。樓上說的計算機就是PC機，有點狹隘了。計算機有微型計算機，PC機，還有大型的運算中心以及超大規(guī)模的超算中心。但是計算機都離不開CPU等模塊的。數(shù)據(jù)線條數(shù)是應該跟字長一樣還是跟最小尋址單位長度（比如字節(jié)）一樣啊假設主存最小尋址單位是字節(jié)，一個字是兩個字節(jié)，那數(shù)據(jù)線條數(shù)應該是8還是16。目前來看好像是16

3、，因為字長應該是主存一次最多能存取的長度，數(shù)據(jù)線應該與這個長度一樣多，而且這樣也和書上按字編址和按字節(jié)編址那地方相吻合，字長是多少不影響主存容量。但是想想也感覺不太對，因為不都是按照2(地址線條數(shù))*（數(shù)據(jù)線條數(shù)）來計算主存容量嗎，按個公式的話主存容量與數(shù)據(jù)線條數(shù)有關了，但是如果最小編制單位不變的話，字長是多少（數(shù)據(jù)線幾條）并不應該影響主存容量啊。如果數(shù)據(jù)線是8條，要是一次存取16位也可以分時在數(shù)據(jù)線上傳送嗎。到底是怎么回事，誰能給我講清楚啊，謝謝了！收藏 分享 內(nèi)存詳解理解 JVM 如何使用 AIX 上的本機內(nèi)存Andrew Hall, 軟件工程師, IBMAndrew Hall 于 200

4、4 年加入 IBM Java Technology Centre，他在 Java System Test 小組工作了兩年。然后在 Java 服務團隊工作了 18 個月，其間，他在多個平臺上調(diào)試了數(shù)十個本機內(nèi)存問題。他目前是 Java Reliability, Availability and Serviceability 團隊的成員。在業(yè)余生活中，他喜歡閱讀、攝影和玩魔術。簡介： Java 堆耗盡并不是造成 的惟一原因。如果本機內(nèi)存 耗盡，則會發(fā)生普通調(diào)試技巧無法解決的 OutOfMemoryError。本文將討論本機內(nèi)存的概念，Java 運行時如何使用它，它被耗盡時會出現(xiàn)什么情況，

5、以及如何在 AIX® 上調(diào)試本機 OutOfMemoryError 。針對 Linux® 和 Windows® 系統(tǒng)的相同主題將在 另一篇同類文章 中介紹。標記本文！發(fā)布日期： 2009 年 5 月 11 日 級別： 中級 其他語言版本： 英文 訪問情況 2063 次瀏覽 建議: 0 (添加評論) 平均分 （共 7 個評分 ）Java 堆（每個 Java 對象在其中分配）是您在編寫 Java 應用程序時使用最頻繁的內(nèi)存區(qū)域。JVM 設計用于將我們與主機的特性隔離，所以將內(nèi)存當作堆來考慮再正常不過了。您一定

6、遇到過 Java 堆 OutOfMemoryError ，它可能是由于對象泄漏造成的，也可能是因為堆的大小不足以存儲所有數(shù)據(jù)，您也可能了解這些場景的一些調(diào)試技巧。但是隨著您的 Java 應用程序處理越來越多的數(shù)據(jù)和越來越多的并發(fā)負載，您可能就會遇到無法使用常規(guī)技巧進行修復的 OutOfMemoryError。在一些場景中，即使 java 堆未滿，也會拋出錯誤。當這類場景發(fā)生時，您需要理解 Java 運行時環(huán)境（Java Runtime Environment，JRE）內(nèi)部到底發(fā)生了什么。Java 應用程序在 Java 運行時的虛擬化環(huán)境中運行，但是運行時本身是使用 C 之類的語言編寫的本機程序

7、，它也會耗用本機資源，包括本機內(nèi)存。本機內(nèi)存是可用于運行時進程的內(nèi)存，它與 Java 應用程序使用的 java 堆內(nèi)存不同。每種虛擬化資源（包括 Java 堆和 Java 線程）都必須存儲在本機內(nèi)存中，虛擬機在運行時使用的數(shù)據(jù)也是如此。這意味著主機的硬件和操作系統(tǒng)施加在本機內(nèi)存上的限制會影響到 Java 應用程序的性能。本系列文章共分兩篇，討論不同平臺上的相應話題。本文是其中一篇。在這兩篇文章中，您將了解什么是本機內(nèi)存，Java 運行時如何使用它，本機內(nèi)存耗盡之后會發(fā)生什么情況，以及如何調(diào)試本機 OutOfMemoryError。本文將討論 AIX 并專注于 IBM® Develop

8、er Kit for Java。另一篇 類似的文章 討論 Windows 和 Linux 上的這一主題，并且不會介紹任何特定的 Java 運行時。本機內(nèi)存簡介我將首先解釋一下操作系統(tǒng)和底層硬件給本機內(nèi)存帶來的限制。如果您熟悉使用 C 等語言管理動態(tài)內(nèi)存，那么您可以直接跳到 下一節(jié)。硬件限制本機進程遇到的許多限制都是由硬件造成的，而與操作系統(tǒng)沒有關系。每臺計算機都有一個處理器和一些隨機存取存儲器（RAM），后者也稱為物理內(nèi)存。處理器將數(shù)據(jù)流解釋為要執(zhí)行的指令，它擁有一個或多個處理單元，用于執(zhí)行整數(shù)和浮點運算以及更高級的計算。處理器具有許多寄存器 ?？焖俚膬?nèi)存元素，用作被執(zhí)行的計算的工作存儲，寄存

9、器大小決定了一次計算可使用的最大數(shù)值。處理器通過內(nèi)存總線連接到物理內(nèi)存。物理地址（處理器用于索引物理 RAM 的地址）的大小限制了可以尋址的內(nèi)存。例如，一個 16 位物理地址可以尋址 0x0000 到 0xFFFF 的內(nèi)存地址，這個地址范圍包括 216 = 65536 個惟一的內(nèi)存位置。如果每個地址引用一個存儲字節(jié)，那么一個 16 位物理地址將允許處理器尋址 64KB 內(nèi)存。處理器被描述為特定數(shù)量的數(shù)據(jù)位。這通常指的是寄存器大小，但是也存在例外，比如 32 位 390 指的是物理地址大小。對于桌面和服務器平臺，這個數(shù)字為 31、32 或 64；對于嵌入式設備和微處理器，這個數(shù)字可能小至 4。物

10、理地址大小可以與寄存器帶寬一樣大，也可以比它大或小。如果在適當?shù)牟僮飨到y(tǒng)上運行，大部分 64 位處理器可以運行 32 位程序。表 1 列出了一些流行的架構以及它們的寄存器和物理地址大小：表 1. 一些流行處理器架構的寄存器和物理地址大小架構寄存器帶寬（位）物理地址大?。ㄎ唬ìF(xiàn)代）Intel® x86323236，具有物理地址擴展（Pentium Pro 和更高型號）x86 6464目前為 48 位（以后將會增大）PPC6464在 POWER 5 上為 50 位390 31 位3231390 64 位6464操作系統(tǒng)和虛擬內(nèi)存如果您編寫無需操作系統(tǒng)，直接在處理器上運行的應用程序，您可

11、以使用處理器可以尋址的所有內(nèi)存（假設連接到了足夠的物理 RAM）。但是要使用多任務和硬件抽象等特性，幾乎所有人都會使用某種類型的操作系統(tǒng)來運行他們的程序。在 Aix 等多任務操作系統(tǒng)中，有多個程序在使用系統(tǒng)資源。需要為每個程序分配物理內(nèi)存區(qū)域來在其中運行。可以設計這樣一個操作系統(tǒng)：每個程序直接使用物理內(nèi)存，并且可以可靠地僅使用分配給它的內(nèi)存。一些嵌入式操作系統(tǒng)以這種方式工作，但是這在包含多個未經(jīng)過集中測試的應用程序的環(huán)境中是不切實際的，因為任何程序都可能破壞其他程序或者操作系統(tǒng)本身的內(nèi)存。虛擬內(nèi)存 允許多個進程共享物理內(nèi)存，而且不會破壞彼此的數(shù)據(jù)。在具有虛擬內(nèi)存的操作系統(tǒng)（比如 Windows

12、、Linux 和許多其他操作系統(tǒng)）中，每個程序都擁有自己的虛擬地址空間 一個邏輯地址區(qū)域，其大小由該系統(tǒng)上的地址大小規(guī)定（所以，桌面和服務器平臺的虛擬地址空間為 31、32 或 64 位）。進程的虛擬地址空間中的區(qū)域可被映射到物理內(nèi)存、文件或任何其他可尋址存儲。操作系統(tǒng)可以將物理內(nèi)存中的數(shù)據(jù)移動到未使用的交換區(qū)，以便于最充分地利用物理內(nèi)存。當程序嘗試使用虛擬地址訪問內(nèi)存時，操作系統(tǒng)結合片上硬件將該虛擬地址映射到物理位置。該位置可以是物理 RAM、文件或交換區(qū)。如果一個內(nèi)存區(qū)域被移動到交換空間，那么它將在被使用之前加載回物理內(nèi)存中。圖 1 展示了虛擬內(nèi)存如何將進程地址空間區(qū)域映射到共享資源：圖

13、1. 虛擬內(nèi)存將進程地址空間映射到物理資源本機程序的每個實例都作為進程運行。在 AIX 上，進程是關于 OS 控制資源（比如文件和套接字信息）、虛擬地址空間以及至少一個執(zhí)行線程的一系列信息。雖然 32 位地址可以引用 4GB 數(shù)據(jù)，但程序不能獨自使用整個 4GB 地址空間。與其他操作系統(tǒng)一樣（比如 Windows 和 Linux），地址空間分為多個部分，程序只能使用其中的一些部分；其余部分供操作系統(tǒng)使用。與 Windows 和 Linux 相比，AIX 內(nèi)存模型更加復雜并且可以更加精確地進行優(yōu)化。AIX 32 位內(nèi)存模型被分成 16 個 256MB 分段進行管理。圖 2 顯示了默認 32 位

14、AIX 內(nèi)存模型的布局：圖 2. 默認 AIX 內(nèi)存模型不同分段的作用如下：· 分段 0：AIX 內(nèi)核數(shù)據(jù)（用戶程序不能直接訪問） · 分段 1：應用程序文本（可執(zhí)行代碼） · 分段 2：線程棧和本機堆（通過 malloc/free 控制的區(qū)域） · 分段 3-C 和 E：內(nèi)存映射區(qū)域（包括文件）和共享內(nèi)存 · 分段 D：共享庫文本（可執(zhí)行代碼） · 分段 F：共享庫數(shù)據(jù) 用戶程序只能直接控制 16 個分段中的 12 個 即 4GB 中的 3GB。最大的限制是，本機堆和所有線程棧都保存在分段 2 中。為了適應對數(shù)據(jù)需求較高的程序，AI

15、X 提供了一個大內(nèi)存模型。大內(nèi)存模型允許程序員或用戶附加一些共享/映射分段作為本機堆使用，通過在構建可執(zhí)行程序時提供一個鏈接器選項或者在程序啟動之前設置 LDR_CNTRL 環(huán)境變量。要在運行時支持大內(nèi)存模型，需要設置 LDR_CNTRL=MAXDATA=0xN0000000。其中， N 位于 1 和 8 之間。超過此范圍的任何值都會造成操作系統(tǒng)使用默認內(nèi)存模型。在大內(nèi)存模型中，本機堆從分段 3 開始；分段 2 僅用于原始（初始）線程棧。當您使用大內(nèi)存模型時，分段分配是靜態(tài)的；也就是說，如果你請求 4 個數(shù)據(jù)分段（1GB 本機堆），但是僅分配 1 個本機堆分段（256MB），則其他 3 個數(shù)據(jù)

16、分段將不能用于內(nèi)存映射。如果您希望本機堆大于 2GB，并且運行的是 AIX 5.1 或更高版本，那么您可以使用 AIX 超大內(nèi)存模型。與大內(nèi)存模型類似，可以通過一個鏈接器選項或在運行時使用 LDR_CNTRL 環(huán)境變量來為編譯時的可執(zhí)行程序啟用超大內(nèi)存模型。要在運行時啟用超大內(nèi)存模型，需要設置 LDR_CNTRL=MAXDATA=0xN0000000DSA。其中， N 位于 0 和 D 之間（如果您使用 AIX 5.2 或更高版本），或位于 1 和 A 之間（如果您使用 AIX 5.1）。 N 值指定可用于本機堆的分段數(shù)量，但與大內(nèi)存模型不同，這些分段可以在必要時用于映射。通常，IBM Jav

17、a 運行時使用超大內(nèi)存模型，除非它被 LDR_CNTRL 環(huán)境變量覆蓋。將 N 設置為 1 和 A 之間，這會使用 3 和 C 之間的分段作為本機存儲。在 AIX 5.2 中，將 N 設置為 B 或更多會更改內(nèi)存布局 它不再使用 D 和 F 作為共享庫，并且允許它們用于本機存儲或映射。將 N 設置為 D 可分配最多 13 個分段（3.25GB）的堆。將 N 設置為 0 可允許分段 3 到 F 用于映射 本機堆保存在分段 2 中。圖 3 展示了不同 AIX 內(nèi)存模型所使用的不同地址空間布局：圖 3. 各種 MAXDATA 值的 AIX 內(nèi)在模型本機內(nèi)存泄漏或本機內(nèi)存過度使用會造成各種問題，這取決

18、于您是耗盡了地址空間還是用完了物理內(nèi)存。耗盡地址空間通常只發(fā)生在 32 位進程中 因為可以輕松地分配最大 4GB 地址空間。64 位進程的用戶空間可以達到上千 GB，并且難以用完。如果您確實耗盡了 Java 進程的地址空間，則 Java 運行時會開始出現(xiàn)一些奇怪的癥狀，本文將在稍后討論這些情況。在進程地址空間大于物理內(nèi)存的系統(tǒng)中，內(nèi)存泄漏或本機內(nèi)存過度使用會迫使操作系統(tǒng)提供一些虛擬地址空間。訪問操作系統(tǒng)提供的內(nèi)存地址要比讀取（物理內(nèi)存中的）常駐地址慢很多，因為必須硬盤驅動器加載它。如果您同時嘗試使用過多 RAM 虛擬內(nèi)存，造成數(shù)據(jù)無法存儲在物理內(nèi)存中，則系統(tǒng)掛起（thrash） 也就是花費大多

19、數(shù)時間在交換空間與內(nèi)存之間來回復制數(shù)據(jù)。出現(xiàn)這種情況時，計算機和各應用程序的性能將變得很差，用戶會立即覺察到出現(xiàn)了問題。當 JVM 的 Java 堆被換出時，垃圾收集器的性能將變得極差，甚至會造成應用程序掛起。如果多個 Java 運行時在一臺機器上同時運行，則物理內(nèi)存必須滿足所有 Java 堆的需要?；仨撌譐ava 運行時如何使用本機內(nèi)存Java 運行時是一個 OS 進程，它受上一節(jié)所提到的硬件及操作系統(tǒng)限制。運行時環(huán)境提供由一些未知用戶代碼驅動的功能；這使得無法預測運行時環(huán)境在各種情況下需要哪些資源。Java 應用程序在托管 Java 環(huán)境中采取的每一個措施都有可能影響提供該環(huán)境的運行時的資

20、源需求。本節(jié)討論 Java 應用程序消耗本機內(nèi)存的方式及原因。Java 堆和垃圾收集Java 堆是分配給對象的內(nèi)存區(qū)。IBM Developer Kits for Java Standard Edition 擁有一個物理堆，但一些專門的 Java 運行時，比如 IBM WebSphere Real Time，則有多個堆。堆可以分為多個部分，例如 IBM gencon 策略的 nursery 和 tenured 區(qū)。大多數(shù) Java 堆都是作為本機內(nèi)存的相鄰 slab 實現(xiàn)的?？刂贫汛笮〉姆椒ㄊ窃?Java 命令行中使用 -Xmx 和 -Xms 選項（mx 是堆的最大大小，ms 是初始大小）。雖

21、然邏輯堆（活躍使用的內(nèi)存區(qū)）將根據(jù)堆中對象的數(shù)量和垃圾收集（CG）所花費的時間增大或縮小，但所使用的本機內(nèi)存量仍然保持不變，并且將由 -Xmx 值（最大堆大小）決定。內(nèi)存管理器依賴作為相鄰內(nèi)存 slab 的堆，因此當堆需要擴展時無法分配更多本機內(nèi)存；所有堆內(nèi)存必須預先保留。保留本機內(nèi)存與分配它不同。保留本機內(nèi)存時，它不受物理內(nèi)存或其他存儲的支持。雖然保留地址空間塊不會耗盡物理資源，但它確實能防止內(nèi)存用于其他目的。保留從未使用的內(nèi)存造成的泄漏與已分配內(nèi)存的泄漏同樣嚴重。AIX 上的 IBM 垃圾收集器將最大限度減少物理內(nèi)存的使用，當使用的堆區(qū)域減少時，它會釋放堆的備份存儲。對于大多數(shù) Java

22、應用程序，Java 堆是最大的進程地址空間使用者，因此 Java 啟動程序使用 Java 堆大小來確定如何配置地址空間。表 2 列出了不同堆大小范圍的默認內(nèi)存模型配置。您可以覆蓋內(nèi)存模型，方法是在啟動 Java 啟動程序之前設置 LDR_CNTRL 環(huán)境變量。如果您正嵌入 Java 運行時或編寫自己的啟動程序，則需要自己配置內(nèi)存模型 通過指定適當?shù)逆溄悠鳂擞浕蛟趩?Java 啟動程序之前設置 LDR_CNTRL。表 2. 不同堆大小的默認 LDR_CNTRL 設置堆范圍LDR_CNTRL 設置最大本機堆大小最大映射空間（不占用本機堆）-Xmx0M to -Xmx2304MMAXDATA=0x

23、A0000000DSA2.5GB512MB-Xmx2304M to -Xmx3072MMAXDATA=0xB0000000DSA2.75GB512MB> -Xmx2304MMAXDATA=0x0DSA256MB3.25GB即時（Just-in-time，JIT）編譯器JIT 編譯器在運行時將 Java 字節(jié)碼編譯為優(yōu)化的二進制碼。這將極大地改善 Java 運行時的速度，并允許 Java 應用程序的運行速度能與本機代碼相提并論。編譯字節(jié)碼將使用本機內(nèi)存（就像靜態(tài)編譯器一樣，比如 gcc，需要內(nèi)存才能運行），但是 JIT 的輸出（可執(zhí)行代碼）也可以存儲在本機內(nèi)存中。包含許多經(jīng)過 JIT 編譯

24、的方法的 Java 應用程序比較小的應用程序使用更多本機內(nèi)存。類和類加載器Java 應用程序由定義對象結構和方法邏輯的類組成。它們還使用 Java 運行時類庫中的類（比如 ），并且可以使用第三方庫。這些類需要在它們的使用期間存儲在內(nèi)存中。Java 5 之后的 IBM 實現(xiàn)為各類加載器分配本機內(nèi)存 slab，用于存儲類數(shù)據(jù)。Java 5 中的共享類技術將共享內(nèi)存中的某個區(qū)域映射到存儲只讀（因此可以共享）類數(shù)據(jù)的地址空間。當多個 JVM 在同一臺機器上運行時，這將減少存儲類數(shù)據(jù)所需的物理內(nèi)存量。共享類還可以改善 JVM 的啟動時間。共享類系統(tǒng)將固定大小的共享內(nèi)存區(qū)域映射到地址空間?？梢圆煌耆加霉?/p>

25、享類緩存，并且其中還可以包含當前未使用的類（由其他 JVM 載入），因此使用共享類將比未使用共享類占用更多地址空間（但物理內(nèi)存較少）。需要重點注意，共享類不能防止類加載器取消加載 但它會造成類數(shù)據(jù)的一個子集保留在類緩存中。參見 參考資料 了解更多關于共享類的信息。加載更多類需要使用更多本機內(nèi)存。每個類加載器還有各自的本機內(nèi)存開銷 因此讓許多類加載分別加載一個類會比讓一個類加載器許多類使用更多本機內(nèi)存。記住，不僅您的應用程序類需要占用內(nèi)存；框架、應用服務器、第三方庫和 Java 運行時都包含根據(jù)需要加載且占用空間的類。Java 運行時可以卸載類以回收空間，但僅限于一些嚴格的條件下。不能卸載單個類

26、；而應卸載類加載器，其對象是加載的所有類。卸載類加載器的條件僅限于：· Java 堆未包含到表示該類加載器的 對象的引用。 · Java 堆未包含到表示該類加載器加載的類的任何 對象的引用。 · 該類加載器加載的任何類的對象在 Java 堆中都處于非活動狀態(tài)（即未被引用）。 注意，Java 運行時為所有 Java 應用程序創(chuàng)建的 3 個類默認加載器 bootstrap、extension 和 application 永遠都無法滿足這些標準；因此，通過應用程序類加載器加載的任何系統(tǒng)類（比如 ）或任何應用程序類都不能被釋放。即使類加載器可用于收集，但運行時只將類加載器

27、作為 GC 周期的一部分進行收集。IBM gencon GC 策略（通過 -Xgcpolicy:gencon 命令行參數(shù)啟用）僅卸載主要（tenured）收集上的類加載器。如果某個應用程序正在運行 gencon 策略并創(chuàng)建和釋放許多類加載器，則您會發(fā)現(xiàn)大量本機內(nèi)存在 tenured 收集期間由可收集的類加載器保存。參見 參考資料，了解關于不同 IBM GC 策略的更多信息。還可以在運行時生成類，而不需要您釋放它。許多 JEE 應用程序使用 JavaServer Pages (JSP) 技術生成 Web 頁面。使用 JSP 為執(zhí)行的各個 . jsp 頁面生成類，該類的持續(xù)時間為加載它們的類加載器

28、的生存期 通常為 Web 應用程序的生存期。生成類的另一個種常用方法是使用 Java 反射。使用 API 時，Java 運行時必須將反射對象的方法（比如 ）連接到被反射的對象或類。這種 “訪問方法” 可以使用 Java Native Interface (JNI)，它需要的設置非常少但運行緩慢，或者它可以在運行時動態(tài)地為您希望反射的各對象類型構建一個類。后一種方法設置較慢，但運行更快，因此它對于經(jīng)常反射特定類的應用程序非常理想。在最初幾次反射類時，Java 運行時使用 JNI 方法。但是在使用了幾次之后，訪問方法將擴展到字節(jié)訪問方法中，該方法涉及構建一個類并通過一個新的類加載器來加載它。執(zhí)行大

29、量反射會造成創(chuàng)建許多訪問程序類和類加載器。保留到反射對象的引用會造成這些類保持為活動狀態(tài)并繼續(xù)占用空間。由于創(chuàng)建字節(jié)碼訪問程序相當慢，因此 Java 運行時可以緩存這些訪問程序供稍后使用。一些應用程序和框架還緩存反射對象，因此會增加它們的本機內(nèi)存占用。您可以使用系統(tǒng)屬性控制反射訪問程序行為。IBM Developer Kit for Java 5.0 的默認擴展閥值（JNI 存取器在擴展到字節(jié)碼存取器中之前的使用次數(shù)）是 15。您可以通過設置 系統(tǒng)屬性來修改該值。您可以在 Java 命令行中通過 N 來設置它。如果您將 inflationThreshold 設置為 0 或更小的值，則存取器將永

30、遠不會擴展。如果您發(fā)現(xiàn)應用程序要創(chuàng)建許多 （用于加載字節(jié)碼存取器的類加載器），則這種設置非常有用。 另一種（極易造成誤解的）設置也會影響反射存取器。 會完全禁用擴展，但它會造成字節(jié)碼存取器濫用。使用 會增加反射類加載器占用的地址空間量，因為會創(chuàng)建更多的類加載器。您可以通過 javacore 轉儲來測量類和 JIT 代碼在 Java 5 及以上版本中使用了多少內(nèi)存。javacore 是一個純文本文件，它包含轉儲發(fā)生時 Java 運行時的內(nèi)部狀態(tài)的概述 包括關于已分配本機內(nèi)存分段的信息。較新版本的 IBM Developer Kit for Java 5 和 6 將內(nèi)存使用情況歸訥在 javaco

31、re 中，對于較老版本（Java 5 SR10 和 Java 6 SR3 之前），本文的示例代碼包包括一個 Perl 腳本，可以用于分配和呈現(xiàn)數(shù)據(jù)（參見 下載）。如果要運行它，您需要 Perl 解釋器，它可以用于 AIX 和其他平臺。參見 參考資料 了解詳細信息。Javacores 將在拋出 OutOfMemoryError 時生成（地址空間耗盡時可能會出現(xiàn)這種情況）。您還可以通過向 Java 進程發(fā)送一個 SIGQUIT 來觸發(fā)此事件（kill -3 <pid>）。要獲取內(nèi)存分段使用的概要信息，運行：perl get_memory_use.pl javacore.<date

32、>.<time>.<pid>.txt腳本的輸出如下所示：perl get_memory_use.pl javacore.20080111.081905.1311.txtSegment Usage Reserved BytesClass Memory 281767824Internal Memory 25763872JIT Code Cache 67108864JIT Data Cache 33554432Object Memory 536870912JNIJNI 允許本機代碼（使用 C 和 C+ 等本機語言編寫的應用程序）調(diào)用 Java 方法，反之亦然。Java

33、運行時本身在很大程度上依賴 JNI 代碼實現(xiàn)類庫功能，例如文件和網(wǎng)絡 I/O。JNI 應用程序可以通過三種方式增加 Java 運行時的本機內(nèi)存占用：· JNI 應用程序的本機代碼編譯成加載到進程地址空間中的共享庫或可執(zhí)行程序。較大的本機應用程序在加載時就會占用大量的進程地址空間。 · 本機代碼必須與 Java 運行時共享地址空間。本機代碼執(zhí)行的任何本機內(nèi)存分配或內(nèi)存映射都從 Java 運行時中取出內(nèi)存。· 某些 JNI 功能可以將本機內(nèi)存作為它們普通操作的一部分使用。GetTypeArrayElements 和 GetTypeArrayRegion functio

34、nsNIOJava 1.4 中增加的新 I/O (NIO) 類引入了一種全新的基于渠道和緩沖區(qū)執(zhí)行 I/O 的方式。再加上 Java 堆中的內(nèi)存支持的 I/O 緩沖，NIO 添加了對直接 ByteBuffer 的支持（使用 方法分配），它的備份方式是本機內(nèi)存而不是 Java 堆。直接 ByteBuffer 可以直接傳遞給本機 OS 庫函數(shù)用于執(zhí)行 I/O 在一些場景中顯著提高它們的速度，因為它們可以避免在 Java 堆和本機堆之間復制數(shù)據(jù)。直接 ByteBuffers 的存儲位置很容易讓人感到疑惑。應用程序仍然使用 Java 堆上的對象來編制 I/O 操作，但是數(shù)據(jù)所在的緩沖保存位于本機內(nèi)存中

35、 Java 堆對象僅包含到本機堆緩沖的引用。非直接 ByteBuffer 將其數(shù)據(jù)保存在 Java 堆上的一個 byte 數(shù)組中。圖 4 顯示了直接和非直接 ByteBuffer 對象之間的不同：圖 4. 直接和非直接 的內(nèi)存拓撲直接 ByteBuffer 對象會自動消除它們的本機緩沖，但是它們只能作為 Java 堆 GC 的一部分 因此它們不會自動響應本機堆的壓力。僅當 Java 堆過滿以至于不能響應堆分配請求，或者當 Java 應用程序明確請求它時（不建議這樣做，因為會產(chǎn)生性能問題），才會執(zhí)行 GC。一種出現(xiàn)問題的情況是本機堆變滿且一個或多個直接 ByteBuffers 可以勝任 GC 的

36、工作（并且可以釋放以增加本機堆的空閑空間），但是 Java 堆基本為空，因此不會執(zhí)行 GC。線程應用程序中的每個線程都需要內(nèi)存來保存它的棧（用于在調(diào)用函數(shù)時保存本地變量和維持狀態(tài)的內(nèi)存區(qū)）。根據(jù)實現(xiàn)的不同，Java 線程可以有單獨的本機和 Java 棧。除了棧空間之外，每個線程都需要一些本機內(nèi)存用于線程本地存儲和內(nèi)存數(shù)據(jù)結構。棧大小因 Java 實現(xiàn)和架構而異。一些實現(xiàn)允許您指定 Java 線程的棧大小。值通常位于 256KB 和 756KB 之間。雖然每個線程使用的內(nèi)存量相當少，但對于擁有幾百個線程的應用程序，線程棧的內(nèi)存使用總量會達到很高。當應用程序的線程比可用處理器多時，運行它們的效率會

37、很低，并且會造成性能較差且內(nèi)存使用增加?；仨撌兹绾沃辣緳C內(nèi)存已耗盡？Java 運行時處理 Java 堆耗盡與處理本機堆耗盡的方式不同，但這兩種情況都呈現(xiàn)類似的癥狀。Java 應用程序發(fā)現(xiàn) Java 堆耗盡時很難正常運行 因為 Java 應用程序若不分配對象則很難執(zhí)行任何任務。較差的 GC 性能和 OutOfMemoryError 表明 Java 堆已填滿。相反，當 Java 運行時啟動并且應用程序穩(wěn)定運行之后，即便本機堆完全耗盡也能繼續(xù)正常運行。這并不會出示任何古怪的行為，因為需要本機內(nèi)存的操作比需要 Java 堆分配的操作少很多。雖然需要本機內(nèi)存的操作因 JVM 實現(xiàn)而異，但也有一些常見的

38、例子：啟動線程、加載類以及執(zhí)行特定類別的網(wǎng)絡和文件 I/O。本機內(nèi)存不足行為的一致性也比 Java 堆內(nèi)存不足行為差，因為沒有針對本機堆分配的單點控制。但是，所有的 Java 堆分配都在 Java 內(nèi)存管理系統(tǒng)的控制之下，任何本機代碼 無論在 JVM、Java 類庫還是應用程序代碼的內(nèi)部 都可以執(zhí)行本機內(nèi)存分配，并造成它出錯。然后，嘗試進行分配的代碼可以按設計人員的方式來處理它：它可以通過 JNI 接口來拋出一個 OutOfMemoryError，在屏幕上打印輸出消息，出現(xiàn)故障并在稍后再次嘗試，或執(zhí)行其他任務。 缺乏可預測行為意味著無法通過一種簡單的方式來識別本機內(nèi)存耗盡。相反，您需要使用來自

39、 OS 和 Java 運行時的數(shù)據(jù)來確認診斷。回頁首本機內(nèi)存耗盡示例為了幫助您了解本機內(nèi)存耗盡對 Java 運行時的影響，本文的示例代碼（參見 下載）包含一些通過不同方式觸發(fā)本機堆耗盡的 Java 程序。這些示例使用通過 C 編寫的本機庫占用所有本機進程空間，然后嘗試執(zhí)行一些使用本機內(nèi)存的操作。提供的示例已經(jīng)經(jīng)過生成，但編譯它們的指令包含在示例包的頂級目錄的 README.html 文件中。 類提供 gobbleMemory() 方法，該方法在循環(huán)中調(diào)用 malloc，直到幾乎所有本機內(nèi)存耗盡。當它完成其任務時，它會打印輸出分配給標準錯誤的字節(jié)數(shù)，如下所示：Allocated 19535467

40、36 bytes of native memory before running out每個示例的輸出都在 32 位 AIX 上運行的 IBM Java 運行時環(huán)境中被捕獲。示例程序的二進制文件提供在示例包中（參見 下載）。所使用的 IBM Java 運行時版本如下：java version "1.5.0"Java(TM) 2 Runtime Environment, Standard Edition (build pap32devifx-20080811c (SR8a)IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc-

41、32 j9vmap3223ifx-20080811 (JIT enabled)J9VM - 20080809_21892_bHdSMrJIT - 20080620_1845_r8GC - 200806_19)JCL - 20080811b嘗試在本機內(nèi)存耗時啟動線程 類嘗試在進程地址空間耗盡時啟動線程。這是發(fā)現(xiàn) Java 進程內(nèi)存不足的常用方法，因為許多應用程序都會在它們的生命周期過程中啟動線程。StartingAThreadUnderNativeStarvation 的輸出如下：$ ./run_thread_demo_linux_aix_32.shAllocated 2652372992 by

42、tes of native memory before running outJVMDUMP006I Processing Dump Event "systhrow", detail "java/lang/OutOfMemoryError" - Please Wait.JVMDUMP007I JVM Requesting Snap Dump using '/u2/andhall/aix_samples_pack/OutOfNativeBehaviour/Snap.20081207.105130.487430.0001.trc'JVMDUM

43、P010I Snap Dump written to /u2/andhall/aix_samples_pack/OutOfNativeBehaviour/Snap.20081207.105130.487430.0001.trcJVMDUMP007I JVM Requesting Heap Dump using '/u2/andhall/aix_samples_pack/OutOfNativeBehaviour/heapdump.20081207.105130.487430.0002.phd'JVMDUMP010I Heap Dump written to /u2/andhall

44、/aix_samples_pack/OutOfNativeBehaviour/heapdump.20081207.105130.487430.0002.phdJVMDUMP007I JVM Requesting Java Dump using '/u2/andhall/aix_samples_pack/OutOfNativeBehaviour/javacore.20081207.105130.487430.0003.txt'JVMDUMP010I Java Dump written to /u2/andhall/aix_samples_pack/OutOfNativeBehav

45、iour/javacore.20081207.105130.487430.0003.txtJVMDUMP013I Processed Dump Event "systhrow", detail "java/lang/OutOfMemoryError".java.lang.OutOfMemoryError: ZIP006:OutOfMemoryError, ENOMEM error in ZipFile.open at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.&l

46、t;init>(ZipFile.java:238) at java.util.jar.JarFile.<init>(JarFile.java:169) at java.util.jar.JarFile.<init>(JarFile.java:107) at com.ibm.oti.vm.AbstractClassLoader.fillCache(AbstractClassLoader.java:69) at com.ibm.oti.vm.AbstractClassLoader.getResourceAsStream(AbstractClassLoader.java

47、:113) at java.util.ResourceBundle$1.run(ResourceBundle.java:1111) at java.security.AccessController.doPrivileged(AccessController.java:197) at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1107) at java.util.ResourceBundle.findBundle(ResourceBundle.java:952) at java.util.ResourceBundle.get

48、BundleImpl(ResourceBundle.java:789) at java.util.ResourceBundle.getBundle(ResourceBundle.java:726) at com.ibm.oti.vm.MsgHelp.setLocale(MsgHelp.java:103) at com.ibm.oti.util.Msg$1.run(Msg.java:44) at java.security.AccessController.doPrivileged(AccessController.java:197) at com.ibm.oti.util.Msg.<cl

49、init>(Msg.java:41) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:194) at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:764) at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:758) at java.lang.Thread.uncaughtE

50、xception(Thread.java:1315)K0319java.lang.OutOfMemoryError: Failed to create a thread: retVal -1073741830, errno 11 at java.lang.Thread.startImpl(Native Method) at java.lang.Thread.start(Thread.java:979) at com.ibm.jtc.demos.StartingAThreadUnderNativeStarvation.main(StartingAThreadUnderNativeStarvati

51、on.java:33)調(diào)用 嘗試為新 OS 線程分配內(nèi)存。嘗試失敗并造成拋出一個 OutOfMemoryError。JVMDUMP 行通知用戶 Java 運行時已經(jīng)生成了它的標準 OutOfMemoryError 調(diào)試數(shù)據(jù)。嘗試處理第一個 OutOfMemoryError 會造成第二個錯誤 :OutOfMemoryError, ENOMEM error in ZipFile.open。當本機內(nèi)存耗盡時，經(jīng)常會出現(xiàn)多個 OutOfMemoryError，因為一些默認 OutOfMemoryError 處理例程可能需要分配本機內(nèi)存。這聽起來沒有什么作用，但 Java 應用程序拋出的大多數(shù) OutO

52、fMemoryError 都是由 Java 堆內(nèi)存不足造成的，這不會阻止運行時分配本機存儲。區(qū)分本場景中的 OutOfMemoryError 拋出與 Java 堆耗盡造成的其他拋出的惟一方法就是消息。嘗試在本機內(nèi)存不足時分配直接 ByteBuffer 類嘗試在地址空間耗盡時分配一個直接（也就是，本機支持的） 對象。它生成以下輸出：$ ./run_directbytebuffer_demo_aix_32.shAllocated 2652372992 bytes of native memory before running outJVMDUMP006I Processing Dump Event

53、 "systhrow", detail "java/lang/OutOfMemoryError" - Please Wait.JVMDUMP007I JVM Requesting Snap Dump using '/u2/andhall/aix_samples_pack/OutOfNativeBehaviour/Snap.20081207.105307.610498.0001.trc'JVMDUMP010I Snap Dump written to /u2/andhall/aix_samples_pack/OutOfNativeBehav

54、iour/Snap.20081207.105307.610498.0001.trcJVMDUMP007I JVM Requesting Heap Dump using '/u2/andhall/aix_samples_pack/OutOfNativeBehaviour/heapdump.20081207.105307.610498.0002.phd'JVMDUMP010I Heap Dump written to /u2/andhall/aix_samples_pack/OutOfNativeBehaviour/heapdump.20081207.105307.610498.0

55、002.phdJVMDUMP007I JVM Requesting Java Dump using '/u2/andhall/aix_samples_pack/OutOfNativeBehaviour/javacore.20081207.105307.610498.0003.txt'JVMDUMP010I Java Dump written to /u2/andhall/aix_samples_pack/OutOfNativeBehaviour/javacore.20081207.105307.610498.0003.txtJVMDUMP013I Processed Dump

56、Event "systhrow", detail "java/lang/OutOfMemoryError".JVMDUMP006I Processing Dump Event "systhrow", detail "java/lang/OutOfMemoryError" - Please Wait.JVMDUMP007I JVM Requesting Snap Dump using '/u2/andhall/aix_samples_pack/OutOfNativeBehaviour/Snap.2008120

57、7.105308.610498.0004.trc'JVMDUMP010I Snap Dump written to /u2/andhall/aix_samples_pack/OutOfNativeBehaviour/Snap.20081207.105308.610498.0004.trcJVMDUMP007I JVM Requesting Heap Dump using '/u2/andhall/aix_samples_pack/OutOfNativeBehaviour/heapdump.20081207.105308.610498.0005.phd'JVMDUMP010I Heap Dump written to /u2/andhall/aix_samples_pack/OutOfNativeBehaviour/heapdump.20081207.105308.610498.0005.phdJVMDUMP007I JVM Requesting Java Dump using '/u2/andhall/aix_samples_pack/OutOfNativeBehaviour/javacore.20081207.105308.610498.0006.txt'UTE430: can't allocate bufferUTE4