javaStack

⑴ java中堆和堆棧有什麼區別

java中堆（heap)和堆棧（stack)有什麼區別 stack 和 heep 都是內存的一部分
stack 空間小，速度比較快， 用來放對象的引用
heep 大，一般所有創建的對象都放在這里。

棧(stack):是一個先進後出的數據結構,通常用於保存方法(函數)中的參數,局部變數.
在java中,所有基本類型和引用類型都在棧中存儲.棧中數據的生存空間一般在當前scopes內(就是由{...}括起來的區域).
堆(heap):是一個可動態申請的內存空間(其記錄空閑內存空間的鏈表由操作系統維護),C中的malloc語句所產生的內存空間就在堆中.
在java中,所有使用new xxx()構造出來的對象都在堆中存儲,當垃圾回收器檢測到某對象未被引用,則自動銷毀該對象.所以,理論上說java中對象的生存空間是沒有限制的,只要有引用類型指向它,則它就可以在任意地方被使用.

1. 棧(stack)與堆(heap)都是Java用來在Ram中存放數據的地方。與C++不同，Java自動管理棧和堆，程序員不能直接地設置棧或堆。
2. 棧的優勢是，存取速度比堆要快，僅次於直接位於CPU中的寄存器。但缺點是，存在棧中的數據大小與生存期必須是確定的，缺乏靈活性。另外，棧數據可以共享，詳見第3點。堆的優勢是可以動態地分配內存大小，生存期也不必事先告訴編譯器，Java的垃圾收集器會自動收走這些不再使用的數據。但缺點是，由於要在運行時動態分配內存，存取速度較慢。
3. Java中的數據類型有兩種。
一種是基本類型(primitive types), 共有8種，即int, short, long, byte, float, double, boolean, char(注意，並沒有string的基本類型)。 這種類型的定義是通過諸如int a = 3; long b = 255L;的形式來定義的，稱為自動變數。值得注意的是，自動變數存的是字面值，不是類的實例，即不是類的引用，這里並沒有類的存在。如int a = 3; 這里的a是一個指向int類型的引用，指向3這個字面值。這些字面值的數據，由於大小可知，生存期可知(這些字面值固定定義在某個程序塊裡面，程序塊退出後，欄位值就消失了)，出於追求速度的原因，就存在於棧中。
另外，棧有一個很重要的特殊性，就是存在棧中的數據可以共享。假設我們同時定義：
int a = 3;
int b = 3；
編譯器先處理int a = 3；首先它會在棧中創建一個變數為a的引用，然後查找有沒有字面值為3的地址，沒找到，就開辟一個存放3這個字面值的地址，然後將a指向3的地址。接著處理int b = 3；在創建完b的引用變數後，由於在棧中已經有3這個字面值，便將b直接指向3的地址。
這樣，就出現了a與b同時均指向3的情況。特別注意的是，這種字面值的引用與類對象的引用不同。
假定兩個類對象的引用同時指向一個對象，如果一個對象引用變數修改了這個對象的內部狀態，那麼另一個對象引用變數也即刻反映出這個變化。
相反，通過字面值的引用來修改其值，不會導致另一個指向此字面值的引用的值也跟著改變的情況。 如上例，我們定義完a與b的值後，再令a=4；那麼，b不會等於4，還是等於3。在編譯器內部，遇到a=4；時，它就會重新搜索棧中是否有4的字面值，如果沒有，重新開闢地址存放4的值；如果已經有了，則直接將a指向這個地址。因此a值的改變不會影響到b的值。
另一種是包裝類數據，如Integer, String, Double等將相應的基本數據類型包裝起來的類。這些類數據全部存在於堆中，Java用new()語句來顯示地告訴編譯器，在運行時才根據需要動態創建，因此比較靈活，但缺點是要佔用更多的時間。
4.String是一個特殊的包裝類數據。即可以用String str = new String("abc");的形式來創建，也可以用String str = "abc"；的形式來創建(作為對比，在JDK 5.0之前，你從未見過Integer i = 3;的表達式，因為類與字面值是不能通用的，除了String。而在JDK 5.0中，這種表達式是可以的！因為編譯器在後台進行Integer i = new Integer(3)的轉換！)。
前者是規范的類的創建過程，即在Java中，一切都是對象，而對象是類的實例，全部通過new()的形式來創建。Java中的有些類，如DateFormat類，可以通過該類的getInstance()方法來返回一個新創建的類，似乎違反了此原則。其實不然。該類運用了單例模式來返回類的實例，只不過這個實例是在該類內部通過new()來創建的，而getInstance()向外部隱藏了此細節。那為什麼在String str = "abc"；中，並沒有通過new()來創建實例，是不是違反了上述原則？其實沒有。

⑵ java語言中提及的「堆」主要有什麼用「棧又有什麼用」

Java把內存劃分成兩種：一種是棧內存，另一種是堆內存。在函數中定義的一些基本類型的變數和對象的引用變數都是在函數的棧內存中分配，當在一段代碼塊定義一個變數時，Java就在棧中為這個變數分配內存空間，當超過變數的作用域後，Java 會自動釋放掉為該變數分配的內存空間，該內存空間可以立即被另作它用。

堆內存用來存放由 new 創建的對象和數組，在堆中分配的內存，由 Java 虛擬機的自動垃圾回收器來管理。在堆中產生了一個數組或者對象之後，還可以在棧中定義一個特殊的變數，讓棧中的這個變數的取值等於數組或對象在堆內存中的首地址，棧中的這個變數就成了數組或對象的引用變數，以後就可以在程序中使用棧中的引用變數來訪問堆中的數組或者對象，引用變數就相當於是為數組或者對象起的一個名稱。引用變數是普通的變數，定義時在棧中分配，引用變數在程序運行到其作用域之外後被釋放。而數組和對象本身在堆中分配，即使程序運行到使用 new 產生數組或者對象的語句所在的代碼塊之外，數組和對象本身占據的內存不會被釋放，數組和對象在沒有引用變數指向它的時候，才變為垃圾，不能在被使用，但仍然占據內存空間不放，在隨後的一個不確定的時間被垃圾回收器收走(釋放掉)。

這也是Java比較占內存的原因，實際上，棧中的變數指向堆內存中的變數，這就是 Java 中的指針!

java中內存分配策略及堆和棧的比較

1 內存分配策略

按照編譯原理的觀點,程序運行時的內存分配有三種策略,分別是靜態的,棧式的,和堆式的.

靜態存儲分配是指在編譯時就能確定每個數據目標在運行時刻的存儲空間需求,因而在編譯時就可以給他們分配固定的內存空間.這種分配策略要求程序代碼中不允許有可變數據結構(比如可變數組)的存在,也不允許有嵌套或者遞歸的結構出現,因為它們都會導致編譯程序無法計算準確的存儲空間需求.

棧式存儲分配也可稱為動態存儲分配,是由一個類似於堆棧的運行棧來實現的.和靜態存儲分配相反,在棧式存儲方案中,程序對數據區的需求在編譯時是完全未知的,只有到運行的時候才能夠知道,但是規定在運行中進入一個程序模塊時,必須知道該程序模塊所需的數據區大小才能夠為其分配內存.和我們在數據結構所熟知的棧一樣,棧式存儲分配按照先進後出的原則進行分配。

靜態存儲分配要求在編譯時能知道所有變數的存儲要求,棧式存儲分配要求在過程的入口處必須知道所有的存儲要求,而堆式存儲分配則專門負責在編譯時或運行時模塊入口處都無法確定存儲要求的數據結構的內存分配,比如可變長度串和對象實例.堆由大片的可利用塊或空閑塊組成,堆中的內存可以按照任意順序分配和釋放.

2 堆和棧的比較

上面的定義從編譯原理的教材中總結而來,除靜態存儲分配之外,都顯得很呆板和難以理解,下面撇開靜態存儲分配,集中比較堆和棧:

從堆和棧的功能和作用來通俗的比較,堆主要用來存放對象的，棧主要是用來執行程序的.而這種不同又主要是由於堆和棧的特點決定的:

在編程中，例如C/C++中，所有的方法調用都是通過棧來進行的,所有的局部變數,形式參數都是從棧中分配內存空間的。實際上也不是什麼分配,只是從棧頂向上用就行,就好像工廠中的傳送帶(conveyor belt)一樣,Stack Pointer會自動指引你到放東西的位置,你所要做的只是把東西放下來就行.退出函數的時候，修改棧指針就可以把棧中的內容銷毀.這樣的模式速度最快, 當然要用來運行程序了.需要注意的是,在分配的時候,比如為一個即將要調用的程序模塊分配數據區時,應事先知道這個數據區的大小,也就說是雖然分配是在程序運行時進行的,但是分配的大小多少是確定的,不變的,而這個"大小多少"是在編譯時確定的,不是在運行時.

堆是應用程序在運行的時候請求操作系統分配給自己內存，由於從操作系統管理的內存分配,所以在分配和銷毀時都要佔用時間，因此用堆的效率非常低.但是堆的優點在於,編譯器不必知道要從堆里分配多少存儲空間，也不必知道存儲的數據要在堆里停留多長的時間,因此,用堆保存數據時會得到更大的靈活性。事實上,面向對象的多態性,堆內存分配是必不可少的,因為多態變數所需的存儲空間只有在運行時創建了對象之後才能確定.在C++中，要求創建一個對象時，只需用 new命令編制相關的代碼即可。執行這些代碼時，會在堆里自動進行數據的保存.當然，為達到這種靈活性，必然會付出一定的代價:在堆里分配存儲空間時會花掉更長的時間!這也正是導致我們剛才所說的效率低的原因,看來列寧同志說的好,人的優點往往也是人的缺點,人的缺點往往也是人的優點(暈~).

3 JVM中的堆和棧

JVM是基於堆棧的虛擬機.JVM為每個新創建的線程都分配一個堆棧.也就是說,對於一個Java程序來說，它的運行就是通過對堆棧的操作來完成的。堆棧以幀為單位保存線程的狀態。JVM對堆棧只進行兩種操作:以幀為單位的壓棧和出棧操作。

我們知道,某個線程正在執行的方法稱為此線程的當前方法.我們可能不知道,當前方法使用的幀稱為當前幀。當線程激活一個Java方法,JVM就會在線程的 Java堆棧里新壓入一個幀。這個幀自然成為了當前幀.在此方法執行期間,這個幀將用來保存參數,局部變數,中間計算過程和其他數據.這個幀在這里和編譯原理中的活動紀錄的概念是差不多的.

從Java的這種分配機制來看,堆棧又可以這樣理解:堆棧(Stack)是操作系統在建立某個進程時或者線程(在支持多線程的操作系統中是線程)為這個線程建立的存儲區域，該區域具有先進後出的特性。

每一個Java應用都唯一對應一個JVM實例，每一個實例唯一對應一個堆。應用程序在運行中所創建的所有類實例或數組都放在這個堆中,並由應用所有的線程共享.跟C/C++不同，Java中分配堆內存是自動初始化的。Java中所有對象的存儲空間都是在堆中分配的，但是這個對象的引用卻是在堆棧中分配,也就是說在建立一個對象時從兩個地方都分配內存，在堆中分配的內存實際建立這個對象，而在堆棧中分配的內存只是一個指向這個堆對象的指針(引用)而已。

Java 中的堆和棧

Java把內存劃分成兩種：一種是棧內存，一種是堆內存。

在函數中定義的一些基本類型的變數和對象的引用變數都在函數的棧內存中分配。

當在一段代碼塊定義一個變數時，Java就在棧中為這個變數分配內存空間，當超過變數的作用域後，Java會自動釋放掉為該變數所分配的內存空間，該內存空間可以立即被另作他用。

堆內存用來存放由new創建的對象和數組。

在堆中分配的內存，由Java虛擬機的自動垃圾回收器來管理。

在堆中產生了一個數組或對象後，還可以在棧中定義一個特殊的變數，讓棧中這個變數的取值等於數組或對象在堆內存中的首地址，棧中的這個變數就成了數組或對象的引用變數。

引用變數就相當於是為數組或對象起的一個名稱，以後就可以在程序中使用棧中的引用變數來訪問堆中的數組或對象。

具體的說：

棧與堆都是Java用來在Ram中存放數據的地方。與C++不同，Java自動管理棧和堆，程序員不能直接地設置棧或堆。

Java的堆是一個運行時數據區,類的(對象從中分配空間。這些對象通過new、newarray、anewarray和multianewarray等指令建立，它們不需要程序代碼來顯式的釋放。堆是由垃圾回收來負責的，堆的優勢是可以動態地分配內存大小，生存期也不必事先告訴編譯器，因為它是在運行時動態分配內存的，Java的垃圾收集器會自動收走這些不再使用的數據。但缺點是，由於要在運行時動態分配內存，存取速度較慢。

棧的優勢是，存取速度比堆要快，僅次於寄存器，棧數據可以共享。但缺點是，存在棧中的數據大小與生存期必須是確定的，缺乏靈活性。棧中主要存放一些基本類型的變數(,int, short, long, byte, float, double, boolean, char)和對象句柄。

棧有一個很重要的特殊性，就是存在棧中的數據可以共享。假設我們同時定義：

int a = 3;

int b = 3;

編譯器先處理int a = 3;首先它會在棧中創建一個變數為a的引用，然後查找棧中是否有3這個值，如果沒找到，就將3存放進來，然後將a指向3。接著處理int b = 3;在創建完b的引用變數後，因為在棧中已經有3這個值，便將b直接指向3。這樣，就出現了a與b同時均指向3的情況。這時，如果再令a=4;那麼編譯器會重新搜索棧中是否有4值，如果沒有，則將4存放進來，並令a指向4;如果已經有了，則直接將a指向這個地址。因此a值的改變不會影響到b的值。要注意這種數據的共享與兩個對象的引用同時指向一個對象的這種共享是不同的，因為這種情況a的修改並不會影響到b, 它是由編譯器完成的，它有利於節省空間。而一個對象引用變數修改了這個對象的內部狀態，會影響到另一個對象引用變數。

⑶ Java集合詳解1：ArrayList,Vector與Stack

本文深入探討了Java集合類中的三個主要實例：ArrayList、Vector和Stack。它們在存儲和組織數據方面扮演著關鍵角色，尤其在實現列表操作時提供了靈活性和效率。下面，我們將詳細解析這些集合類的特性、底層實現以及性能考量。

ArrayList作為動態數組的實現，提供了一系列操作來存儲和管理數據。其核心特點在於可變的容量，通過內部數組來存儲元素，初始容量為10，並隨添加元素自動擴展。擴容時，ArrayList採用線性增長策略，將容量增加為原有容量的1.5倍。這種策略在確保性能的同時，避免了過度分配導致的內存浪費。確保容量增長的同時，通過調用ensureCapacity方法預先增加容量，可以減少多次擴容帶來的性能開銷。值得注意的是，ArrayList不是線程安全的，因此在多線程環境下訪問或修改列表時需要外部同步。

Vector則提供了一種同步的、可動態擴展的數組實現。它不僅繼承自AbstractList，還實現了RandomAccess介面，支持快速隨機訪問。Vector的擴容機制與ArrayList類似，但採用了增長因子策略來調整容量，增長因子的設定決定了每次擴容時容量的增量。此外，Vector在序列化時會復制整個數組，與ArrayList不同。Vector同樣不是線程安全的，但在內部通過同步機制確保了對Vector的並發訪問安全。

Stack類則基於Vector擴展，專為後進先出（LIFO）操作而設計。它通過一系列方法如empty()、peek()、pop()和push()提供了堆棧功能的實現。Stack繼承Vector的特性，通過簡單構造方法和方法實現提供了堆棧功能，但其源碼並未詳細展開。

在比較這三個集合類時，我們可以總結出以下關鍵區別：
1. **線程安全性**：ArrayList為非線程安全集合，而Vector提供了線程安全保證。
2. **性能**：ArrayList在隨機訪問和順序添加時表現出色，但刪除操作可能導致性能開銷；Vector和Stack在這些方面與ArrayList類似，但Vector提供了額外的同步機制。
3. **容量管理**：ArrayList採用1.5倍的線性增長策略，而Vector通過增長因子進行容量調整。
4. **同步機制**：Vector通過同步機制確保多線程環境下的安全性，而ArrayList需要外部同步來避免並發問題。

綜上所述，選擇哪個集合類取決於特定的應用需求。對於要求線程安全、頻繁隨機訪問或需要更靈活容量管理的應用場景，Vector可能更為合適。而對於性能敏感且不需要線程安全的應用，ArrayList提供了高效且簡單的數據存儲解決方案。Stack則專用於實現棧結構的特定應用需求。在實際開發中，應根據具體場景選擇最適合的集合類以實現最優性能和資源利用。

⑷ 如何理解Java虛擬機棧

堆是堆（heap），棧是棧（stack），堆棧是棧。

棧中分配的是基本類型和自定義對象的引用。

堆中分配的是對象，也就是new出來的東西。 被所有線程共享。

方法區/靜態區 存放的是類信息和static變數、常量。 被所有線程共享。

也可以這么理解：堆是用來存放對象的，棧是用來運行程序的。

堆：java的垃圾回收器會自動的回收這些不用的數據。缺點是由於要動態的分配內存，存儲效率會比較的慢。

棧：棧的優勢是存取效率比較快，僅次於寄存器，棧數據可以共享。但缺點是棧中的數據大小和生存期的固定的，缺乏靈活性。

一般每個方法的調用都會獨立有一個棧來保存對象的引用變數，在方法返回後，棧會清空，當在一段代碼塊定義一個變數時，Java就在棧中為這個變數分配內存空間，當超過變數的作用域後，Java會自動釋放掉為該變數所分配的內存空間，該內存空間可以立即被另作他用。

以32位地址操作系統為例，一個進程可擁有的虛擬內存地址范圍為0-2^32。分為兩部分，一部分留給kernel使用(kernel virtual memory)，剩下的是進程本身使用， 即圖中的process virtual memory。

一個程序本質上都是由bss段、data段、text段三個組成的

bss段（Block Started by Symbol segment）通常是指用來存放程序中未初始化的全局變數的一塊內存區域，一般在初始化時bss 段部分將會清零。bss段屬於靜態內存分配，即程序一開始就將其清零了。

在C語言之類的程序編譯完成之後，已初始化的全局變數保存在.data 段中，未初始化的全局變數保存在.bss 段中。

text和data段都在可執行文件中（在嵌入式系統里一般是固化在鏡像文件中），由系統從可執行文件中載入；而bss段不在可執行文件中，由系統初始化。

⑸ JAVA中隊列和棧的區別

隊列(Queue)：是限定只能在表的一端進行插入和在另一端進行刪除操作的線性表;

棧(Stack)：是限定只能在表的一端進行插入和刪除操作的線性表。

區別如下：

一、規則不同

1. 隊列：先進先出(First In First Out)FIFO

2. 棧：先進後出(First In Last Out )FILO

二、對插入和刪除操作的限定不同

1. 隊列：只能在表的一端進行插入，並在表的另一端進行刪除;

2. 棧：只能在表的一端插入和刪除。

三、遍歷數據速度不同

1.
隊列：基於地址指針進行遍歷，而且可以從頭部或者尾部進行遍歷，但不能同時遍歷，無需開辟空間，因為在遍歷的過程中不影響數據結構，所以遍歷速度要快;

2.
棧：只能從頂部取數據，也就是說最先進入棧底的，需要遍歷整個棧才能取出來，而且在遍歷數據的同時需要為數據開辟臨時空間，保持數據在遍歷前的一致性。

⑹ java涓鐨勫爢鏍堥棶棰橈紵

鍏跺疄榪欎簺鍩虹鐨勪笢瑗跨綉涓婃湁涓嶅皯, 浣犲彲浠ュ氬幓csdn,閭ｉ噷鍙浠ュ﹀埌涓嶅皯濂戒笢瑗 ,鎴戝氨鐩存帴緇欎綘綺樿創榪囨潵浜
java涓鍫嗘爤(stack)鍜屽爢(heap)
涓銆佸爢鏍(stack)鍜屽爢(heap)錛
錛1錛夊唴瀛樺垎閰嶇殑絳栫暐
銆銆鎸夌収緙栬瘧鍘熺悊鐨勮傜偣,紼嬪簭榪愯屾椂鐨勫唴瀛樺垎閰嶆湁涓夌嶇瓥鐣,鍒嗗埆鏄闈欐佺殑,鏍堝紡鐨,鍜屽爢寮忕殑.

銆闈欐佸瓨鍌ㄥ垎閰嶆槸鎸囧湪緙栬瘧鏃跺氨鑳界『瀹氭瘡涓鏁版嵁鐩鏍囧湪榪愯屾椂鍒葷殑瀛樺偍絀洪棿闇奼,鍥犺屽湪緙栬瘧鏃跺氨鍙浠ョ粰浠栦滑鍒嗛厤鍥哄畾鐨勫唴瀛樼┖闂.榪欑嶅垎閰嶇瓥鐣ヨ佹眰紼嬪簭浠ｇ爜涓涓嶅厑璁告湁鍙鍙樻暟鎹緇撴瀯(姣斿傚彲鍙樻暟緇)鐨勫瓨鍦,涔熶笉鍏佽告湁宓屽楁垨鑰呴掑綊鐨勭粨鏋勫嚭鐜,鍥犱負瀹冧滑閮戒細瀵艱嚧緙栬瘧紼嬪簭鏃犳硶璁＄畻鍑嗙『鐨勫瓨鍌ㄧ┖闂撮渶奼.

銆鏍堝紡瀛樺偍鍒嗛厤涔熷彲縐頒負鍔ㄦ佸瓨鍌ㄥ垎閰,鏄鐢變竴涓綾諱技浜庡爢鏍堢殑榪愯屾爤鏉ュ疄鐜扮殑.鍜岄潤鎬佸瓨鍌ㄥ垎閰嶇浉鍙,鍦ㄦ爤寮忓瓨鍌ㄦ柟妗堜腑,紼嬪簭瀵規暟鎹鍖虹殑闇奼傚湪緙栬瘧鏃舵槸瀹屽叏鏈鐭ョ殑,鍙鏈夊埌榪愯岀殑鏃跺欐墠鑳藉熺煡閬,浣嗘槸瑙勫畾鍦ㄨ繍琛屼腑榪涘叆涓涓紼嬪簭妯″潡鏃,蹇呴』鐭ラ亾璇ョ▼搴忔ā鍧楁墍闇鐨勬暟鎹鍖哄ぇ灝忔墠鑳藉熶負鍏跺垎閰嶅唴瀛.鍜屾垜浠鍦ㄦ暟鎹緇撴瀯鎵鐔熺煡鐨勬爤涓鏍,鏍堝紡瀛樺偍鍒嗛厤鎸夌収鍏堣繘鍚庡嚭鐨勫師鍒欒繘琛屽垎閰嶃

銆闈欐佸瓨鍌ㄥ垎閰嶈佹眰鍦ㄧ紪璇戞椂鑳界煡閬撴墍鏈夊彉閲忕殑瀛樺偍瑕佹眰,鏍堝紡瀛樺偍鍒嗛厤瑕佹眰鍦ㄨ繃紼嬬殑鍏ュ彛澶勫繀欏葷煡閬撴墍鏈夌殑瀛樺偍瑕佹眰,鑰屽爢寮忓瓨鍌ㄥ垎閰嶅垯涓撻棬璐熻矗鍦ㄧ紪璇戞椂鎴栬繍琛屾椂妯″潡鍏ュ彛澶勯兘鏃犳硶紜瀹氬瓨鍌ㄨ佹眰鐨勬暟鎹緇撴瀯鐨勫唴瀛樺垎閰,姣斿傚彲鍙橀暱搴︿覆鍜屽硅薄瀹炰緥.鍫嗙敱澶х墖鐨勫彲鍒╃敤鍧楁垨絀洪棽鍧楃粍鎴,鍫嗕腑鐨勫唴瀛樺彲浠ユ寜鐓т換鎰忛『搴忓垎閰嶅拰閲婃斁.
錛2錛夊爢鍜屾爤鐨勬瘮杈
銆銆涓婇潰鐨勫畾涔変粠緙栬瘧鍘熺悊鐨勬暀鏉愪腑鎬葷粨鑰屾潵,闄ら潤鎬佸瓨鍌ㄥ垎閰嶄箣澶,閮芥樉寰楀緢鍛嗘澘鍜岄毦浠ョ悊瑙,涓嬮潰鎾囧紑闈欐佸瓨鍌ㄥ垎閰,闆嗕腑姣旇緝鍫嗗拰鏍:

銆浠庡爢鍜屾爤鐨勫姛鑳藉拰浣滅敤鏉ラ氫織鐨勬瘮杈,鍫嗕富瑕佺敤鏉ュ瓨鏀懼硅薄鐨勶紝鏍堜富瑕佹槸鐢ㄦ潵鎵ц岀▼搴忕殑.鑰岃繖縐嶄笉鍚屽張涓昏佹槸鐢變簬鍫嗗拰鏍堢殑鐗圭偣鍐沖畾鐨:

銆鍦ㄧ紪紼嬩腑錛屼緥濡侰/C++涓錛屾墍鏈夌殑鏂規硶璋冪敤閮芥槸閫氳繃鏍堟潵榪涜岀殑,鎵鏈夌殑灞閮ㄥ彉閲,褰㈠紡鍙傛暟閮芥槸浠庢爤涓鍒嗛厤鍐呭瓨絀洪棿鐨勩傚疄闄呬笂涔熶笉鏄浠涔堝垎閰,鍙鏄浠庢爤欏跺悜涓婄敤灝辮,灝卞ソ鍍忓伐鍘備腑鐨勪紶閫佸甫(conveyor belt)涓鏍,Stack Pointer浼氳嚜鍔ㄦ寚寮曚綘鍒版斁涓滆タ鐨勪綅緗,浣犳墍瑕佸仛鐨勫彧鏄鎶婁笢瑗挎斁涓嬫潵灝辮.閫鍑哄嚱鏁扮殑鏃跺欙紝淇鏀規爤鎸囬拡灝卞彲浠ユ妸鏍堜腑鐨勫唴瀹歸攢姣.榪欐牱鐨勬ā寮忛熷害鏈蹇,褰撶劧瑕佺敤鏉ヨ繍琛岀▼搴忎簡.闇瑕佹敞鎰忕殑鏄,鍦ㄥ垎閰嶇殑鏃跺,姣斿備負涓涓鍗沖皢瑕佽皟鐢ㄧ殑紼嬪簭妯″潡鍒嗛厤鏁版嵁鍖烘椂,搴斾簨鍏堢煡閬撹繖涓鏁版嵁鍖虹殑澶у皬,涔熷氨璇存槸鉶界劧鍒嗛厤鏄鍦ㄧ▼搴忚繍琛屾椂榪涜岀殑,浣嗘槸鍒嗛厤鐨勫ぇ灝忓氬皯鏄紜瀹氱殑,涓嶅彉鐨,鑰岃繖涓"澶у皬澶氬皯"鏄鍦ㄧ紪璇戞椂紜瀹氱殑,涓嶆槸鍦ㄨ繍琛屾椂.

銆 鍫嗘槸搴旂敤紼嬪簭鍦ㄨ繍琛岀殑鏃跺欒鋒眰鎿嶄綔緋葷粺鍒嗛厤緇欒嚜宸卞唴瀛橈紝鐢變簬浠庢搷浣滅郴緇熺＄悊鐨勫唴瀛樺垎閰,鎵浠ュ湪鍒嗛厤鍜岄攢姣佹椂閮借佸崰鐢ㄦ椂闂達紝鍥犳ょ敤鍫嗙殑鏁堢巼闈炲父浣.浣嗘槸鍫嗙殑浼樼偣鍦ㄤ簬,緙栬瘧鍣ㄤ笉蹇呯煡閬撹佷粠鍫嗛噷鍒嗛厤澶氬皯瀛樺偍絀洪棿錛屼篃涓嶅繀鐭ラ亾瀛樺偍鐨勬暟鎹瑕佸湪鍫嗛噷鍋滅暀澶氶暱鐨勬椂闂,鍥犳,鐢ㄥ爢淇濆瓨鏁版嵁鏃朵細寰楀埌鏇村ぇ鐨勭伒媧繪с備簨瀹炰笂,闈㈠悜瀵硅薄鐨勫氭佹,鍫嗗唴瀛樺垎閰嶆槸蹇呬笉鍙灝戠殑,鍥犱負澶氭佸彉閲忔墍闇鐨勫瓨鍌ㄧ┖闂村彧鏈夊湪榪愯屾椂鍒涘緩浜嗗硅薄涔嬪悗鎵嶈兘紜瀹.鍦–++涓錛岃佹眰鍒涘緩涓涓瀵硅薄鏃訛紝鍙闇鐢╪ew鍛戒護緙栧埗鐩稿叧鐨勪唬鐮佸嵆鍙銆傛墽琛岃繖浜涗唬鐮佹椂錛屼細鍦ㄥ爢閲岃嚜鍔ㄨ繘琛屾暟鎹鐨勪繚瀛.褰撶劧錛屼負杈懼埌榪欑嶇伒媧繪э紝蹇呯劧浼氫粯鍑轟竴瀹氱殑浠ｄ環:鍦ㄥ爢閲屽垎閰嶅瓨鍌ㄧ┖闂存椂浼氳姳鎺夋洿闀跨殑鏃墮棿錛佽繖涔熸ｆ槸瀵艱嚧鎴戜滑鍒氭墠鎵璇寸殑鏁堢巼浣庣殑鍘熷洜,鐪嬫潵鍒楀畞鍚屽織璇寸殑濂,浜虹殑浼樼偣寰寰涔熸槸浜虹殑緙虹偣,浜虹殑緙虹偣寰寰涔熸槸浜虹殑浼樼偣(鏅晘).
錛3錛塉VM涓鐨勫爢鍜屾爤
銆銆JVM鏄鍩轟簬鍫嗘爤鐨勮櫄鎷熸満.JVM涓烘瘡涓鏂板壋寤虹殑綰跨▼閮藉垎閰嶄竴涓鍫嗘爤.涔熷氨鏄璇,瀵逛簬涓涓狫ava紼嬪簭鏉ヨ達紝瀹冪殑榪愯屽氨鏄閫氳繃瀵瑰爢鏍堢殑鎿嶄綔鏉ュ畬鎴愮殑銆傚爢鏍堜互甯т負鍗曚綅淇濆瓨綰跨▼鐨勭姸鎬併侸VM瀵瑰爢鏍堝彧榪涜屼袱縐嶆搷浣:浠ュ撫涓哄崟浣嶇殑鍘嬫爤鍜屽嚭鏍堟搷浣溿

銆銆 鎴戜滑鐭ラ亾,鏌愪釜綰跨▼姝ｅ湪鎵ц岀殑鏂規硶縐頒負姝ょ嚎紼嬬殑褰撳墠鏂規硶.鎴戜滑鍙鑳戒笉鐭ラ亾,褰撳墠鏂規硶浣跨敤鐨勫撫縐頒負褰撳墠甯с傚綋綰跨▼嬋媧諱竴涓狫ava鏂規硶,JVM灝變細鍦ㄧ嚎紼嬬殑Java鍫嗘爤閲屾柊鍘嬪叆涓涓甯с傝繖涓甯ц嚜鐒舵垚涓轟簡褰撳墠甯.鍦ㄦゆ柟娉曟墽琛屾湡闂,榪欎釜甯у皢鐢ㄦ潵淇濆瓨鍙傛暟,灞閮ㄥ彉閲,涓闂磋＄畻榪囩▼鍜屽叾浠栨暟鎹.榪欎釜甯у湪榪欓噷鍜岀紪璇戝師鐞嗕腑鐨勬椿鍔ㄧ邯褰曠殑姒傚康鏄宸涓嶅氱殑.

銆銆 浠嶫ava鐨勮繖縐嶅垎閰嶆満鍒舵潵鐪,鍫嗘爤鍙堝彲浠ヨ繖鏍風悊瑙:鍫嗘爤(Stack)鏄鎿嶄綔緋葷粺鍦ㄥ緩絝嬫煇涓榪涚▼鏃舵垨鑰呯嚎紼(鍦ㄦ敮鎸佸氱嚎紼嬬殑鎿嶄綔緋葷粺涓鏄綰跨▼)涓鴻繖涓綰跨▼寤虹珛鐨勫瓨鍌ㄥ尯鍩燂紝璇ュ尯鍩熷叿鏈夊厛榪涘悗鍑虹殑鐗規с

銆 姣忎竴涓狫ava搴旂敤閮藉敮涓瀵瑰簲涓涓狫VM瀹炰緥錛屾瘡涓涓瀹炰緥鍞涓瀵瑰簲涓涓鍫嗐傚簲鐢ㄧ▼搴忓湪榪愯屼腑鎵鍒涘緩鐨勬墍鏈夌被瀹炰緥鎴栨暟緇勯兘鏀懼湪榪欎釜鍫嗕腑,騫剁敱搴旂敤鎵鏈夌殑綰跨▼鍏變韓.璺烠/C++涓嶅悓錛孞ava涓鍒嗛厤鍫嗗唴瀛樻槸鑷鍔ㄥ垵濮嬪寲鐨勩侸ava涓鎵鏈夊硅薄鐨勫瓨鍌ㄧ┖闂撮兘鏄鍦ㄥ爢涓鍒嗛厤鐨勶紝浣嗘槸榪欎釜瀵硅薄鐨勫紩鐢ㄥ嵈鏄鍦ㄥ爢鏍堜腑鍒嗛厤,涔熷氨鏄璇村湪寤虹珛涓涓瀵硅薄鏃朵粠涓や釜鍦版柟閮藉垎閰嶅唴瀛橈紝鍦ㄥ爢涓鍒嗛厤鐨勫唴瀛樺疄闄呭緩絝嬭繖涓瀵硅薄錛岃屽湪鍫嗘爤涓鍒嗛厤鐨勫唴瀛樺彧鏄涓涓鎸囧悜榪欎釜鍫嗗硅薄鐨勬寚閽(寮曠敤)鑰屽凡銆