java堆的大小
㈠ java的堆內存是什麼
Java堆（Java Heap）是java虛擬機所管理的內存中最大的一塊
java堆被所有線程共享的一塊內存區域
虛擬機啟動時創建java堆
java堆的唯一目的就是存放對象實例。
java堆是垃圾收集器管理的主要區域。
從內存回收的角度來看， 由於現在收集器基本都採用分代收集演算法， 所以Java堆可以細分為：新生代（Young）和老年代（Old）。 新生代又被劃分為三個區域Eden、From Survivor， To Survivor等。無論怎麼劃分，最終存儲的都是實例對象， 進一步劃分的目的是為了更好的回收內存， 或者更快的分配內存。
java堆的大小是可擴展的， 通過-Xmx和-Xms控制。
如果堆內存不夠分配實例對象， 並且對也無法在擴展時， 將會拋出outOfMemoryError異常。
㈡ 查看java對象占堆內存多少個位元組
object
o=new
object():
在java中空對象佔八個位元組，對象的引用佔四個位元組。所以上面那條語句所佔的空間是4byte+8byte=12byte.java中的內存是以8的倍數來分配的，所以分配的內存是16byte.
舉個例子：
class
o{
int
i;
byte
j;
string
s;
}
其所佔內存的大小是空對象（8）+int(4)+byte(1)+string引用(4)=17byte,因要是8的整數倍，所以其佔大小為24byte.
當然，如果類里有其他對象的話，也要把其他對象的空間算進去。
㈢ java 虛擬機堆的大小怎樣查看
命令行
java –Xms128m //JVM佔用最小內存
–Xmx512m //JVM佔用最大內存
–XX:PermSize=64m //最小堆大小
–XX:MaxPermSize=128m //最大堆大小
㈣ java中有最大堆嗎
虛擬機上有你說這參數，正常情況不用調整，虛擬機會自行管理。尤其jdk8的虛擬機有幾個跟內存相關的參數，調整了也不生效。java裡面沒聽說過需要自行控制堆大小，也沒聽說過可以自行改變堆大小的api。控制堆的職責在虛擬機實現，對虛擬機啟動參數理解夠好可以自行調整。
補充一點其他知識：堆，棧的控制，操作系統api會提供此功能。直接運行在操作系統上的進程，可以調用到系統api。如虛擬機一般就是c+系統api實現的。因此虛擬機自身可以堆棧cpu等等系統資源。而操作系統可看成與硬體直接打交道的介面平台（實際上又封裝了N層，不用管）。能了解此段的內容，理解第一段應該沒問題了。java可以直接訪問操作系統庫，很少有應用這么用。或者就不推薦這么用，如果這么用為什麼不直接用系統api？此處別鑽牛角尖。java有安全機制，如果訪問操作系統底層的api能否可行不清楚。我也沒試過。
㈤ java設置堆初始值大小為1G的命令參數為
一般系統會默認給定物理內存的四分之一作為你java運行的最大內存, 這個說法是錯誤的,中間件的內存分配都是根據中間間的設置來指定的,如不設置默認為0,而不是自動默認1/4。
㈥ jvm默認多大的對象是大對象
jvm默認多大的對象是大對象？對象的內存分配——對象優先在Eden分配
當Eden區沒有足夠空間進行分配時，虛擬機將發起一次Minor GC。
testAllocation()方法中，嘗試分配3個2MB大小和1個4MB大小的對象，在運行時通過-Xms20M、-Xmx20M、-Xmn10M這3個參數限制了Java堆大小為20MB，不可擴展，其中10MB分配給新生代，剩下的10MB分配給老年代。-XX:SurvivorRatio=8決定了新生代中Eden區與一個Survivor區的空間比例是8:1，從輸出的結果也可以清晰地看到「eden space 8192K、from space 1024K、to space 1024K」的信息，新生代總可用空間為9216KB（Eden區+1個Survivor區的總容量）。執行testAllocation()中分配allocation4對象的語句時會發生一次Minor GC，這次GC的結果是新生代6651KB變為162KB，而總內存佔用量則幾乎沒有減少（因為allocation1、allocation2、allocation3三個對象都是存活的，虛擬機幾乎沒有找到可回收的對象）。這次GC發生的原因是給allocation4分配內存的時候，發現Eden已經被佔用了6MB，剩餘空間已不足以分配allocation4所需的4MB內存，因此發生Minor GC。GC期間虛擬機又發現已有的3個2MB大小的對象全部無法放入Survivor空間（Survivor空間只有1MB大小），所以只好通過分配擔保機制提前轉移到老年代去。這次GC結束後，4MB的allocation4對象順利分配在Eden中，因此程序執行完的結果是Eden佔用4MB（被allocation4佔用），Survivor空閑，老年代被佔用6MB（被allocation1、allocation2、allocation3佔用）。
下面看看使用Parallel Scavenge收集器的情況：
沒有發生新生代GC，直接把allocation4分配到老年代上。
對象的內存分配——大對象直接進入老年代——典型的大對象
很長的字元串以及數組
對象的內存分配——大對象直接進入老年代——大對象噩夢
比遇到一個大對象更加壞的消息就是遇到一群「朝生夕滅」的「短命大對象」，經常出現大對象容易導致內存還有不少空間時就提前觸發垃圾收集以獲取足夠的連續空間來「安置」它們。
對象的內存分配——大對象直接進入老年代——原因
大於-XX:PretenureSizeThreshold設置值的對象直接在老年代分配。這樣做的目的是避免在Eden區及兩個Survivor區之間發生大量的內存復制。
PretenureSizeThreshold被設置為3MB（就是3145728，這個參數不能像-Xmx之類的參數一樣直接寫3MB），因此超過3MB的對象都會直接在老年代進行分配。
PretenureSizeThreshold參數只對Serial和ParNew兩款收集器有效，Parallel Scavenge收集器不認識這個參數，Parallel Scavenge收集器一般並不需要設置。
㈦ JAVA虛擬機的最大堆大小如何設置
虛擬機的堆大小設置不屬於java標准選項，也就是說實現一個java虛擬機，不一定要支持這個功能。
不過流行的發行版都是實現了這個選項，輸入java -X，會輸出有哪些非標准選項被支持。
單獨輸入這個選項（-Xms），是不能工作的，缺少必要的class參數，請注意提示的用法那一段中，非中括弧的部分，那些是必選的。
正確用法:
java -Xss64m Test
Test是class的名字
㈧ java堆內存大小是多少，取決於什麼
這個看下jdk幫助文檔就行
返回的是位元組，所以是247.5MB
㈨ JAVA虛擬機的堆大小如何設置
java –Xms128m //JVM佔用最小內存
–Xmx512m //JVM佔用最大內存
–XPermSize=64m //最小堆大小
–XMaxPermSize=128m //最大堆大小
㈩ java堆的大小包括加上方法區（持久代）的大小嗎
首先你說的「持久代」僅僅是HotSpot存在的一個概念，並且將其置於方法區，JRocket與IBM的VM都不存在這個「持久代」，最新的HotSpot也計劃將其移除。所以你說的都對，在heap中和在Method Area中並沒定論。