JVM内存分块
一、JVM內存區域組成
java 把內存分四種
1、棧區（stack segment）— 由編譯器自動分配釋放,存放函數的參數值，局部變量的值等，具體方法執行結束之后，系統自動釋放內存資源
2、堆區（heap segment） — 一般由程序員分配釋放，存放由new創建的對象和數組，jvm不定時查看這個對象，如果沒有引用指向這個對象就回收
3、靜態區（data segment）— 存放全局變量，靜態變量 和字符串常量，不釋放
4、代碼區（code segment）— 存放程序中方法的二進制代碼，而且是多個對象 共享一個代碼空間區域
在方法（代碼塊）中定義一個變量時，java 就在棧中為這個變量分配內存空間，當超過變量的作用域后，java 會自動釋放掉為該變量所分配的內存空間；
在堆中分配的內存由java 虛擬機的自動垃圾回收器來管理，堆的優勢是可以動態分配內存大小，生存期也不必事先告訴編譯器，因為它是在運行時動態分配內存的。缺點就是要在運行時動態分配內存，存取速度較慢；棧的優勢是存取速度比堆要快，缺點是存在棧中的數據大小與生存期必須是確定的無靈活性.
java 堆由Perm區和Heap區組成，Heap區則由Old區 和New區組成，而New區又分為Eden區, From區, To區，Heap = {Old + NEW = { Eden, From, To } }，見圖1所示。
Heap區分兩大塊，一塊是 NEW Generation, 另一塊是Old Generation. 在New Generation中，有一個叫Eden的空間，主要是用來存放新生的對象，還有兩個Survivor Spaces（from,to）, 它們用來存放每次垃圾回收后存活下來的對象。在Old Generation中，主要存放應用程序中生命周期長的內存對象，還有個Permanent Generation，主要用來放JVM自己的反射對象，比如類對象和方法對象等。
在New Generation塊中，垃圾回收一般用Copying的算法，速度快。每次GC的時候，存活下來的對象首先由Eden拷貝到某個Survivor Space, 當Survivor Space空間滿了后, 剩下的live對象就被直接拷貝到Old Generation中去。因此，每次GC后，Eden內存塊會被清空。在Old Generation塊中，垃圾回收一般用mark-compact的算法，速度慢些，但減少內存要求.
垃圾回收分多級，0級為全部(Full)的垃圾回收，會回收OLD段中的垃圾；1級或以上為部分垃圾回收，只會回收NEW中的垃圾，內存溢出通常發生于OLD段或Perm段垃圾回收后，仍然無內存空間容納新的Java 對象的情況。
JVM調用GC的頻度還是很高的，主要兩種情況下進行垃圾回收：當應用程序線程空閑；另一個是java 內存堆不足時，會不斷調用GC，若連續回收都解決不了內存堆不足的問題時，就會報out of memory錯誤。因為這個異常根據系統運行環境決定，所以無法預期它何時出現。
根 據GC的機制，程序的運行會引起系統運行環境的變化，增加GC的觸發機會。為了避免這些問題，程序的設計和編寫就應避免垃圾對象的內存占用和GC的開銷。 顯示調用System.GC()只能建議JVM需要在內存中對垃圾對象進行回收，但不是必須馬上回收，一個是并不能解決內存資源耗空的局面，另外也會增加 GC的消耗。
當一個URL被訪問時，內存申請過程如下：
A. JVM會試圖為相關Java 對象在Eden中初始化一塊內存區域
B. 當Eden空間足夠時，內存申請結束。否則到下一步
C. JVM試圖釋放在Eden中所有不活躍的對象（這屬于1或更高級的垃圾回收）, 釋放后若Eden空間仍然不足以放入新對象，則試圖將部分Eden中活躍對象放入Survivor區
D. Survivor區被用來作為Eden及OLD的中間交換區域，當OLD區 空間足夠時，Survivor區的對象會被移到Old區 ，否則會被保留在Survivor區
E. 當OLD區 空間不夠時，JVM會在OLD區 進行完全的垃圾收集（0級）
F. 完全垃圾收集后，若Survivor及OLD區 仍然無法存放從Eden復制過來的部分對象，導致JVM無法在Eden區為新對象創建內存區域，則出現"out of memory錯誤"
二、內存溢出類型?
1、java .lang.OutOfMemoryError: PermGen space
JVM 管理兩種類型的內存，堆和非堆。堆是給開發人員用的，是在JVM啟動時創建；非堆是留給JVM自己用的，用來存放類的信息的。它和堆不同，運行期內GC不 會釋放空間。如果web app用了大量的第三方jar或者應用有太多的class文件而恰好MaxPermSize設置較小，超出了也會導致這塊內存的占用過多造成溢出，或者 tomcat熱部署時侯不會清理前面加載的環境，只會將context更改為新部署的，非堆存的內容就會越來越多。
2、java .lang.OutOfMemoryError:
2Javaheap space
這種內存溢出是最常見的情況之一，主要體現在Old區 的 溢出，產生的原因可能是：1) 設置的內存參數過小(ms/mx, NewSize/MaxNewSize)；2) 程序問題。Heap space其默認空間(即-Xms)是物理內存的1/64，最大空間(-Xmx)是物理內存的1/4。如果內存剩余不到40％，JVM就會增大堆到Xmx 設置的值，內存剩余超過70％，JVM就會減小堆到Xms設置的值。所以服務器的Xmx和Xms設置一般應該設置相同避免每次GC后都要調整虛擬機堆的大 小。假設物理內存無限大，那么JVM內存的最大值跟操作系統有關，一般32位機是1.5g到3g之間，而64位的就不會有限制了.
注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內存或者操作系統的最大限制都會引起服務器啟動不起來.
3、java .lang.OutOfMemoryError: c heap space
系統對C Heap沒有限制，故C Heap發生問題時，Java 進程所占內存會持續增長，直到占用所有可用系統內存
4、其他
JVM 有2個GC線程。第一個線程負責回收Heap的Young區。第二個線程在Heap不足時，遍歷Heap，將Young 區升級為Older區。Older區的大小等于-Xmx減去-Xmn，不能將-Xms的值設的過大，因為第二個線程被迫運行會降低JVM的性能。
為什么一些程序頻繁發生GC？有如下原因：
a、程序內調用了System.gc()或Runtime.gc()。
b、一些中間件軟件調用自己的GC方法，此時需要設置參數禁止這些GC。
c、Java 的Heap太小，一般默認的Heap值都很小。
d、頻繁實例化對象，Release對
象。此時盡量保存并重用對象，例如使用StringBuffer()和String()。
如果你發現每次GC后，Heap的剩余空間會是總空間的50%，這表示你的Heap處于健康狀態。許多Server端的Java 程序每次GC后最好能有65%的剩余空間。
三、JVM如何設置虛擬內存
提示：在JVM中如果98％的時間是用于GC且可用的Heap size 不足2％的時候將拋出此異常信息。
提示：Heap Size 最大不要超過可用物理內存的80％，一般的要將-Xms和-Xmx選項設置為相同，而-Xmn為1/4的-Xmx值。
提 示：JVM初始分配的內存由-Xms指定，默認是物理內存的1/64；JVM最大分配的內存由-Xmx指定，默認是物理內存的1/4。默認空余堆內存小于 40%時，JVM就會增大堆直到-Xmx的最大限制；空余堆內存大于70%時，JVM會減少堆直到-Xms的最小限制。因此服務器一般設置-Xms、 -Xmx相等以避免在每次GC 后調整堆的大小。
提示：假設物理內存無限大的話，JVM內存的最大值跟操作系統有很大的關系。簡單的說就32位 處理器雖然可控內存空間有4GB,但是具體的操作系統會給一個限制，這個限制一般是2GB-3GB（一般來說Windows系統下為1.5G- 2G，Linux系統下為2G-3G），而64bit以上的處理器就不會有限制了
提示：注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內存或者操作系統的最大限制都會引起服務器啟動不起來。
提示：設置NewSize、MaxNewSize相等，"new"的大小最好不要大于"old"的一半，原因是old區 如果不夠大會頻繁的觸發"主" GC ，大大降低了性能
提示：增加Heap Size 雖然會降低GC的頻率，但也增加了每次GC的時間。并且GC運行時，所有的用戶線程將暫停，也就是GC期間，Java 應用程序不做任何工作。
提示：Heap Size 并不決定進程的內存使用量。進程的內存使用量要大于-Xmx定義的值，因為Java 為其他任務分配內存，例如每個線程的Stack等。
提示：每個線程都有他自己的Stack，Stack Size 限制著線程的數量。如果Stack過大就好導致內存溢漏。-Xss參數決定Stack大小，例如-Xss1024K。如果Stack太小，也會導致Stack溢漏。
JVM使用-XX:PermSize設置非堆內存初始值，默認是物理內存的1/64；由XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的1/4。
解決方法：手動設置Heap size
修改TOMCAT_HOME/bin/catalina.bat
在"echo "Using CATALINA_BASE: $CATALINA_BASE""上面加入以下行：
JAVA _OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"
四、不健壯代碼的特征及解決辦法
1、 盡早釋放無用對象的引用。好的辦法是使用臨時變量的時候，讓引用變量在退出活動域后，自動設置為null，暗示垃圾收集器來收集該對象，防止發生內存泄 露。對于仍然有指針指向的實例，jvm就不會回收該資源,因為垃圾回收會將值為null的對象作為垃圾，提高GC回收機制效率；
2、我們的程序里不可避免大量使用字符串處理，避免使用String，應大量使用StringBuffer，每一個String對象都得獨立占用內存一塊區域；例如
3、盡量少用靜態變量 ，因為靜態變量 是全局的，GC不會回收的；
4、避免集中創建對象尤其是大對象，JVM會突然需要大量內存，這時必然會觸發GC優化系統內存環境；顯示的聲明數組空間，而且申請數量還極大。
5、盡量運用對象池技術以提高系統性能；生命周期長的對象擁有生命周期短的對象時容易引發內存泄漏，例如大集合對象擁有大數據量的業務對象的時候，可以考慮分塊進行處理，然后解決一塊釋放一塊的策略。
6、不要在經常調用的方法中創建對象，尤其是忌諱在循環中創建對象。可以適當的使用hashtable，vector 創建一組對象容器，然后從容器中去取那些對象，而不用每次new之后又丟棄
7、一般都是發生在開啟大型文件或跟數據庫一次拿了太多的數據，造成 Out Of Memory Error 的狀況，這時就大概要計算一下數據量的最大值是多少，并且設定所需最小及最大的內存空間值。
java 把內存分四種
1、棧區（stack segment）— 由編譯器自動分配釋放,存放函數的參數值，局部變量的值等，具體方法執行結束之后，系統自動釋放內存資源
2、堆區（heap segment） — 一般由程序員分配釋放，存放由new創建的對象和數組，jvm不定時查看這個對象，如果沒有引用指向這個對象就回收
3、靜態區（data segment）— 存放全局變量，靜態變量 和字符串常量，不釋放
4、代碼區（code segment）— 存放程序中方法的二進制代碼，而且是多個對象 共享一個代碼空間區域
在方法（代碼塊）中定義一個變量時，java 就在棧中為這個變量分配內存空間，當超過變量的作用域后，java 會自動釋放掉為該變量所分配的內存空間；
在堆中分配的內存由java 虛擬機的自動垃圾回收器來管理，堆的優勢是可以動態分配內存大小，生存期也不必事先告訴編譯器，因為它是在運行時動態分配內存的。缺點就是要在運行時動態分配內存，存取速度較慢；棧的優勢是存取速度比堆要快，缺點是存在棧中的數據大小與生存期必須是確定的無靈活性.
java 堆由Perm區和Heap區組成，Heap區則由Old區 和New區組成，而New區又分為Eden區, From區, To區，Heap = {Old + NEW = { Eden, From, To } }，見圖1所示。
Heap區分兩大塊，一塊是 NEW Generation, 另一塊是Old Generation. 在New Generation中，有一個叫Eden的空間，主要是用來存放新生的對象，還有兩個Survivor Spaces（from,to）, 它們用來存放每次垃圾回收后存活下來的對象。在Old Generation中，主要存放應用程序中生命周期長的內存對象，還有個Permanent Generation，主要用來放JVM自己的反射對象，比如類對象和方法對象等。
在New Generation塊中，垃圾回收一般用Copying的算法，速度快。每次GC的時候，存活下來的對象首先由Eden拷貝到某個Survivor Space, 當Survivor Space空間滿了后, 剩下的live對象就被直接拷貝到Old Generation中去。因此，每次GC后，Eden內存塊會被清空。在Old Generation塊中，垃圾回收一般用mark-compact的算法，速度慢些，但減少內存要求.
垃圾回收分多級，0級為全部(Full)的垃圾回收，會回收OLD段中的垃圾；1級或以上為部分垃圾回收，只會回收NEW中的垃圾，內存溢出通常發生于OLD段或Perm段垃圾回收后，仍然無內存空間容納新的Java 對象的情況。
JVM調用GC的頻度還是很高的，主要兩種情況下進行垃圾回收：當應用程序線程空閑；另一個是java 內存堆不足時，會不斷調用GC，若連續回收都解決不了內存堆不足的問題時，就會報out of memory錯誤。因為這個異常根據系統運行環境決定，所以無法預期它何時出現。
根 據GC的機制，程序的運行會引起系統運行環境的變化，增加GC的觸發機會。為了避免這些問題，程序的設計和編寫就應避免垃圾對象的內存占用和GC的開銷。 顯示調用System.GC()只能建議JVM需要在內存中對垃圾對象進行回收，但不是必須馬上回收，一個是并不能解決內存資源耗空的局面，另外也會增加 GC的消耗。
當一個URL被訪問時，內存申請過程如下：
A. JVM會試圖為相關Java 對象在Eden中初始化一塊內存區域
B. 當Eden空間足夠時，內存申請結束。否則到下一步
C. JVM試圖釋放在Eden中所有不活躍的對象（這屬于1或更高級的垃圾回收）, 釋放后若Eden空間仍然不足以放入新對象，則試圖將部分Eden中活躍對象放入Survivor區
D. Survivor區被用來作為Eden及OLD的中間交換區域，當OLD區 空間足夠時，Survivor區的對象會被移到Old區 ，否則會被保留在Survivor區
E. 當OLD區 空間不夠時，JVM會在OLD區 進行完全的垃圾收集（0級）
F. 完全垃圾收集后，若Survivor及OLD區 仍然無法存放從Eden復制過來的部分對象，導致JVM無法在Eden區為新對象創建內存區域，則出現"out of memory錯誤"
二、內存溢出類型?
1、java .lang.OutOfMemoryError: PermGen space
JVM 管理兩種類型的內存，堆和非堆。堆是給開發人員用的，是在JVM啟動時創建；非堆是留給JVM自己用的，用來存放類的信息的。它和堆不同，運行期內GC不 會釋放空間。如果web app用了大量的第三方jar或者應用有太多的class文件而恰好MaxPermSize設置較小，超出了也會導致這塊內存的占用過多造成溢出，或者 tomcat熱部署時侯不會清理前面加載的環境，只會將context更改為新部署的，非堆存的內容就會越來越多。
2、java .lang.OutOfMemoryError:
2Javaheap space
這種內存溢出是最常見的情況之一，主要體現在Old區 的 溢出，產生的原因可能是：1) 設置的內存參數過小(ms/mx, NewSize/MaxNewSize)；2) 程序問題。Heap space其默認空間(即-Xms)是物理內存的1/64，最大空間(-Xmx)是物理內存的1/4。如果內存剩余不到40％，JVM就會增大堆到Xmx 設置的值，內存剩余超過70％，JVM就會減小堆到Xms設置的值。所以服務器的Xmx和Xms設置一般應該設置相同避免每次GC后都要調整虛擬機堆的大 小。假設物理內存無限大，那么JVM內存的最大值跟操作系統有關，一般32位機是1.5g到3g之間，而64位的就不會有限制了.
注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內存或者操作系統的最大限制都會引起服務器啟動不起來.
3、java .lang.OutOfMemoryError: c heap space
系統對C Heap沒有限制，故C Heap發生問題時，Java 進程所占內存會持續增長，直到占用所有可用系統內存
4、其他
JVM 有2個GC線程。第一個線程負責回收Heap的Young區。第二個線程在Heap不足時，遍歷Heap，將Young 區升級為Older區。Older區的大小等于-Xmx減去-Xmn，不能將-Xms的值設的過大，因為第二個線程被迫運行會降低JVM的性能。
為什么一些程序頻繁發生GC？有如下原因：
a、程序內調用了System.gc()或Runtime.gc()。
b、一些中間件軟件調用自己的GC方法，此時需要設置參數禁止這些GC。
c、Java 的Heap太小，一般默認的Heap值都很小。
d、頻繁實例化對象，Release對
象。此時盡量保存并重用對象，例如使用StringBuffer()和String()。
如果你發現每次GC后，Heap的剩余空間會是總空間的50%，這表示你的Heap處于健康狀態。許多Server端的Java 程序每次GC后最好能有65%的剩余空間。
三、JVM如何設置虛擬內存
提示：在JVM中如果98％的時間是用于GC且可用的Heap size 不足2％的時候將拋出此異常信息。
提示：Heap Size 最大不要超過可用物理內存的80％，一般的要將-Xms和-Xmx選項設置為相同，而-Xmn為1/4的-Xmx值。
提 示：JVM初始分配的內存由-Xms指定，默認是物理內存的1/64；JVM最大分配的內存由-Xmx指定，默認是物理內存的1/4。默認空余堆內存小于 40%時，JVM就會增大堆直到-Xmx的最大限制；空余堆內存大于70%時，JVM會減少堆直到-Xms的最小限制。因此服務器一般設置-Xms、 -Xmx相等以避免在每次GC 后調整堆的大小。
提示：假設物理內存無限大的話，JVM內存的最大值跟操作系統有很大的關系。簡單的說就32位 處理器雖然可控內存空間有4GB,但是具體的操作系統會給一個限制，這個限制一般是2GB-3GB（一般來說Windows系統下為1.5G- 2G，Linux系統下為2G-3G），而64bit以上的處理器就不會有限制了
提示：注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內存或者操作系統的最大限制都會引起服務器啟動不起來。
提示：設置NewSize、MaxNewSize相等，"new"的大小最好不要大于"old"的一半，原因是old區 如果不夠大會頻繁的觸發"主" GC ，大大降低了性能
提示：增加Heap Size 雖然會降低GC的頻率，但也增加了每次GC的時間。并且GC運行時，所有的用戶線程將暫停，也就是GC期間，Java 應用程序不做任何工作。
提示：Heap Size 并不決定進程的內存使用量。進程的內存使用量要大于-Xmx定義的值，因為Java 為其他任務分配內存，例如每個線程的Stack等。
提示：每個線程都有他自己的Stack，Stack Size 限制著線程的數量。如果Stack過大就好導致內存溢漏。-Xss參數決定Stack大小，例如-Xss1024K。如果Stack太小，也會導致Stack溢漏。
JVM使用-XX:PermSize設置非堆內存初始值，默認是物理內存的1/64；由XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的1/4。
解決方法：手動設置Heap size
修改TOMCAT_HOME/bin/catalina.bat
在"echo "Using CATALINA_BASE: $CATALINA_BASE""上面加入以下行：
JAVA _OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"
四、不健壯代碼的特征及解決辦法
1、 盡早釋放無用對象的引用。好的辦法是使用臨時變量的時候，讓引用變量在退出活動域后，自動設置為null，暗示垃圾收集器來收集該對象，防止發生內存泄 露。對于仍然有指針指向的實例，jvm就不會回收該資源,因為垃圾回收會將值為null的對象作為垃圾，提高GC回收機制效率；
2、我們的程序里不可避免大量使用字符串處理，避免使用String，應大量使用StringBuffer，每一個String對象都得獨立占用內存一塊區域；例如
3、盡量少用靜態變量 ，因為靜態變量 是全局的，GC不會回收的；
4、避免集中創建對象尤其是大對象，JVM會突然需要大量內存，這時必然會觸發GC優化系統內存環境；顯示的聲明數組空間，而且申請數量還極大。
5、盡量運用對象池技術以提高系統性能；生命周期長的對象擁有生命周期短的對象時容易引發內存泄漏，例如大集合對象擁有大數據量的業務對象的時候，可以考慮分塊進行處理，然后解決一塊釋放一塊的策略。
6、不要在經常調用的方法中創建對象，尤其是忌諱在循環中創建對象。可以適當的使用hashtable，vector 創建一組對象容器，然后從容器中去取那些對象，而不用每次new之后又丟棄
7、一般都是發生在開啟大型文件或跟數據庫一次拿了太多的數據，造成 Out Of Memory Error 的狀況，這時就大概要計算一下數據量的最大值是多少，并且設定所需最小及最大的內存空間值。
轉載于:https://www.cnblogs.com/java0721/archive/2011/11/28/2602771.html
總結
- 上一篇： centos 支持 ntfs格式
- 下一篇： My first App Encrypt