java棧多大內存

❶ java 每個函數的棧空間大小是

在Java程序運行時，各個棧空間大小如下：
(1) 寄存器。最快的保存區域，位於處理器內部,數量十分有限，它是根據需要由編譯器分配。我們對此沒有直接的控制權.
(2) 棧(stack)。駐留於常規RAM（隨機訪問存儲器）區域，這是一種特別快、特別有效的數據保存方式，僅次於寄存器。創建程序時，Java編譯器必須准確地知道堆棧內保存的所有數據的「長度」以及「存在時間」。這失去了一定的靈活性，因此對象句柄是存放在棧中，但Java對象並不放到其中。
(3) 堆(heap)。保存了Java對象。和棧不同，它最吸引人的地方在於編譯器不必知道要從堆里分配多少存儲空間，也不必知道存儲的數據要在堆里停留多長的時間。因此，用堆保存數據時會得到更大的靈活性。要求創建一個對象時，只需用new命令編制相關的代碼即可。執行這些代碼時，會在堆里自動進行數據的保存。當然，為達到這種靈活性，必然會付出一定的代價：在堆里分配存儲空間時會花掉更長的時間！
(4) 靜態存儲。這兒的「靜態」（Static）是指「位於固定位置」（盡管也在RAM里）。程序運行期間，靜態存儲的數據將隨時等候調用。可用static關鍵字指出一個對象的特定元素是靜態的。但Java對象本身永遠都不會置入靜態存儲空間。
(5) 常數存儲。常數值通常直接置於程序代碼內部。這樣做是安全的，因為它們永遠都不會改變。有的常數需要嚴格地保護，所以可考慮將它們置入只讀存儲器（ROM）。
(6) 非RAM存儲。數據完全獨立於一個程序之外，則程序不運行時仍可存在，並在程序的控制范圍之外。

❷ Java循環創建多個對象後導致內存溢出！

在解決java內存溢出問題之前，需要對jvm（java虛擬機）的內存管理有一定的認識。jvm管理的內存大致包括三種不同類型的內存區域：Permanent Generation space（永久保存區域）、Heap space(堆區域)、Java Stacks(Java棧）。其中永久保存區域主要存放Class（類）和Meta的信息，Class第一次被Load的時候被放入PermGen space區域，Class需要存儲的內容主要包括方法和靜態屬性。堆區域用來存放Class的實例（即對象），對象需要存儲的內容主要是非靜態屬性。每次用new創建一個對象實例後，對象實例存儲在堆區域中，這部分空間也被jvm的垃圾回收機制管理。而Java棧跟大多數編程語言包括匯編語言的棧功能相似，主要基本類型變數以及方法的輸入輸出參數。Java程序的每個線程中都有一個獨立的堆棧。容易發生內存溢出問題的內存空間包括：Permanent Generation space和Heap space。
第一種OutOfMemoryError： PermGen space
發生這種問題的原意是程序中使用了大量的jar或class，使java虛擬機裝載類的空間不夠，與Permanent Generation space有關。解決這類問題有以下兩種辦法：
增加java虛擬機中的XX:PermSize和XX:MaxPermSize參數的大小，其中XX:PermSize是初始永久保存區域大小，XX:MaxPermSize是最大永久保存區域大小。如針對tomcat6.0，在catalina.sh 或catalina.bat文件中一系列環境變數名說明結束處（大約在70行左右） 增加一行： JAVA_OPTS=" -XX:PermSize=64M -XX:MaxPermSize=128m" 如果是windows伺服器還可以在系統環境變數中設置。感覺用tomcat發布sprint+struts+hibernate架構的程序時很容易發生這種內存溢出錯誤。使用上述方法，我成功解決了部署ssh項目的tomcat伺服器經常宕機的問題。
清理應用程序中web-inf/lib下的jar，如果tomcat部署了多個應用，很多應用都使用了相同的jar，可以將共同的jar移到tomcat共同的lib下，減少類的重復載入。這種方法是網上部分人推薦的，我沒試過，但感覺減少不了太大的空間，最靠譜的還是第一種方法。
第二種OutOfMemoryError： Java heap space
發生這種問題的原因是java虛擬機創建的對象太多，在進行垃圾回收之間，虛擬機分配的到堆內存空間已經用滿了，與Heap space有關。解決這類問題有兩種思路：
檢查程序，看是否有死循環或不必要地重復創建大量對象。找到原因後，修改程序和演算法。 我以前寫一個使用K-Means文本聚類演算法對幾萬條文本記錄（每條記錄的特徵向量大約10來個）進行文本聚類時，由於程序細節上有問題，就導致了Java heap space的內存溢出問題，後來通過修改程序得到了解決。
增加Java虛擬機中Xms（初始堆大小）和Xmx（最大堆大小）參數的大小。如：set JAVA_OPTS= -Xms256m -Xmx1024m
第三種OutOfMemoryError：unable to create new native thread
在java應用中，有時候會出現這樣的錯誤：OutOfMemoryError: unable to create new native thread.這種怪事是因為JVM已經被系統分配了大量的內存(比如1.5G)，並且它至少要佔用可用內存的一半。有人發現，在線程個數很多的情況下，你分配給JVM的內存越多，那麼，上述錯誤發生的可能性就越大。
那麼是什麼原因造成這種問題呢？
每一個32位的進程最多可以使用2G的可用內存，因為另外2G被操作系統保留。這里假設使用1.5G給JVM，那麼還餘下500M可用內存。這500M內存中的一部分必須用於系統dll的載入，那麼真正剩下的也許只有400M，現在關鍵的地方出現了：當你使用Java創建一個線程，在JVM的內存里也會創建一個Thread對象，但是同時也會在操作系統里創建一個真正的物理線程(參考JVM規范)，操作系統會在餘下的400兆內存里創建這個物理線程，而不是在JVM的1500M的內存堆里創建。在jdk1.4里頭，默認的棧大小是256KB，但是在jdk1.5里頭，默認的棧大小為1M每線程，因此，在餘下400M的可用內存里邊我們最多也只能創建400個可用線程。
這樣結論就出來了，要想創建更多的線程，你必須減少分配給JVM的最大內存。還有一種做法是讓JVM宿主在你的JNI代碼里邊。
給出一個有關能夠創建線程的最大個數的估算公式：
(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads

對於jdk1.5而言，假設操作系統保留120M內存：
1.5GB JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads
1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads

對於棧大小為256KB的jdk1.4而言，
1.5GB allocated to JVM: ~1520 threads
1.0GB allocated to JVM: ~3520 threads

對於這個異常我們首先需要判斷下，發生內存溢出時進程中到底都有什麼樣的線程，這些線程是否是應該存在的，是否可以通過優化來降低線程數； 另外一方面默認情況下java為每個線程分配的棧內存大小是1M，通常情況下，這1M的棧內存空間是足足夠用了，因為在通常在棧上存放的只是基礎類型的數據或者對象的引用，這些東西都不會占據太大的內存， 我們可以通過調整jvm參數，降低為每個線程分配的棧內存大小來解決問題，例如在jvm參數中添加-Xss128k將線程棧內存大小設置為128k。

❸ java中棧內存是什麼意思

堆內存：保存對象的真正數據，都是每一個對象的屬性內容
棧內存：保存的專是一塊堆內存的空屬間地址，可以把它想像成一個int型變數（每一個int型變數只能存放一個數值）所以每一塊保留一塊堆內存地址，但是為了方便理解，可以簡單的講棧內存之中保存的數據理解為對象的名稱（Person per，保存的是per）

❹ java工作原理

作為一名Java使用者，掌握JVM的體系結構也是必須的。
說起Java，人們首先想到的是Java編程語言，然而事實上，Java是一種技術，它由四方面組成：Java編程語言、Java類文件格式、Java虛擬機和Java應用程序介面(Java API)。它們的關系如下圖所示：

運行期環境代表著Java平台，開發人員編寫Java代碼(.java文件)，然後將之編譯成位元組碼(.class文件)，再然後位元組碼被裝入內存，一旦位元組碼進入虛擬機，它就會被解釋器解釋執行，或者是被即時代碼發生器有選擇的轉換成機器碼執行。

Java平台由Java虛擬機和Java應用程序介面搭建，Java語言則是進入這個平台的通道，用Java語言編寫並編譯的程序可以運行在這個平台上。

在Java平台的結構中, 可以看出，Java虛擬機(JVM) 處在核心的位置，是程序與底層操作系統和硬體無關的關鍵。它的下方是移植介面，移植介面由兩部分組成：適配器和Java操作系統, 其中依賴於平台的部分稱為適配器；JVM 通過移植介面在具體的平台和操作系統上實現；在JVM 的上方是Java的基本類庫和擴展類庫以及它們的API， 利用Java API編寫的應用程序(application) 和小程序(Java applet) 可以在任何Java平台上運行而無需考慮底層平台, 就是因為有Java虛擬機(JVM)實現了程序與操作系統的分離，從而實現了Java 的平台無關性。

JVM在它的生存周期中有一個明確的任務，那就是運行Java程序，因此當Java程序啟動的時候，就產生JVM的一個實例；當程序運行結束的時候，該實例也跟著消失了。下面我們從JVM的體系結構和它的運行過程這兩個方面來對它進行比較深入的研究。

1、Java虛擬機的體系結構

·每個JVM都有兩種機制：

①類裝載子系統：裝載具有適合名稱的類或介面

②執行引擎：負責執行包含在已裝載的類或介面中的指令

·每個JVM都包含：

方法區、Java堆、Java棧、本地方法棧、指令計數器及其他隱含寄存器

對於JVM的學習，在我看來這么幾個部分最重要：

Java代碼編譯和執行的整個過程

JVM內存管理及垃圾回收機制

下面分別對這幾部分進行說明：

2、Java代碼編譯和執行的整個過程

也正如前面所說，Java代碼的編譯和執行的整個過程大概是：開發人員編寫Java代碼(.java文件)，然後將之編譯成位元組碼(.class文件)，再然後位元組碼被裝入內存，一旦位元組碼進入虛擬機，它就會被解釋器解釋執行，或者是被即時代碼發生器有選擇的轉換成機器碼執行。

（1）Java代碼編譯是由Java源碼編譯器來完成，也就是Java代碼到JVM位元組碼（.class文件）的過程。

（2）Java位元組碼的執行是由JVM執行引擎來完成。

Java代碼編譯和執行的整個過程包含了以下三個重要的機制:

·Java源碼編譯機制

·類載入機制

·類執行機制

（1）Java源碼編譯機制

Java 源碼編譯由以下三個過程組成：

①分析和輸入到符號表

②註解處理

③語義分析和生成class文件

最後生成的class文件由以下部分組成：

①結構信息：包括class文件格式版本號及各部分的數量與大小的信息

②元數據：對應於Java源碼中聲明與常量的信息。包含類/繼承的超類/實現的介面的聲明信息、域與方法聲明信息和常量池

③方法信息：對應Java源碼中語句和表達式對應的信息。包含位元組碼、異常處理器表、求值棧與局部變數區大小、求值棧的類型記錄、調試符號信息

（2）類載入機制
JVM的類載入是通過ClassLoader及其子類來完成的，類的層次關系和載入順序可以由下圖來描述：

①Bootstrap ClassLoader

負責載入$JAVA_HOME中jre/lib/rt.jar里所有的class，由C++實現，不是ClassLoader子類

②Extension ClassLoader

負責載入java平台中擴展功能的一些jar包，包括$JAVA_HOME中jre/lib/*.jar或-Djava.ext.dirs指定目錄下的jar包

③App ClassLoader

負責記載classpath中指定的jar包及目錄中class

④Custom ClassLoader

屬於應用程序根據自身需要自定義的ClassLoader，如tomcat、jboss都會根據j2ee規范自行實現ClassLoader

載入過程中會先檢查類是否被已載入，檢查順序是自底向上，從Custom ClassLoader到BootStrap ClassLoader逐層檢查，只要某個classloader已載入就視為已載入此類，保證此類只所有ClassLoader載入一次。而載入的順序是自頂向下，也就是由上層來逐層嘗試載入此類。

（3）類執行機制

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

JVM執行class位元組碼，線程創建後，都會產生程序計數器（PC）和棧（Stack），程序計數器存放下一條要執行的指令在方法內的偏移量，棧中存放一個個棧幀，每個棧幀對應著每個方法的每次調用，而棧幀又是有局部變數區和操作數棧兩部分組成，局部變數區用於存放方法中的局部變數和參數，操作數棧中用於存放方法執行過程中產生的中間結果。棧的結構如下圖所示：

3、JVM內存管理及垃圾回收機制

JVM內存結構分為：方法區（method），棧內存（stack），堆內存（heap），本地方法棧（java中的jni調用），結構圖如下所示：

（1）堆內存（heap）

所有通過new創建的對象的內存都在堆中分配，其大小可以通過-Xmx和-Xms來控制。
操作系統有一個記錄空閑內存地址的鏈表，當系統收到程序的申請時，會遍歷該鏈表，尋找第一個空間大於所申請空間的堆結點，然後將該結點從空閑結點鏈表中刪除，並將該結點的空間分配給程序，另外，對於大多數系統，會在這塊內存空間中的首地址處記錄本次分配的大小，這樣代碼中的delete語句才能正確的釋放本內存空間。但由於找到的堆結點的大小不一定正好等於申請的大小，系統會自動的將多餘的那部分重新放入空閑鏈表中。這時由new分配的內存，一般速度比較慢，而且容易產生內存碎片，不過用起來最方便。另外，在WINDOWS下，最好的方式是用VirtualAlloc分配內存，它不是在堆，也不是在棧，而是直接在進程的地址空間中保留一塊內存，雖然這種方法用起來最不方便，但是速度快，也是最靈活的。堆內存是向高地址擴展的數據結構，是不連續的內存區域。由於系統是用鏈表來存儲的空閑內存地址的，自然是不連續的，而鏈表的遍歷方向是由低地址向高地址。堆的大小受限於計算機系統中有效的虛擬內存。由此可見，堆獲得的空間比較靈活，也比較大。

（2）棧內存（stack）

在Windows下, 棧是向低地址擴展的數據結構，是一塊連續的內存區域。這句話的意思是棧頂的地址和棧的最大容量是系統預先規定好的，在WINDOWS下，棧的大小是固定的（是一個編譯時就確定的常數），如果申請的空間超過棧的剩餘空間時，將提示overflow。因此，能從棧獲得的空間較小。只要棧的剩餘空間大於所申請空間，系統將為程序提供內存，否則將報異常提示棧溢出。 由系統自動分配，速度較快。但程序員是無法控制的。

堆內存與棧內存需要說明：

基礎數據類型直接在棧空間分配，方法的形式參數，直接在棧空間分配，當方法調用完成後從棧空間回收。引用數據類型，需要用new來創建，既在棧空間分配一個地址空間，又在堆空間分配對象的類變數 。方法的引用參數，在棧空間分配一個地址空間，並指向堆空間的對象區，當方法調用完成後從棧空間回收。局部變數new出來時，在棧空間和堆空間中分配空間，當局部變數生命周期結束後，棧空間立刻被回收，堆空間區域等待GC回收。方法調用時傳入的literal參數，先在棧空間分配，在方法調用完成後從棧空間收回。字元串常量、static在DATA區域分配，this在堆空間分配。數組既在棧空間分配數組名稱，又在堆空間分配數組實際的大小。

如：

（3）本地方法棧（java中的jni調用）

用於支持native方法的執行，存儲了每個native方法調用的狀態。對於本地方法介面，實現JVM並不要求一定要有它的支持，甚至可以完全沒有。Sun公司實現Java本地介面(JNI)是出於可移植性的考慮，當然我們也可以設計出其它的本地介面來代替Sun公司的JNI。但是這些設計與實現是比較復雜的事情，需要確保垃圾回收器不會將那些正在被本地方法調用的對象釋放掉。

（4）方法區（method）

它保存方法代碼(編譯後的java代碼)和符號表。存放了要載入的類信息、靜態變數、final類型的常量、屬性和方法信息。JVM用持久代（Permanet Generation）來存放方法區，可通過-XX:PermSize和-XX:MaxPermSize來指定最小值和最大值。

垃圾回收機制

堆里聚集了所有由應用程序創建的對象，JVM也有對應的指令比如 new, newarray, anewarray和multianewarray，然並沒有向 C++ 的 delete，free 等釋放空間的指令，Java的所有釋放都由 GC 來做，GC除了做回收內存之外，另外一個重要的工作就是內存的壓縮，這個在其他的語言中也有類似的實現，相比 C++ 不僅好用，而且增加了安全性，當然她也有弊端，比如性能這個大問題。

(4)java棧多大內存擴展閱讀

Java虛擬機的運行過程示例

上面對虛擬機的各個部分進行了比較詳細的說明，下面通過一個具體的例子來分析它的運行過程。

虛擬機通過調用某個指定類的方法main啟動，傳遞給main一個字元串數組參數，使指定的類被裝載，同時鏈接該類所使用的其它的類型，並且初始化它們。例如對於程序：

編譯後在命令行模式下鍵入： java HelloApp run virtual machine

將通過調用HelloApp的方法main來啟動java虛擬機，傳遞給main一個包含三個字元串"run"、"virtual"、"machine"的數組。現在我們略述虛擬機在執行HelloApp時可能採取的步驟。

開始試圖執行類HelloApp的main方法，發現該類並沒有被裝載，也就是說虛擬機當前不包含該類的二進制代表，於是虛擬機使用ClassLoader試圖尋找這樣的二進制代表。如果這個進程失敗，則拋出一個異常。類被裝載後同時在main方法被調用之前，必須對類HelloApp與其它類型進行鏈接然後初始化。鏈接包含三個階段：檢驗，准備和解析。檢驗檢查被裝載的主類的符號和語義，准備則創建類或介面的靜態域以及把這些域初始化為標準的默認值，解析負責檢查主類對其它類或介面的符號引用，在這一步它是可選的。類的初始化是對類中聲明的靜態初始化函數和靜態域的初始化構造方法的執行。一個類在初始化之前它的父類必須被初始化。