java修改堆內存,java設置堆內存

本文目錄一覽：

• 1、java內存溢出問題！請問如何修改JVM分配內存，麻煩具體一點，不勝感激~
• 2、Tomcat 環境中，Java 內存 堆的調整
• 3、JAVA堆棧在哪裡設置？
• 4、誰能解釋一下java中的棧內存和堆內存
• 5、如何設置jvm內存
• 6、如何解決物理內存不足引起的JAVA 堆內存溢出

java內存溢出問題！請問如何修改JVM分配內存，麻煩具體一點，不勝感激~

java.lang.OutOfMemoryError: Java heap space?

我只知道手動設置：

java 運行的Class -Xms800m -Xmx800m -XX:MaxNewSize=256m

也就是說運行時設置參數就可以了

Tomcat 環境中，Java 內存 堆的調整

設置Tomcat啟動的初始內存其初始空間(即-Xms)是物理內存的1/64，最大空間(-Xmx)是物理內存的1/4。

可以利用JVM提供的-Xmn -Xms -Xmx等選項可進行設置

三、實例，以下給出1G內存環境下java jvm 的參數設置參考：

JAVA_OPTS=”-server -Xms800m -Xmx800m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true “

JAVA_OPTS=”-server -Xms768m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m -XX: NewSize=192m -XX:MaxNewSize=384m”

CATALINA_OPTS=”-server -Xms768m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:NewSize=192m -XX:MaxNewSize=384m”

Linux：

在/usr/local/apache-tomcat-5.5.23/bin 目錄下的catalina.sh添加：

JAVA_OPTS=’-Xms512m -Xmx1024m’要加「m」說明是MB，否則就是KB了，在啟動tomcat時會 報內存不足。

-Xms：初始值-Xmx：最大值-Xmn：最小值

Windows

在catalina.bat最前面加入set JAVA_OPTS=-Xms128m -Xmx350m

如果用startup.bat啟動tomcat,OK設置生效.夠成功的分配200M內存.

但是如果不是執行startup.bat啟動tomcat而是利用windows的系統服務啟動tomcat服務,上面的設置就不生效了,就是說set JAVA_OPTS=-Xms128m -Xmx350m 沒起作用.上面分配200M內存就OOM了..

windows服務執行的是bin\tomcat.exe.他讀取註冊表中的值,而不是catalina.bat的設置.

解決辦法:

修改註冊表HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat Service Manager\Tomcat5\Parameters\JavaOptions

原值為-Dcatalina.home=”C:\ApacheGroup\Tomcat 5.0″-Djava.endorsed.dirs=”C:\ApacheGroup\Tomcat 5.0\common\endorsed”-Xrs加入 -Xms300m -Xmx350m

重起tomcat服務,設置生效

答案2Tomcat 的JVM 內存溢出問題的解決關鍵字: tomcat 的jvm 內存溢出問題的解決

最近在熟悉一個開發了有幾年的項目，需要把資料庫從mysql移植到oracle，首先把jdbc的連接指向mysql，打包放到tomcat裡面，可以跑起來，沒有問題，可是當把jdbc連接指向oracle的時候，tomcat就連續拋java.lang.OutOfMemoryError的錯誤，上網google了一下，了解了一下tomcat的運行機制，也解決了問題，share出來，以備查。

1、首先是：java.lang.OutOfMemoryError: Java heap space 解釋： Heap size 設置 JVM堆的設置是指java程序運行過程中JVM可以調配使用的內存空間的設置.JVM在啟動的時候會自動設置Heap size的值，其初始空間(即-Xms)是物理內存的1/64，最大空間(-Xmx)是物理內存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等選項可進行設置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。

提示：在JVM中如果98％的時間是用於GC且可用的Heap size 不足2％的時候將拋出此異常信息。

提示：Heap Size 最大不要超過可用物理內存的80％，一般的要將-Xms和-Xmx選項設置為相同，而-Xmn為1/4的-Xmx值。

解決方法： 手動設置Heap size 修改TOMCAT_HOME/bin/catalina.bat，在「echo “Using CATALINA_BASE: $CATALINA_BASE”」上面加入以下行： Java代碼 set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:MaxNewSize=256m set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m -XX:MaxNewSize=256m 或修改catalina.sh 在「echo “Using CATALINA_BASE: $CATALINA_BASE”」上面加入以下行： JAVA_OPTS=”$JAVA_OPTS -server -Xms800m -Xmx800m -XX:MaxNewSize=256m”

2、其次是：java.lang.OutOfMemoryError: PermGen space 原因： PermGen space的全稱是Permanent Generation space,是指內存的永久保存區域，這塊內存主要是被JVM存放Class和Meta信息的,Class在被Loader時就會被放到PermGen space中，它和存放類實例(Instance)的Heap區域不同,GC(Garbage Collection)不會在主程序運行期對PermGen space進行清理，所以如果你的應用中有很CLASS的話,就很可能出現PermGen space錯誤，這種錯誤常見在web伺服器對JSP進行pre compile的時候。如果你的WEB APP下都用了大量的第三方jar, 其大小超過了jvm默認的大小(4M)那麼就會產生此錯誤信息了。

解決方法： 1. 手動設置MaxPermSize大小 修改TOMCAT_HOME/bin/catalina.bat（Linux下為catalina.sh），在Java代碼 「echo “Using CATALINA_BASE: $CATALINA_BASE”」上面加入以下行： set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m 「echo “Using CATALINA_BASE: $CATALINA_BASE”」上面加入以下行： set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m catalina.sh下為： Java代碼 JAVA_OPTS=”$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m” JAVA_OPTS=”$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m”

另外看到了另外一個帖子，覺得挺好，摘抄如下：

分析java.lang.OutOfMemoryError: PermGen space 發現很多人把問題歸因於： spring,hibernate,tomcat，因為他們動態產生類,導致JVM中的permanent heap溢出 。然後解決方法眾說紛紜，有人說升級 tomcat版本到最新甚至乾脆不用tomcat。還有人懷疑spring的問題，在spring論壇上討論很激烈，因為spring在AOP時使用CBLIB會動態產生很多類。 但問題是為什麼這些王牌的開源會出現同一個問題呢，那麼是不是更基礎的原因呢？tomcat在QA很隱晦的回答了這一點，我們知道這個問題，但這個問題是由一個更基礎的問題產生。 於是有人對更基礎的JVM做了檢查，發現了問題的關鍵。原來SUN 的JVM把內存分了不同的區，其中一個就是permenter區用來存放用得非常多的類和類描述。本來SUN設計的時候認為這個區域在JVM啟動的時候就固定了，但他沒有想到現在動態會用得這麼廣泛。而且這個區域有特殊的垃圾收回機制，現在的問題是動態載入類到這個區域後，gc根本沒辦法回收！

對於以上兩個問題，我的處理是：

在catalina.bat的第一行增加：

Java代碼 :set JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m

在catalina.sh的第一行增加：

Java代碼 :JAVA_OPTS=-Xms64m -Xmx256m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m

JAVA堆棧在哪裡設置？

堆棧設置無疑是要適當理解和設置的最重要環節。 過度嚴格的內存設置要麼使Tomcat運行很慢，要麼報OutOfMemoryError的錯誤信息，使工作不正常。內存設置過大，要麼因不能平均分配如此大量的內存而無法啟動JVM，要麼能啟動運行正常，但卻耗用了超出所需的過量計算機內存，而且計算機上的其他軟體也無法運行(因為必要的內存已分配給Tomcat)。 之前關於JVM設置選項詳解中顯示的-Xmx和-Xms設置值為384MB，但這不一定是計算機的適用內存，即使是適用的，也未必就是Tomcat所要的內存大小。到底多大內存是最適合的，需要經驗來決定不同內存的大小。

以小的和大的啟動堆棧內存配置Tomcat JVM，都會引髮網頁響應時間超出Java VM堆棧的最大值的某種問題(如果需要堆棧也跟著增長)。 因為Tomcat正在提供響應時會佔用大量的時間重新分配內存，所以如果您不希望性能出現類似的問題，一定要讓-Xms和Xmx開關值就是所需內存的相同大小，從而保證JVM在操作過程中從不需要重新分配堆棧內存。

在調用駐留於CATALINA_HOME/bin的Tomcat腳本之前，可以設置JAVA_OPTS環境變數值，以設置這些JVM啟動的任意開關。將JAVA_OPTS設置成包含任意開關、以空格分開的字元串。

為了可以連接遠程調試器，且想阻調試模式啟動Tomcat JVM，那麼可以按如下方式設置JAVA_OPTS環境變數：

JAVA_OPTS=”-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n”

以上語句允許您通過Tomcat主機上的8000埠連接一個JPDA遠程調試器客戶端(例如，任何Java IDE)，並調試Tomcat JVM中運行的任何代碼。您可隨意定製所喜歡的埠號。

如果想通過JMX遠程客戶端連接到Tomcat以實現本地管理和，或監控，請使用下列設置：

JAVA_OPTS=”-Dcom.sun.management.jmxremote=true

-Dcom.sun.management.jxremote.ssl=false

-Dcom.sun.managerment.jmxremote.authenticate=false”

這些設置允許您在同一台運行Tomcat的機器上使用JMX控制台(如JDK自帶的jconsole)，如果想遠程使用JMX控制台，則使用下列這些設置：

JAVA_OPTS=”-Dcom.sun.management.jmxremote.port=8080

-Dcom.sun.management.jmxremote.ssl=false

-Dcom.sun.management.jmxremote.authenticate=false

-Dcom.sun.management.jmxmote.password.file=/path/to/pw/file”

這些設置允許您從另一台機器上用TCP 8008埠連接到Tomcat JVM上。 您也可以設置-Dcom.sun.management.jmxremote.authenticate=truen，然後在JMX遠程口令文件中設置-Dcom.sun.management.jmxmote.password.file=/path/to/pw/file路徑，從而只有您及您授權的用戶可以連接到Tomcat JVM上。

誰能解釋一下java中的棧內存和堆內存

2.1 內存分配策略

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

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

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

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

2.2 堆和棧的比較

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

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

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

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

2.3 JVM中的堆和棧

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

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

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

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

如何設置jvm內存

修改 tomcat 的內存方式：

修改 tomcat安裝目錄\bin\catalina.bat

在

set JAVA_OPTS=%JAVA_OPTS% %LOGGING_CONFIG%

這行下面前面加上

JAVA_OPTS=’-Xms512m -Xmx1024m’

JAVA_OPTS=”$JAVA_OPTS -server -XX:PermSize=64M -XX:MaxPermSize=256m”

其中 JAVA_OPTS=’-Xms512m -Xmx1024m’ 是設置Tomcat使用的內存的大小.

-XX:PermSize=64M -XX:MaxPermSize=256m 指定類空間(用於載入類)的內存大小

如何解決物理內存不足引起的JAVA 堆內存溢出

內存溢出 out of memory，是指程序在申請內存時，沒有足夠的內存空間供其使用，出現out of memory；比如申請了一個integer,但給它存了long才能存下的數，那就是內存溢出。

內存泄露 memory leak，是指程序在申請內存後，無法釋放已申請的內存空間，一次內存泄露危害可以忽略，但內存泄露堆積後果很嚴重，無論多少內存,遲早會被佔光。

memory leak會最終會導致out of memory！

內存溢出就是你要求分配的內存超出了系統能給你的，系統不能滿足需求，於是產生溢出。

內存泄漏是指你向系統申請分配內存進行使用(new)，可是使用完了以後卻不歸還(delete)，結果你申請到的那塊內存你自己也不能再訪問（也許你把它的地址給弄丟了），而系統也不能再次將它分配給需要的程序。一個盤子用盡各種方法只能裝4個果子，你裝了5個，結果掉倒地上不能吃了。這就是溢出！比方說棧，棧滿時再做進棧必定產生空間溢出，叫上溢，棧空時再做退棧也產生空間溢出，稱為下溢。就是分配的內存不足以放下數據項序列,稱為內存溢出.

以發生的方式來分類，內存泄漏可以分為4類：

1. 常發性內存泄漏。發生內存泄漏的代碼會被多次執行到，每次被執行的時候都會導致一塊內存泄漏。

2. 偶發性內存泄漏。發生內存泄漏的代碼只有在某些特定環境或操作過程下才會發生。常發性和偶發性是相對的。對於特定的環境，偶發性的也許就變成了常發性的。所以測試環境和測試方法對檢測內存泄漏至關重要。

3. 一次性內存泄漏。發生內存泄漏的代碼只會被執行一次，或者由於演算法上的缺陷，導致總會有一塊僅且一塊內存發生泄漏。比如，在類的構造函數中分配內存，在析構函數中卻沒有釋放該內存，所以內存泄漏只會發生一次。

4. 隱式內存泄漏。程序在運行過程中不停的分配內存，但是直到結束的時候才釋放內存。嚴格的說這裡並沒有發生內存泄漏，因為最終程序釋放了所有申請的內存。但是對於一個伺服器程序，需要運行幾天，幾周甚至幾個月，不及時釋放內存也可能導致最終耗盡系統的所有內存。所以，我們稱這類內存泄漏為隱式內存泄漏。

從用戶使用程序的角度來看，內存泄漏本身不會產生什麼危害，作為一般的用戶，根本感覺不到內存泄漏的存在。真正有危害的是內存泄漏的堆積，這會最終消耗盡系統所有的內存。從這個角度來說，一次性內存泄漏並沒有什麼危害，因為它不會堆積，而隱式內存泄漏危害性則非常大，因為較之於常發性和偶發性內存泄漏它更難被檢測到

內存溢出的原因以及解決方法

引起內存溢出的原因有很多種，小編列舉一下常見的有以下幾種：

1.內存中載入的數據量過於龐大，如一次從資料庫取出過多數據；

2.集合類中有對對象的引用，使用完後未清空，使得JVM不能回收；

3.代碼中存在死循環或循環產生過多重複的對象實體；

4.使用的第三方軟體中的BUG；

5.啟動參數內存值設定的過小

內存溢出的解決方案：

第一步，修改JVM啟動參數，直接增加內存。(-Xms，-Xmx參數一定不要忘記加。)

第二步，檢查錯誤日誌，查看逗OutOfMemory地錯誤前是否有其它異常或錯誤。

第三步，對代碼進行走查和分析，找出可能發生內存溢出的位置。

重點排查以下幾點：

1.檢查對資料庫查詢中，是否有一次獲得全部數據的查詢。一般來說，如果一次取十萬條記錄到內存，就可能引起內存溢出。這個問題比較隱蔽，在上線前，資料庫中數據較少，不容易出問題，上線後，資料庫中數據多了，一次查詢就有可能引起內存溢出。因此對於資料庫查詢盡量採用分頁的方式查詢。

2.檢查代碼中是否有死循環或遞歸調用。

3.檢查是否有大循環重複產生新對象實體。

4.檢查對資料庫查詢中，是否有一次獲得全部數據的查詢。一般來說，如果一次取十萬條記錄到內存，就可能引起內存溢出。這個問題比較隱蔽，在上線前，資料庫中數據較少，不容易出問題，上線後，資料庫中數據多了，一次查詢就有可能引起內存溢出。因此對於資料庫查詢盡量採用分頁的方式查詢。

5.檢查List、MAP等集合對象是否有使用完後，未清除的問題。List、MAP等集合對象會始終存有對對象的引用，使得這些對象不能被GC回收。

第四步，使用內存查看工具動態查看內存使用情況